After decades of hacking my C++ Lisp interpreter I just got sick of the state of the code. I don't like most of the code any more. I had some advice from Jon Eaves (http://www.eaves.org), who said "Are you a typist or a programmer?". Hmmm. The value of the work is actually in my head, not the code. His advice - walk away - rewrite it since you will write it much better the next time.
Soooo I have started rewriting it in Java. After three days in, I have got it to this state:
JLispin > ((lambda (x) x) (cons (quote Hello) "World"))
(Hello . "World")
Woohooo !
I'm using SICP as a guide for implementation.
Why Java, I hear you ask? Lots of reasons. The other main candidate was Mono/C#. Java has Eclipse whereas Monodevelop is not more than a text editor. (No debugger). I'm dependant on the Eclipse refactoring tools nowadays. Only Vi$ual $tudio has refactoring tools for C# ;-(. Mono will also compile Java, so Java wins. JLispin will also come in handy in my Java day job.
Let me know if you're interested in dabbling in the project.
Sunday, April 15, 2007
Sunday, February 25, 2007
Why I demand Agile development.
You can rely on Agile development projects to produce good code and unit tests, regression tests and continuous integration environments. Waterfallers can do this too, but don't expect it.
My last couple of Agile projects have used Thoughtworks developers. We've been using Java to build both J2EE web applications and an fat client. When the projects are finished, we are handed not just a fine application, but also a complete world of fully automated test suites and JUnit or Selinium tests. The code itself is highly refined since by now it has been refactored many times.
Big Deal, I hear you say, what does this have to do with architecture? Well as an architect this suite of code and tests means a lot to me. I don't need to design every foreseeable integration point up front. Because the code is well-made I can be sure that adding integration points in future will be feasible and safe.
It's feasible because of the large number of unit tests has forced the devs to use dependency injection, so adding interfaces doesn't engender a re-write. It's safe because when we refactor to add (say) a web service, I know the automated regression tests will pick up any breakages. So changing is less painful in after-project maintenance. Not surprising when you understand that all coding is maintenance in an Agile process.
So when I consider change cases for the system design I can be very relaxed about future changes. This is very valuable to me and my customer. It reduces my need to create a Big Design Up Front. The less you do up front, the better.
Deferring detailed design decisions allows you to use the lessons learned during prototyping and software development. In engineering terms its a way of reducing delay in the feedback loop from posited design to actual experience.
As each iteration unfolds we create production-ready software. We run this an make sure it works in a production-like environment. So any architectural nasties are found early. On one memorable project I deployed the software into the production environment well before the system was to go live. The system performance was abysmal due to WAN latency. We were able to make fixes in the next iteration without breaking stride. If it had been a waterfall project we would have never seen the issue until the end.
Your Agile development team can give you early warning if you have architectural issues.
All good reasons architects should prefer Agile.
My last couple of Agile projects have used Thoughtworks developers. We've been using Java to build both J2EE web applications and an fat client. When the projects are finished, we are handed not just a fine application, but also a complete world of fully automated test suites and JUnit or Selinium tests. The code itself is highly refined since by now it has been refactored many times.
Big Deal, I hear you say, what does this have to do with architecture? Well as an architect this suite of code and tests means a lot to me. I don't need to design every foreseeable integration point up front. Because the code is well-made I can be sure that adding integration points in future will be feasible and safe.
It's feasible because of the large number of unit tests has forced the devs to use dependency injection, so adding interfaces doesn't engender a re-write. It's safe because when we refactor to add (say) a web service, I know the automated regression tests will pick up any breakages. So changing is less painful in after-project maintenance. Not surprising when you understand that all coding is maintenance in an Agile process.
So when I consider change cases for the system design I can be very relaxed about future changes. This is very valuable to me and my customer. It reduces my need to create a Big Design Up Front. The less you do up front, the better.
Deferring detailed design decisions allows you to use the lessons learned during prototyping and software development. In engineering terms its a way of reducing delay in the feedback loop from posited design to actual experience.
As each iteration unfolds we create production-ready software. We run this an make sure it works in a production-like environment. So any architectural nasties are found early. On one memorable project I deployed the software into the production environment well before the system was to go live. The system performance was abysmal due to WAN latency. We were able to make fixes in the next iteration without breaking stride. If it had been a waterfall project we would have never seen the issue until the end.
Your Agile development team can give you early warning if you have architectural issues.
All good reasons architects should prefer Agile.
Subscribe to:
Posts (Atom)