Ever had that feeling of anticipation, of an impending feature or game release only to find it delayed? And, then, delayed again again as if you're stuck in an endless cycle of Groundhog Day?
It's frustrating as a user, but it's more frustrating as a developer. And the cause of it has everything to do with effort estimation problems.
Estimating how much time and effort it takes to build a house or write an essay isn't always easy, and you can easily be a factor two off if you don't do it diligently. Do an estimate for code development time, and you sometimes risk being a factor ten or hundred off!
Sometimes the biggest challenges turn out to be a piece of cake, but (more often) the low-hanging fruit ends up becoming epic undertakings. As I have some personal experience on effort estimation, I wanted to share my opinion on the topic here.
Estimating development effort in terms of a number of days tends to be futile for all but the most simplistic tasks. It's much more effective to indicate clearly on what difficulty level you're operating, to crank those down as you advance in a task, and then only make a time estimate once you clearly have the end in sight.
So, to keep it nice and simple, I present five ski pistes of code development to help you guys estimate your effort in a sensible way. Just take one of your planned development tasks and check below to see what piste you're on with it.
Or alternatively, look at an existing development project, think about the tasks they do, put the tasks on the right piste and you'll quickly know to what extent you can trust the effort estimate from the development team!
The Green Piste
What it represents
This is 100% familiar ground. You're doing something you've done many times before, using a platform that you've done many times before and on a topic that you've mastered as well. The task at hand could be writing a README, creating modified versions of graphical assets, or adding documentation to your code. Barely any testing is needed and surprises are extremely unlikely.
how to estimate effort
Go ahead, just make an estimate! You're likely to be approximately correct.
The Blue Piste
What it represents
In some regions blue means easy, in others it means intermediate. These are the tasks that appear straightforward, but threats of delays are absolutely looming if a developer could stop for a moment and think clearly about the nature of the task. For instance, a blue piste task could be (a) doing tests and debugging of generally working code on a platform you're familiar with (b) adding new components to an existing user interface using familiar techniques, (c) making an API change of a code that doesn't need to preserve backwards compatibility. In all these cases, the task will generally go as expected, but there is a distinct change that you'll introduce glitches and inconsistencies that complicate things, or that the underlying platform is complicating your life in unexpected ways.
How to estimate effort
Your intuitive estimate will usually work here, but don't be surprised if it's a factor two off or so.
How to move to the Green Piste
Identify the subtasks that could lead to possible complications and issues, and simply do those first if at all possible? Once you have those out of the way, you'll be on a Green Piste and you'll be able to trust your own effort estimate at that point!
The Red Piste
What it represents
Red Piste development consists of many routine programming tasks. The task will be roughly 50% known ground, and 50% new ground, with the new ground being something that you have some knowledge about, but have yet to establish expertise in. For instance, you may be developing a new code on a platform you've got a lot of expertise in, or you may be porting very familiar code to a new platform that you only have basic knowledge about at the start. You could be connecting CubDefi to a new wallet type, DCity to a new type of game mechanic, or Splinterlands to a new turn order. It all looks perfectly doable at the start, but at least you're aware that there are some unknowns lurking there.
How to estimate effort
When doing development on the Red Piste, I would not recommend making a public effort estimate because complications are rather likely. Your estimate is quite likely to be off by a factor two, and if serious complications occur it could be off by a factor five or more. You'll look like a clown in both cases, so it's better to first move your task to the Blue Piste instead.
How to move to the Blue Piste
Don't waste your time with the low-hanging familiar fruit, but start your development with the unfamiliar half of the coding and dry code it separately. Test it to get a good impression of the unfamiliar part, and then test how it interacts with the parts of the task that you're familiar with. If you then become familiar with that "unfamiliar half", and have a decent understanding of what it does with the other code parts you're working with, then you've managed to move your task to the Blue Piste, and effort estimation becomes sensible again :).
The Black Piste
What it represents
Black Piste development is doing something new, but with clear guidance around. You might not have the knowledge, but you know where to find it, and you know that whatever you're trying to do can be made to work in one way or another. For instance, I've never made a serious Hive application, but if I were to start developing an NFT simulation game on the Hive Blockchain using JavaScript, then I would be doing Black Piste coding. The key difference with Red Piste coding is that most of the work in the task is unfamiliar to you, but at the same time you're not going Off Piste because you do have all the necessary resources at your disposal to do it! (e.g. documentation, Discord support groups, rudimentary examples with similar functionalities from other projects)
How to estimate effort
Don't do it. Black Piste effort estimates can be off by a factor 2 to infinite. There are two main reasons for that: first, the chance of complications is much higher, as you do not fully understand what you're trying to do yourself. But moreover, when working with such unfamiliar things there will be mental processes working in your head. The apparent complexity of the task might make you anxious, causing you to stall in your progress and lose motivation. Or the apparent ease at the start may lead you to writing overly complicated code, only to find that you got yourself stuck inside a bloated architecture and need to restart from scratch months later. Your priority needs to be to get to the Red Piste here.
How to move to the Red Piste
There's no way around it: here you are going to need to crank down your ambition and split up your tasks. Instead of doing something large and unfamiliar, try to define simple prototypes that capture important bits of your development task, and that are much closer to what is provided to you in the documentation. You'll probably end up with a lot more tasks (and/or a more simplistic program), but at least those tasks will land on the Red Piste.
Off Piste
What it represents
Off Piste development is doing something new, without clear guidance around. A few months ago I was considering to develop an NFT game using Unity with the Hive blockchain, and I realized after a few hours that I'd be going straight into Off Piste development! This is because although I know Unity, I don't know much about Hive development and I really could not find clear documentation on combining the two! Sometimes the really unique things start out with doing Off Piste development, so it can be hugely valuable to use this. But this is absolutely NOT the case if there is any kind of time pressure looking!
How to estimate effort
It's pointless. If you feel the urge to estimate effort now then choose a different task.
How to move to the Black Piste
Breaking down your task into subtasks is a good start. Next, identify for which of these subtasks you really don't have clear guidance for, and start exploring those. If you are able to get a clear strategy for those tasks that are the trickiest in the batch, then you've managed to move your workload onto the Black Piste!
Wrap up
I've been coding, designing and leading development for about 16 years now in all sorts of projects, but this is the first time I give development advice here on LeoFinance. Let me know if it's of any help to you!
EDIT: Oh, and one more little thing: keep in mind that different developers perform differently on the different pistes! For instance, Isome get distracted and inefficient on the Green, while others get anxious when operating on a Black Piste...