Software is full of ilities - those quality attributes that more seasoned veterans (or anyone that thinks beyond today’s quarter) care an awful lot about. Some common non-functional requirements bandied about include scalability, reusability, flexibility, testability, availability, usability, adaptability, maintainability…really we could go on and on. Individually, none of these is more or less important than any other though depending on what you’re building for whom, certain attributes are given more or less weight. If I’m working on a simple app to manage my wine collection, I probably don’t care too much about scalability. But, when designing a ratings engine to process thousands of transactions, my concerns change. To put it succinctly, it depends and its always about tradeoffs.
Lately I’ve noticed a lot of projects value dateility above all else. Now, this isn’t necessarily a bad thing. Say you’ve got an important industry conference in six weeks and you need to have a demo ready or on the close date of a merger the books have to be unified - I’ve been in situations where hitting a specific date really was critical to the success of the project.
But then there are those times where the date is arbitrary, it’s pulled out the hat by some manager or VP in an effort to please their bosses or curry favor with the person cutting the checks. I remember one project where the importance of the date was reiterated to us again and again, only to be told at the holiday party that the plan really had us finishing a couple of weeks after the all mighty date. That didn’t sit well with those of us logging all that extra time and we spent most of the next month cleaning up the code in preparation for the next march.
Of course dialing any ility to eleven means others will be turned down to compensate. When we focus on the date at all cast, we stop testing, ignore best practices, and we’re left with a ball of mud. We might have “saved” a little time, but odds are we’ve cost ourselves significantly more in the long run. When building a house or a bridge, the consequences of shortened schedules are easy to see; with software, it’s harder to diagnose but no less real. High defect rates, difficult to use systems and high estimates for new feature work are typical markers of a rushed project.
The affect on team morale is evident to anyone that cares to see it. Nearly everyone I’ve worked with genuinely wants to do good work, they want to take pride in what they’re building. When forced to do a half-assed job, they don’t take it well. The key is saying no, to build less, but finding a manager or VP willing to do that is nigh on impossible. Agile techniques help, but culture trumps all - if people are rewarded based solely on hitting a date, success will be redefined to make sure the maximum bonuses are paid out.
