A software developer’s conjecture: I’m going to be a gardener

Last week the question was what is software development really: art or engineering science? My thesis was that software development is a bit of both, but we often forget the artistic aspect in everyday life and often are not even clear where we really stand on this scale: are we artists or engineers?

Advertisement

There were many comments on this blog post not only in the developer channel but also under the related channel Video on Youtube. One comment in particular caught my attention: The author basically agreed with my statement, but saw one point differently. I mentioned that art cannot be estimated, but in his opinion everything can be estimated: Developers are often afraid to give big numbers when they are unsure or do not know.

Appreciate a spaceship

This made me think, because if I am unsure or lack basic knowledge, I cannot estimate because I do not dare to give a large number. It is literally impossible to estimate. In such a situation if I simply give a large number, it will not be an estimate, it will just be a guess.

Developer Snapshot: Programmer news in a sentence or two

If you ask me how long it would take me personally to build a spacecraft from scratch, I have absolutely no idea how to answer. It doesn’t help me to dare to say a big number, because that doesn’t make the estimate any more solid: whether I say five, ten or twenty years – everything has the same significance, namely practically none. And that’s why, in my opinion, it’s not an estimate, but, as I said, just a (bad) guess.

Still, this question hasn’t left me alone, and a few days ago an entrepreneur friend of mine pointed out a very exciting blog post “Are you a software gardener?“Brought to your attention by Chris Aitchison. His core message is that we as developers are not engineers, but gardeners.

Software development as garden maintenance

Of course, when I first read this comparison I found it a bit strange, but the blog post raises a very good point: it says that engineering projects are essentially predictable and so it is also possible to plan and build a bridge or a viaduct. For example, a skyscraper can be predicted quite precisely in terms of time. Because how to build a bridge or a skyscraper is now well known and there is not much difference in each instance and in most cases it is even independent of the respective environment. Of course there is a difference in price, but the basic principle of how to build a bridge or a skyscraper is largely the same.

However, things look completely different if you want to build a garden. Of course, you will have a rough plan and you will be able to tell where which tree, which bush, which flower and so on should be planted. But unlike a building, where you usually already know where which stone or support will be used, in a garden you cannot predict every leaf or every flower in detail. And it would be very absurd if you tried.

In fact, it is obvious that it is impossible to predict how many flowers a few daffodil bulbs planted today will have next spring. Depending on the weather, climate, soil conditions, etc., it is not even possible to accurately predict whether they will even survive the next winter. Of course, as an experienced gardener you have a certain feel and a certain experience here, but you cannot guarantee it.

Active Care

And it’s the same with software: software is also unique and largely depends on its respective environment. Furthermore, software is never finished, but can always be further developed, just like a garden will never end. This is only because the environment is changing: hardware is changing, the underlying operating system is changing, libraries and APIs are changing, and so on.

I have to take into account all these changes in my software over time. Sure: software doesn’t get outdated, but it’s rarely run under the same conditions today as it was five or ten years ago. To implement this, you have to actively do something about it.

Recognize the experience

Of course, this works much better if the software gardeners (i.e. developers) have a certain amount of experience, know their tools and are adept at efficient software development. Just as people talk about plants as having “green thumbs”, there are people in software development who have better skills than others at designing algorithms and data structures.

This ability is not easy to measure; there is no particularly suitable metric for it. But experienced and skilled developers very quickly recognize their peers based on emotion. In other words: if you don’t develop software yourself, it will be difficult to identify really good developers. Often, gut feeling ultimately drives the decision, followed by the hope that the decision wasn’t too bad.

By the way, if you don’t like the garden metaphor, there are other comparable disciplines, such as cooking or playing an instrument. These two examples also require the use of technology, but both go far beyond pure technology if one wants to be really good at them. Mastering the technology is a necessary condition, but not a sufficient one.

My guess? 1 billion euros at most…

So, and this brings me back to the original point, in my opinion estimation makes no sense in software development.

Sure, if you ask me how long it would take me to write a web server in Go that provides some API routes that talk to a database and return or receive JSON, I can roughly answer that, because I’ve done it many times already. But even in this trivial example there are uncertainties that can have massive implications:

• Does the API have authentication?
• Will the API support CORS?
• What is the testing strategy for API?
• Is documentation required for API?
• Is the API versioned, and if so, according to what scheme?
• Are there any special considerations regarding caches or proxies?
• ,

Depending on how these questions are answered, we could be talking about fluctuations in the estimate by several hundred percent, if not thousands. And keep in mind, this is a fundamentally known problem!

But if I can’t predict it accurately without reading all the possible details beforehand, how can I estimate the effort for something I’ve never done before in terms of topic and content, which is completely unknown territory for me?

Of course I could take the original cue from the comments and say: “Well, it probably won’t cost more than a billion euros.” And I’d probably be right with that assessment – it wouldn’t do anyone any good.

The path to an informed guess

The question is what to make of it. Sometimes the business just wants numbers to be able to estimate whether a development is profitable and whether the effort is likely to be worth it in the end. And even if, from our perspective as developers, it is often not possible to give a meaningful estimate, that doesn’t mean that the question about the estimate is not fundamentally justified. Just standing there and saying “Sorry, I can’t appreciate that” is of no use and doesn’t get anyone closer to the real goal.

This is why I believe (and this is the process we use in our company as well Native Web Apply): If we cannot estimate something because there are too many unknowns, then the development project should be preceded by a research project that tries to solve the most important problems. So the goal is initially to develop a “proof of concept”, a “breakthrough”, a “prototype”, or whatever you want to call it. However, in the beginning it is simply a matter of gaining more knowledge and initial experience to put yourself in a better position to make reasonable estimates.

And this research is not valuable, but limited by a timebox. For example, you take four weeks to figure out how certain things work, whether they work at all, and so on. What these four weeks will cost is known in advance because they can be billed based on the time spent. And then you look at the result: if it is promising, you move forward and gradually get closer to a reliable estimate along the way. However, if the result is not promising, you can decide whether you want to continue the research and invest again in a timebox, or whether you would rather leave it alone.

join hands with business

In my opinion, that is a much better way to state a number than to say any big number. Of course, at the end of the day the business has its role to play as well. But I think it is a good idea to point out that if an estimate is needed, you must first create a reasonable basis on which to make a solid estimate.

My experience is that you can explain this clearly and if you communicate it openly and transparently the business often appreciates it too. Because it shows you are now No Just say anything but that you take the request seriously, that you are trustworthy, and that you try to tackle the problem constructively and, above all, together. And that’s ultimately what matters in software development anyway: that everyone involved works together. So why not start with effort estimation?

(RME)