A pretty good summary of what’s required by a software development team.
The Joel Test
- Do you use source control?
- Can you make a build in one step?
- Do you make daily builds?
- Do you have a bug database?
- Do you fix bugs before writing new code?
- Do you have an up-to-date schedule?
- Do you have a spec?
- Do programmers have quiet working conditions?
- Do you use the best tools money can buy?
- Do you have testers?
- Do new candidates write code during their interview?
- Do you do hallway usability testing?
From:
http://www.joelonsoftware.com/articles/fog0000000043.html
Programming and the ‘half a loaf’ principle
From the dark ages of 2000 – another article that understands a key developer mindset. Namely: 1) All developers think their code is awesome (at least for the first six months after they write it). 2) All developers think other peoples’ code is garbage and needs to be thrown out. 3) All code can be described by two adjectives: a) ‘bloated’ or b) ‘elegant’. This ignores the fact that bloated code that works is far more useful than elegant code that doesn’t exist yet.
http://www.joelonsoftware.com/articles/fog0000000069.html
The half a loaf syndrome is the idea that something that is incomplete, but provides a useful function, is better than nothing at all. In programming it is generally accepted that it is better to get software out – even with shortcomings – than to wait until a project is complete. This is why governments tend to be so bad with digital projects. They approach software development like building a bridge. Half a bridge is no use … the project has to be 100% complete before it is launched. Civil engineering projects have budgets, targets and completion dates and have a finite objective (a bridge) that is unlikely to change.
By contrast, software with the best will in the world tends to evolve as the project grows and the full extent of the requirements and possibilities becomes clear. If an early release of a usable tool is made to users, then their feedback can help the project grow, evolve (and have good UI), and fix problems early, rather than waiting for a single massive release of a ‘complete’ project and then running into problems.
Another side of that concept is the common developer belief that whatever they did more than a year ago would be better if it was done again. This ignores the principle that something that works, for all it’s faults, is better than something doesn’t exist yet. Half a loaf (with the possibility of just baking the other half) is better than starting a new batch of bread and all the problems that may entail.