How much understanding do you have in economics? Because, most of our work, in software, is really based on economics decisions. When we’re coding, we’re working to deliver some economic value to the organization.
Coding is only half the fun, though. In fact, it’s really a lot less then half. Where does our time go? Like all these meetings we attend. What’s their economic value?
As we all know, meetings are waste. Ok, maybe it just feels like it. They don’t contribute to the value that the user gets. If we could spend the time we’re meeting on code, we’ll deliver twice the value, even more. right?
Well, that’s only half true. While they don’t add value much, meetings reduce risks .
When we do requirements reviews, we assume we’ll find out problems, assumptions, unknowns, and even more questions early. All those incur risk to the project, and by flushing them out, we mitgate the risks.
And we do that, before we even open the IDE. We don’t want to waste our time solving the wrong problem. So we invest in the requirement review.
Risks Averted!
We step out of a requirement review understanding the problem.
Then, we march proudly on to the next room, for our next meeting – the design review. We do those, because we want to make sure we build the best solution to the problem. That the architecture and tool-set are sound, that we have the skills, and that our idea actually solves the problem. That it is easy to extend for the next feature set.
We don’t want to deliver a solution that didn’t take into account all the things we don’t know. So we invest in trying to figure them out in the design review. Or in the process leading to it.
Now we know how to build it.
Risks Averted! Again!
We step out of the design review, with common understanding of the solution we’re going to build. Then we go off and code. Then another review pops up: Code review. Why invest in that?
Two reasons. The first is, that as a risk reducer, this is the last gate where we can identify and catch a problem before it goes out into the wild. While we had a design in our heads, floating in the design review room, and in the corridors, our design has now met reality and the solution has probably changed. Maybe a lot, maybe less.
Does it still solve the problem? If not, better go back to the coding board.
The second reason is the future. We can increase our collective knowledge of the code, requirements, tools, patterns – all through code reviews. That knowledge will help us deliver faster (and therefore cheaper), in the next round.
If we see that the code is not extensible as we need it to be, we want to do something about it, so that next feature will be simpler (and cheaper, and faster) to add.
We invest this time in code reviews, so that our future will be better. We pay now, to rip the rewards we believe we get later.
Quality Insurance
I know, you read Quality Assurance, but we’re really using the term wrong. Testers cannot assure quality. They didn’t build the thing, how can they be responsible for its quality? Can we take their assurance seriously?
No. Instead, testing is like buying a quality policy insurance. Instead of relying on luck (and the word of developers), we check that we deliver the right features. That the new features solve the users problems.
That even if we decide to release the app with that bug, at least you and I, and the user, know about it.
We invest in learning as much as we can, so we can make better business decisions about our app. If we think about it, the decision of releasing now, or postponing the release, so we can fix those bugs – These are money-carrying decisions.
Our economic lifestyle is not just about meetings and testers. Take automation, for example. We invest in automation (all kinds – tests, CI, deployment) in order to save time later, and reduce errors in those processes.
Or another economic activity – refactoring. We invest time in refactoring now, (you do refactor, right?), because we want to shorten our time we will spend in the code in the future, so when we get to the future, we can deliver faster.
Everything we do has an economic impact. And we should think about our activities in terms of what value they bring – what we think we’ll get out of them, and at what cost. If you feel meetings, for example don’t bring value, change them. If you’re spending your time in buggy code, write lots of tests, so your trip back will be shorter and safer.
That’s how we can start focusing on the delivering value, with less risk, and in a cheaper way.
I’m talking a lot about economic value in my Clean Code and Automation for developers workshops. Check them out.
0 Comments