#lisp #agile #CommonLisp #softwareDevelopment #paragent

We were contacted by a reporter at InfoQ. He saw the “Why Lisp?” blog post, and wanted to ask about how Lisp helped us with any Agile development practices. You can read the resulting article here. We don’t tend to follow a strict Agile methodology at Paragent, but instead have worked to incorporate some of the Agile practices into our day-to-day routine.

One important aspect of Agile practices is the idea of rapid release cycles. Instead of slaving away for months at a time, and then dumping a huge release in your customer’s lap, Agile practices promote much shorter cycles - on the order of weeks. The basic idea is to keep the development pipeline as short as possible. If you mess up something at the beginning of a development cycle, and only find out six months later, it is very expensive to flush the pipeline. If you get back to them two weeks later, you can recover from your mistakes quickly, correct, and move on.

(Image from     Henning (WMDE), https://commons.wikimedia.org/wiki/File:WMDE_SD%26E_Agile_Process.svg, licensed under the Creative Commons Attribution-Share Alike 4.0 International license)

There is a corollary with the internal development process called the Edit-Compile-Test loop. It is the time it takes between writing code in your editor, and finding out whether it works or not. With traditional programming environments, and large applications, this cycle can be extremely long. This tends to result in programmers doing more in the edit phase of the cycle, to amortize the relatively constant-cost compile phase of the cycle. This has impacts across many aspects of development. For example, if you do more in the edit cycle, it means that your commits into the revision control system will be much larger, and cover potentially disparate areas of code, making rollbacks and merges more difficult.

I am a bad programmer. I have very bad habits. When working in C++, I would bang away on code sometimes for days without fully compiling, testing or checking in. A 15 minute compile is such a buzz-kill. When I was in the flow, I didn’t want anything to break my stride. Programming in Lisp (and from what I understand languages like Ruby, although I have what amounts to no experience with it) is a completely different experience. The compile cost of bringing up an application happens when you first start it, and unless your application is a true behemoth, it is certainly no worse than starting even a minor Visual Studio solution. At that point, the compile phase of the Edit-Compile-Test loop is negligible. You basically edit, and then test to see if it worked. If so, you can check in that little snippet and move on. It may be one of those things you just have to experience to truly appreciate. What is even more impressive is that you are not sacrificing program efficiency on the altar of programming productivity. When you hit C-c C-c in emacs, you are getting a compiled version of your function inserted into the runtime.

What is really interesting is how this Lisp work-flow influences the entire software development stack. Peter Seibel has a great chapter on integrated testing in Lisp, and there are several other good tools out there. Perhaps one of the most often quoted, but never followed piece of software development wisdom: “Premature optimization is the root of all evil.” — Donald Knuth. Lisp makes it dead-easy. I’ve profiled orders of magnitude more Lisp code than I have in any other language just because I could. Lisp is more than just a bunch of parenthesis thrown together back in the 50’s before we could afford lowercase letters and called a language. Lisp brings a different attitude to programming.

Don’t get me wrong - I’m still a bad programmer, with many bad habits. I make optimistic estimates of how long code will take to write. I check in code I haven’t fully tested. I don’t comment my code well. I start coding before I have necessarily thought out why, how, or where I am going. I’m a bad, bad person. Lisp makes it a little bit easier for me to be good some times.

Written by tritchey

November 7th, 2007 at 11:36 am

Originally posted in: http://paragent.com:80/blog/?p=11