Well, a few days ago a developer colleague asked on Twitter: “how to reduce costs in software development process?”, this question made me think about all the steps in producing a software and making him available to the customer. After thinking about it a while I came to the following response: “the best way should be doing a great requirement engineering process” and now I will show to all you readers what made me answer that.
On first, what is Requirement Engineering?
Nowadays the Agile Movement take a great space into software development culture, with its many advances in delivering high quality software with time-to-market asked in the customer segment. But, as Fred Brook precisely said in The Mythical Man-Month: “There is no silver-bullet in software engineering”. Exactly as he said, Agile culture is a great advance in this engineering but with its gain comes the price, many software engineers visioning the agility and time-to-market pressure takes the requirement engineering process to a second order. What a big mistake!
According to Ian Sommervile, in his Software Engineering book, this process is defined as : “the first stage to be done in the software engineering process”. In fact, this step is done mostly in Scrum or Kaban with the term “technical refinement”, but many just skip the step “functional refinement” because thinks it a step only to satisfy stakeholders thoughts, and here lives one of the big mistakes in software development. Well, we can refine technically the most as we can, but if it doesn’t satisfy stakeholders it won’t serve. So as the opposite works, if stakeholders think a big project, in many cases it will just be unfit for just one project and should be break into two or more. In any cases, the fault of a well-done functional refinement will lead into a more expensive process, the technical refinement will take more time than expected and result in more doubtful requirements that obligates the team to stop and revisit it in the future.
By its time, a confusing and bad-done technical refinement will take to a bad software modeling and a not efficient architecture, summing it together we have the recipe to more costs into developing process and as consequence the software will probably have a larger memory consuming than it should, what in a Cloud Computing perspective means more money wasted.
In my words I usually say: “Requirement engineering process is the fundamental to spend less money in software engineering”.
So, what would I do to do better in it?
To be honest, there is no cake recipe, every company, every department, every squad has its own differences and dynamic. But you should take the following advice with you: Do not fear in taking a considerable time in this process. See, many projects that I participated focused it’s time in codding. I should suggest you the following as an experiment: invert it. Focus many part of it in refining and mapping requirements, negotiates it with the stakeholder and in the end you will write less code and the stakeholders will spent less money too. Happy ending !
Jokes apart, we know that stakeholder’s pressure are a real pain in many cases, so if you need to do daily reports, I should suggest you spent about 30% of the project time in this step. Define with clarity and objectively the non-functional and functional requirements, the business rules too, and attaches them to its following history, you should spend like one week to one refine one-two history and discover all its requirements and demands.
As you do the refinement, produces in parallel artifacts and documents about it, UML diagrams, requirement documents ( do not bind yourself in the waterfall model, create a template that should take only the essential about the requirements), record meetings and then in the final produce a final report that should map the UI with the followings requirements, talk to the other necessary areas and then do a final meeting, after that you are clear to code.
Taking those steps in mind, developers will not only have less stress than more money will be saved and the success project chances will increase considerably.
Thank you!
Thinking about software engineering, have you already asked yourself: “Why should I still care about doing a colleague”? Check this article !
Top comments (8)
Thanks for sharing this post. From my personal experience I also find this to be true. Software is complex and making assumptions are costly. It's better to pay the cost up front of doing clarifying assumptions before starting to code.
Yeah, in many situations the cost for doing bad assumptions can cost more in long-term than the software itselft, fighting against it should be number one goal in management :)
Maybe cutting down the management costs would be an idea. Use a ticket system to keep track of how long the management spends on each task. Most non-technical tasks aren't complex and could be done much faster.
Well, in micro enviroments like startups it will work considerably. A system like Jira or even GitHub Projects would fit well where the barrier (physicaly and in subjects) are thinner. But when you talk about big companies like Banks then the macro scenario comes and most part of time you will get blocked because of other area SLA are different than yours. Not antecipating this time gap in requirement for example can make you spent more money in one step of the project than you think.
I dont know if that's relevant, but for me, it's multi tasking; a lot of software companies out there make it a habit to put a developer on several totally unrelated epics at a time, all with deadlines, meetings and other followup constraints...
The trial/error/adjustment process of building a software is in my opinion inevitable, and its cost can be reduced with the right approaches and senior developers experience; however, multi tasking provides no benefits at all to any software project and results in poor performance as teams and individuals.
Mistakes during software development are expected, but might be controlled and cerned more into codding problems than architectural/requirement problems.
Multi tasking in fact can be a real trouble when you do not have balance in team focus x other demands. In that point of view emerges one of the most hardful challenges that i saw: doing a great management with teams in necessarily multi-task scenarios.
Really great post
Thank you !