Yes, this entry's title is a riff on Mitch Albom's book The Five People You Meet in Heaven. Largely inspired by the previous blog entry, here's a post about things typical developers ignore because they're either inexperienced, lazy, or plain stupid.
These are the kinds of things that many developers don't want to think about; they just want to do the 'fun' part, the quick hacking together of a GUI and some half-baked business rules. But that's like only doing the fun part of making a baby. Failing to uphold responsibilities as a parent and partner can yield a very imbalanced child. People wanting to only do the fun parts should get out of enterprise IT and become developers only after they get to the big workstation in the sky (I couldn't write 'cubicle in the sky' because I'm not sure there are cubicles in heaven).
And no, no one person is perfect and has the time to be a complete expert in all the below items. But someone on the project team better be thinking about these, and preferably at design time so they don't become emergency projects later in a system's life. If making software right is hard, making it right after it's already in production is harder. The alternative? Get ready to burn that candle at both ends.
Archiving
If a system is going to last a while, it's going to collect data. Queries, I/O operations, and general system performance all get slower as a system has to hash through more data. But an archiving approach for older data always seems to be an afterthought to most application developers. This is also becoming more important in an age of legal compliance (read: Sarbanes Oxley).
Concurrency and Scalability
Thanks to years like 1999, the developer ranks are filled with Visual Basic* and Excel* macro people that think applications have only one user. So they don't design to protect against dirty reads and writes. What's sad is that RDBMSs and some programming language tools have support for managing concurrency and protecting data, but these features are either ignored or worse, coded around!
* Note that I'm not necessarily against Excel or VB, both of which can be outstanding tools, but more the mentality of people that spend a few months with them and then, with no exposure to advanced computing issues, assume they can work on enterprise systems (and at fat contract rates!).
Data Modeling
This is arguably the most important item on the list. A database structure that satisfies the business needs and is technically sound is paramount to a system's business value, agility, performance, and maintainability. Too many developers think programming is all about building a GUI. But a cruddy GUI on a solid database can always be replaced. It is more difficult and expensive to repair a broken database foundation under a beautiful GUI.
As an adjunct point, SQL, and cousins like PL/SQL and T-SQL, are not to be scoffed at and seen as nuisances. They are tools like any other and when used properly can simplify the work of the client and middle tiers. They are valuable allies in addressing the challenge of application partitioning and code reuse.
Documentation
All companies suffer turnover. Sometimes it's because the company stinks. Sometimes it's because the company is fine but the market is good and someone just gets a great opportunity. Sometimes people decide for a career change or want to have kids. In the end, someone other than the original developer(s) will have to look at the code. For the love of God, document. Document in design papers. Document in code comments. Document in technical papers and user manuals. Others will benefit from it and so will you.
Yes, it's possible to document too much (see Scott Ambler's articles on agile documentation). Overbearing loads of documentation can put people to sleep and can themselves become a maintenance hassle to keep current. But a lack of documentation or the presence of poor documentation are much more common concerns.
Security
It's the age of the Internet, viruses, email fraud, wireless networks, and cheap multiple-gigabyte portable storage. But no matter what age it is, there are always humans around. Humans are evil. It's better to plan for protection at design time rather than a year after going live.
No comments:
Post a Comment