Today, while on the beach at Cape Hatteras, we built a sandcastle. And not just any sandcastle, a drip castle. The tide had reached its lowest and was coming in. We had a trench dug from the sea all the way up to our castle. Then a moat from the trench encircled the castle, and finally a mound in the middle housed our drip spires. It was quite the undertaking. It began without a complete plan, it suffered some setbacks, multiple people contributed and the contributions were often mis-matched, and a certain someone destroyed as much as he contributed. It was never really finished, but it was beautiful when we finally stopped working on it. And it was all built with the knowledge that it was in the path of high tide. And it struck me - this is like nearly every software project out there. I have a friend who's been in consulting for a long time and worked on many different projects and he often laments that none of them are around anymore... they've all been re-worked to newer tech or the company has gone out of business or the project is otherwise dead. Decades of work, but no tangible product to show for it remains.
So, here are some thoughts on software and sandcastles...
Even when you have a plan, you won't really be able to follow it
It's hard to predict every bump in the road or turn of events. The users of the software won't really know what they want until they actually use it, even when they think they do know. The management will want results quickly, and won't see maintainability and good design as being more important than the project schedule, though they'll never admit that. They want it all - good, fast and cheap; none of this picking two business. Also, process is everything! Users will often jump to UI opinions or lists of what they want to track, but they will often avoid telling you what their business process is because they frankly don't know. Often, they're looking for software to drive the process - EEP! Process should drive the software. Building software is like building a sandcastle - even with a 'plan', it evolves as it gets built.
Not all developers are created equal
Some developers will break everything they touch. Because accuracy and attention to detail isn't important to them, they'll often be faster to market because they can cut out the hard stuff. They'll write twice as much code and produce an order of magnitude more bugs. They'll shy away from newer techniques because the old ways work for them and are comfortable. Building software is like building a sandcastle - not everyone who touches it makes it better.
It's okay not to be finished
Software that isn't finished is software that's being used. That's a good thing. Building software is like building a sandcastle - if it's good, there's no such thing as 'done'.
Remember it's made of sand...
Yes, you may have the most beautiful design in the world, but it's written in COBOL. No really... it's all COBOL given enough time. Your medium is sand. Java is 15 years old. C# is only 10. ASP.NET MVC, only 1. And within these technologies, there is constant rehashing. Take the classic example of Microsoft's data access strategies. ODBC, DAO, RDO, ADO, ADO.NET, Linq-to-SQL, and now Entity Framework. And that's just within Microsoft tech. Building software is like building a sandcastle - as beautiful as your creation is, it's still made of sand and the next tide is coming.
The right way is to do it for love...
We know it's not going to last like a beautiful building. And it's probably not going to be used by millions of people like a particular model of car. And it's not going to be touched only by the most skilled craftsmen like some kind of wood furniture. But building software is still beautiful and complicated and fun, even if it's just made from sand.