Given enough money, time, experience, technical experience and creative input, time has shown as an industry we can build awesome things. Unless you’re working on a self-funded project with unlimited supplies of cash and time, it’s unlikely that most of us will ever have the experience of working with minimal or no resource constraints.
Software development in ‘the real world’ is really no different from any other business, and the concept of the Triple Constraint has been well understood in Project Management for some same. This describes the inter-relationship between 3 attributes of:
- schedule
- scope
- cost
and how they interact to affect quality of the final product. At a high level, it’s generally understood that you can have ‘any two’ of these, but it’s impossible to have all three at the same time. Each of these attributes translates to desirable qualities of:
- fast (deliver the product in less time)
- good (include all desired features)
- cheap (deliver at low cost)
So, you can have fast and good but it won’t be cheap, or you can have fast and cheap but it won’t meet all your requirements (some features will have to be left out).
So back to the original topic. How is software development a compromise? Invariably because your client or your company wants all these things: “we want it developed in an impossibly short amount of time (get it ready for tomorrow), we want this massive list of features (and no, we’re not prepared to leave any out), and oh by the way, we only have enough money to pay for 1 developer to work for 8 hours”.
While technology can go some way to helping produce more for less (code generation etc), the reality is that software development in the real world is not a technical problem. It is a business problem of negotiating contracts and managing expectations. For the technologist, this is the continual struggle – pretty much everything you work on will be under less than ideal conditions.
Business Driven Development (BDD). Welcome to the Real World.
True. But more often than not, software is delivered way outside of the minimalistic envelope which would be allowed by the problem to be solved. That’s normal, to a point – humans are creatures that make mistakes, software is written by humans, hence in the writing of software mistakes happen.
However, I think there’s a particular class of mistakes which cost more and would be easy to avoid in most cases.
In an agile world, few projects still do a minimalistic requirements analysis. True, in an ideal process stories are captured in a way that makes the business benefit obvious, and are then prioritized based on the ratio between benefits and cost. In the real world, however, this cost is always assessed only subjectively, and never in relation with a new feature’s effect on the application overall. This leads to bloatware, when the actual solution would be multiple, separately licensed, decoupled but well integrated applications. Bloatware is never a solution. At least not a good one.