Get it working then make it better.
I have recently been doing some research into Open Source, its an interesting subject from so many perspectives. That’s not what this article is about but if you want to follow up on it I recommend The Success of Open Source. Anyway reading this book prompted me to think a bit more about daily builds. Yes I know I already posted on this topic a few days ago but I can’t resist linking it with the Linux philosophy which can be summarised as:
“get it working then make it better”
Now this really appeals to me for a few reasons:
- I am a pretty poor programmer, a reasonable designer and a pretty good architect, (hopefully :-)). So I incline to grand concepts, but I can never get them to work in code unless I start really simply. In fact in most cases I start with someone elses code first and hack it around until I have proved the basic concepts.
- My real background is in systems integration so I never expect anything to work as documented. In fact when I started programming with VB 2, I fell found of a whole host of bugs as well so even when not systems integrating I am very cautious. Because of that I really like to hack something together very early on that proves all the really important concepts work, before I creates architectures or designs that depend on them working.
- I really like to play around with ideas and discuss and debate and its so much easier to do this with prototypes of some kind. Not for me, I can play around with concepts just fine, but most engineers/developers that I work with struggle with concepts but revel in practical discussions around applications/hardware and code.
- The final reason is that project team members engaged early on in the process when something only just works, is just about useful, but can be easily improved in obvious ways marshals tremendous enthusiasm from people involved, as they feel that their contributions really matter. If the daily build method is followed they can see the results of their contribution quickly and directly. Conversely if your contribution is to review some dry 100 page document, have to comment on laborious comment forms, rarely get any feedback and only see the end result months later then its not surprising that motivation and ownership of success is somewhat diminished.
As an aside since I mentioned “laborious comment forms”, I just wanted to say “I hate the things”, my preference is comments made directly in MS Word, but to be honest I always tell people comment in any way you like, this is my preference but comments are what I want, the richer the better, a nice set of neat forms are NOT my objective.
There are lots of other reasons why “get it working then make it better” works really well, but I have already written about them in the previous posts.
