I strongly believe that if you want to build awesome software, then every aspect of it needs to be as good as you want the final product to be.
It is often the case that aged software shops will have put in place aspects of their software that they’ll “revisit later on”, which then doesn’t happen.
It gets lost to the crowd of “more important things to do”.
One of the most common neglects I see is how a shop will build, deploy and distribute its software. At best their solution is amateur. It’s usually home-baked and rigged with esoteric and often superfluous tasks and features that are “necessary” due to some poor design decision made previously. The build system — be it continuous integration or some poor sod in the corner — has to do 30 different things, copy 11 thousand files, just to compile the few.
And so the problem persists; the rot festers; the software continues to be sub-par and so do the profit margins.
I feel that if you start from the ground-up, that you build consistently and efficiently then your software becomes such. If it is easy for a developer to build and deploy or distribute your software, it’s then easy for them to do their job. Any developer knows the pains they’ll go through day-to-day when making a change that requires a 15-minute rebuild and 5 minute deployment wait just to check the first name field doesn’t fall over on a null pointer.
With poor practice comes poor software comes poor profit.
So if you’re heading up a development shop and your developers are crying for a more efficient, simpler, consistent build process, then heed their recommendations and concerns. Let them spend the time and money streamlining how they work, because you’ll get reliability, efficiency and less coffee breaks if you do.
Would you pay for that shiny new tablet PC if it came packaged in A4 paper?
How disappointed do you feel with a product when you hold it and you “know” its build quality is poor.
Why is software any different?
You wouldn’t build a palace with breeze blocks.