Integrate sustainability in your estimation
In this blog-post i want to show you some ideas how to integrate sustainability into effort estimations. These estimations can be applied to software development projects.
Sustainable development comes with many benefits, but it’s often neglected due to close project deadlines in classical waterfall projects or due to small budgets.
Of course developing a clean greenfield project is slower and more time consuming than developing in the quick and dirty manner. Test-automation, code-reviews, refactorings, behavior-driven-development etc. is time consuming and in many commercial projects time means money.
But these workflows are essential to reduce technical debts and with some experience they are calculable.
Behavior-driven-development (BDD) is primary based on the idea, that we split one test in three sections:
- The given-section: In this section we prepare all boundary conditions of our software system, so that the test stay deterministic
- The when-section: A part of the software-system is executed
- The then-section: The results the when-section has produced are verified
The given-section and the then-section should be taken from the requirements. The when-section comes from the implemented solution.
Until one test with one given, one when and one then-section passes, we need to implemented a test-method, a procedure under test, prepare the boundary-condition, run the test, refactor the procedure under test, resolve errors, run the test again until it passes, review the code.
My idea was, the ratio between the duration, that a developer needed to implement a set of requirements, and the number of single BDD-style-tests he created in this time, reflects an average personal velocity constant.
The number of BDD-style-tests should include in my opinion all tests:
- The automated ones
- The manually executed tests
The requirements, which were implemented and which could be but actually weren’t verified with a BDD-style-test, can be also included in the number of tests.
Then the personal velocity get’s more realistic.
From the personal velocity to the estimation
To estimate the project duration with this approach, we first need to split the requirements into a set of BDD-style-tests. Therefore experience with test-driven-development is helpful.
Then we multiple the number of BDD-style-tests, which we got from the last step, with the average personal velocity.
- The estimation includes the extra efforts for develop automated tests, for refactorings and all the other stuff, which is needed to develop clean-code.
- The actual progess can be compared with the estimated progess.
- Changing requirements can be included in the estimation, even when the project is already in progess.
When the project is in progess, we can compare the actual efforts with estimated efforts. The estimated efforts is the product from estimated velocity and number of implemented BDD-style-tests.
A new estimation for changed requirements can be done with the same algorithm. Therefore we split the changed requirements into a set of BDD-style-tests, substract the tests, which are already implemented and which are still conform to the changed requirements, and multiple the number of tests with the average personal velocity.
This estimation-algorithm can be applied to classical greenfield waterfall projects.
Brownfield projects are more difficult to estimate, because a change on the top-level-component like the user interface often has a set of changes in the dependencies as a consequence.
Take as a example a transactional client application, which interacts with SAP through a RESTfull-API. When the user should enter an additional property in the user-interface and this property should be saved in the database-records, the application creates, every component of the application must change:
- The user-interface needs a additional input-field for the new property
- The RESTfull-API must handle the new property
- The ABAP-update-function-module must handle the new property
- The database-tables must store the new property
In my next blog-post i want to show you another idea how to estimate brownfield projects.
The average personal velocity can be an important key figure for effort estimations, which include all the extra efforts for developing in an sustainable manner. Of course this key figure is based on some assumptions and will not cover all eventualities, which happens in an software project.
But it can be a quite realistic approach for projects, that are using behavior or test-driven-development.
Johannes Gerbershagen nice post, i have few questions
I will be really happy to know whether you are using in your projects if yes how did you manage the above mentioned points?
Great answer and nice blog too!
I agree that building a trust is vital for being able to, well, do anything, actually. If people do not trust you why would they follow you and agree to your suggestions? I feel this is especially a challenge for the consultants, unless they work for a company that already built trust with the customer. The permanent workers face the same issues but the consultants frequently start off with a handicap. At least that's my experience from years of observing many SAP projects.
Good points. Johannes already answered well to p. 1. I feel 2 and 3 are connected and this is a general challenge in development, not related specifically to the specific concept in the blog.
To write better code (which is, in the long term, cheaper and easier to maintain), we need to learn continuously and understand new techniques / technologies that come up seemingly every day. At the same time, we have our daily work to do, working code to write. So we don't have a lot of time to learn. But if we don't learn, we do not write good code and eventually spend more time writing code inefficiently / maintaining inefficient code. And we have even less time to learn.
As you see, it's a vicious circle breaking which can be very challenging even for someone who realizes it needs to be broken. (Let's just admit there are plenty of "lemming developers" who are perfectly happy cranking out the same code and/or don't even realize they're stuck on a wheel.) This is a complex problem that also involves incompetent managers and lack of leadership but, that aside, what can we do, as developers? Here are my thoughts.
“(Let’s just admit there are plenty of “lemming developers” who are perfectly happy cranking out the same code and/or don’t even realize they’re stuck on a wheel.)”
Lemmings go off cliffs. Perhaps “hamster developers”.
WWMC? What Would Matt Code? – I like it. I think I’ll trademark it.
Hamster developers describes it very good. I see many colleagues don't come out of their wheel. They just saw the plenty old COBOL-style solutions with huge procedures, the five chars long abbreviations etc. and think that is the way how ABAP development is done.
The never saw and nobody tells them how ABAP development can be enhanced in the year 2020. Next week i'm going to tell some of these developers, that we couldn't accept these old COBOL-style solutions anymore and that we going the review their code continuously and expect them to improve and refactor their solutions. I'm excited about the reaction.
Good luck with that! 🙂 I hope most people genuinely want to change and just need some help or motivation. However, there definitely are people who just refuse to change at all. In my personal opinion, if anyone ever reaches such point they should leave the development profession for everyone's sake. But not everyone agrees...
I did that back in 2003. It generally improved coding styles. I was Head of Development then, so I wrote the standards, and then said - code reviews must be carried out to ensure these standards are met.
Very simple standards like:
For the matter of fact, Lemmings don't go off cliffs.
It's just a myth (based on a faked nature movie).
Don't tell me it's a myth. I've played the game. 😉
Better real working ABAP examples:
For a smaller project, I'm not sure how it would work. Like Nabheet Madan it is probably lack of personal knowledge.
I also think you would have to balance what the change is with what the effort to fixing the program would be. If it would take you 2 hours to do a quick change or 5 days to fix it, I couldn't justify the five days. Probably because it isn't really a project. Correct?
I can see the advantage. But I struggle with how to implement it.