I observed a very talented engineering team making a basic mistake today.
I think we often mis-interpret what 'barely sufficient' means in the context of agile software development and delivery. It is mistakenly interpreted as an excuse to cut down requirements. In reality, I believe it really applies more to engineering and design than to requirements. There are two different syndromes to be careful of in a software project - 'scope creep' and 'creeping elegance'.
In an agile methodology, we iterate through cycles of 'design a little', 'code a little', 'test a little'. We embarq on writing software often without fully understanding the problem. I am a big fan of this vs up front. Personally, I pretty much think on the keyboard as I believe, people learn incrementally. That said, I am aware always that there is a risk in this mode until I have a full grasp of the problem. My energy is always directed towards activities or areas that help me flesh out unknowns. Whilst in this mode, I 'hack' for speed and refactor only after I think I have my arms around the business problem.
What I found the team doing was laying the 'foundation' down aka building middleware. That by itself wasnt a problem, however, they had taken their eyes of the business problem and failed to deliver the results in the needed timeframe.
Programming competitions are a great way to teach developers this mindset. You have a fixed duration so you have to be quick. You have to focus on the problem and only the problem .. no deviating onto bunny trails. You have to solve the problem in the simplest quickest way. As engineers, we love complexity so, the last discipline is the hardest.
It’s nice to see you back. I am a real fan of your blogs.
Requirements should be based on the business / service benefits and hence they could be "barely sufficient" if the benefits can be met. I will quote an example but the issue needs to be addressed at a more fundamental level.
However, almost all the time they are not. The requirements are quite often a mash-up of business benefits and the "wish" of the originator. There has to be ways that can capture requirements in such a way that the business problems are "first" addressed and then address the wish list.
The "wish" factors are important from the customer experience perspective but for the techies, they are not as important as the cost, quality, time, performance, scalability and other goodness factors.
Just to cite an example from the automobile industry. The design, engineering and assembly are important for the design and tech team. Those should be decided by the design and engineering community after studying what the market wants (Not the customer). They are the best to do that job. Then comes the configuration bit - color, upholstery, music system etc. Those are similar to the "wish list". Those can be decided by the customer experience or sales teams along with the customer.
Often, in software development, it is very difficult to differentiate between the real requirements and the "wish" and hence teams land up with a lot in their plate.
One option I am thinking about is to pay for a fast dsl/fibre connection and host my own server vs paying someone a monthly charge for hosting.
Post a Comment