In this episode, the penultimate episode in the Software Estimation mini-series, I want to discuss how Software Estimation works in terms of professionalism - and in many cases, surprisingly, the professional response is not to provide an estimate.
Or listen at:
Published: Wed, 26 Feb 2025 01:00:00 GMT
Links
Transcript
Hello and welcome back to the Better ROI from Software Development podcast.
This episode is part of a wider mini-series looking at estimation in software development. I started the mini-series back in episode 189 by providing the following guidelines:
- Don't invest in estimates unless there are clear demonstrable value in having them.
- Agree what a valuable estimate looks like. This will likely be a desirable level of accuracy and precision for an estimate.
- Provide the team with training and time to develop their estimation skills
- Collect data on points 1 to 3 and regularly review if you have the correct balance.
Subsequent episodes take a deeper dive into specific aspects for estimation in software development, and while long-term listeners may find an amount of repetition across the series, I wanted each episode to be understandable in its own right, as much as practical to be self-contained advice.
In this episode, the penultimate episode in the Software Estimation mini-series, I want to discuss how Software Estimation works in terms of professionalism. And in many cases, surprisingly, the professional response is not to provide an estimate.
So you may be asking, why would an episode on professionalism be included in a series focused on software estimation?
I guess this episode for me feels like a cathartic exercise. I've been called unprofessional, maybe even lazy, on occasions where I've been reluctant to provide estimates.
I strongly refute that.
In some situations, we simply don't know enough to be able to provide a valuable estimate.
In such situations the unprofessional, and indeed lazy approach, would have me just given an off-the-cuff estimate, something to tick the box, something to get a manager off my back, basically to kick the problem down the road and worry about it when the estimate was invariably incorrect and expectations have been set.
After all, how easy would it be for me to say "that's a 24 month project, check in with me every 6 months for a progress update". That buys me lots of time to get on with the work, lots of time where I'm not having to keep justifying my time.
Definitely easier.
Definitely results in a quieter life than having to have a conversation why I can't provide a valuable estimate.
But, unless I have considerable confidence in that 24-month estimate, then wouldn't that be the unprofessional thing to do?
So, through the course of this episode, I will go into more depth in my thoughts behind this. I hope that this episode not only helps to give comfort to developers like me, professionals trying to do what they believe is correct, yet come under a constant barrage to take the easy path, but also to help leaders and managers to understand that the questions they are being asked are a reflection of their professionalism.
Let's start with professionalism within software development.
Unfortunately, professionalism within software development is not a defined thing.
Software developers do not have a necessary professional level they need to reach to be able to start producing websites, apps, or even industrial control units. It's not an industry like medicine, law, or architecture which requires us to achieve a level of theoretical knowledge, nor make any commitment to the morality or the correctness of any work that we do.
That new app you've downloaded, or that website you've just put your credit card details into, it could have been written by someone with over 30 years of experience like myself, or by a doctor of computer science, or by someone that has self-taught themselves in their spare time from watching a handful of YouTube videos.
In many ways, this is an excellent thing. It's a great leveller. It allows many self-starters to break into the industry without having to go through prohibitively expensive qualifications. It allows people to transition into their career with a reasonably low barrier to entry. With so much free content out there, it's perfectly possible for anyone with access to the internet to learn the skills to provide themselves and their loved ones with a stable, lucrative future.
Having myself been largely self-taught, I applaud anyone that has made the effort to either get into the industry or continue to grow through self-learning. If anything, given how quickly technology changes, the ability to self-learn has to be a key characteristic for any successful software developer.
But, there is always two sides to that coin.
So, while it's a great leveller, and provides opportunities for so many, and allows for rapid adoption of software in our everyday lives, it does come at the price of consistency. Take four developers with five years of industry experience. The variability in what they know, techniques, approaches, programming languages, their ways of working, their thoughts on the morality of their work will be heavily influenced by the teams they have worked with, and the work they have been paid to do.
As such, there can be no expectation that those four would all have the same definition of what professional is, let alone attempt to live up to it.
One may be obsessive about quality and push for heavy instrumentation in time and effort in testing.
One may be obsessive about positive good and pushing for a heavy investment in making software inclusive and non-harmful.
One may be obsessed about delighting their customer and pushing for an ever-growing list of exciting features.
One may be obsessive about delighting their employer, pushing to hit every target to put them in a good light for that next raise or promotion.
And all four would be right, in their own way. Each is being professional as they see it, and there is nothing wrong in that. But the key takeaway is that all are being professional differently.
And it was this lack of agreed professional characteristics that led to one of the leading software developer thought leaders, Robert C. Martin, or Uncle Bob as he is affectionately known, to draft the Programmer's Oath back in 2015.
He wrote:
"In order to defend and preserve the honor of the professional computer programmers, I promise that, to the best of my ability and judgment:
1. I will not produce harmful code.
2. The code that I produce will always be my best work. I will not knowingly allow code that is defective, either in behavior or structure, to accumulate.
3. I will provide with each release a quick, short and repeatable proof that every element of the code works as it should.
4. I will make frequent small releases so that I do not impede the progress of others.
5. I will fearlessly and relentlessly improve my creation to every opportunity. I will never degrade them.
6. I will do all that I can to keep the productivity of myself and others as high as possible. I will do nothing that decreases that productivity.
7. I will continue to ensure that others can cover for me and that I can cover for them.
8. I will produce estimates that are honest both in magnitude and precision. I will not make promises without certainty.
9. I will never stop learning and improving my craft."
I explored the program as Oath in detail back in episodes 51 through to 60.
Keep number 8. "I will produce estimates that are honest both in magnitude and precision. I will not make promises without certainty" in mind - we'll be coming back to it later in this episode.
While Uncle Bob has made a valiant effort to introduce them to the mainstream, and to my mind his Programmer's Oath is the best example of attempting to do this, I doubt that more than 5% of software developers are even aware of them, let alone having read them and then attempting to live by them.
So, again, we come back to there being no universally accepted guidance on what is or isn't professional software developer behaviour.
Thus, in lieu of that, we have to fall back to what we would consider generic professional characteristics. Those characteristics we would want and expect from those working around us.
So I asked ChatGPT, what are the top 5 characteristics of a professional? (Spoiler, you will notice from the response, perhaps unsurprisingly, a lot of crossover with the programmers oath.)
"The characteristics of a professional can vary depending on the context and the specific profession, but there are several key traits that are generally regarded as essential across a wide range of professions.
Here are five of the top characteristics:
1. Expertise and competence. A professional possesses a high level of expertise in their field, acquired through education, training and experience. This includes not only technical skills but also a deep understanding of the theoretical and practical aspects of their work. Continuous learning and staying updated with the latest developments in their field are also part of this trait.
2. Integrity and ethical standards. Professionals adhere to a strong set of ethical standards and conduct themselves with integrity. They are honest, trustworthy and accountable for their actions. They make decisions based on ethical considerations and are committed to doing the right thing, even when it's challenging.
3. Reliability and responsibility. Being dependable and consistent in work and performance is a hallmark of a professional. They take responsibility for their work, meet deadlines and follow firm commitments. They are also accountable for their mistakes and learn from them.
4. Effective communication. Professionals communicate clearly, effectively and appropriately. This includes not only verbal and written communication, but also the ability to listen actively and empathise with others. They can convey complex information in an understandable way and adapt adjusting their communication styles to suit different audiences and situations.
5. Respectful and collaborative attitude A professional demonstrates respect for others, regardless of their positional background. They value diversity and foster an inclusive environment. Collaboration and teamwork are also important, as you understand the value of working with others to achieve common goals.
These characteristics contribute to a professional's reputation and success. They are often interrelated. For example, effective communication enhances reliability and integrity reinforces expertise. Together, they form the foundation of professionalism in any field."
For me, the two key characteristics that come across in that description and that of the Programmer's Oath are trust and transparency.
I find too often that these two characteristics, characteristics that are a cornerstone of any society, are so often overlooked. Almost seen as too simple for anyone to care about.
Yet, so many initiatives, projects and even companies fail for lack of them.
As leaders and managers, we want to have the truth, warts and all.
The concept that the worst thing for a leader is not being told the truth is a common theme in leadership and management literature. Books like Good to Great, Leaders Eat Last, and The Five Dysfunctions of a Team, for example, emphasise the importance of transparent communication and the dangers of a culture where employees feel unable to speak the truth to leadership. These works highlight how a lack of honest feedback can lead to poor decision making, reduced employee engagement, and a toxic working environment.
Leaders are encouraged to foster an atmosphere where team members feel safe, and are encouraged to express their thoughts and concerns honestly. This includes being truthful about challenges, potential problems, and even personal mistakes or misjudgements.
Such principles are crucial for effective leadership and organisational success, as they enable leaders to get a clear picture of the situation, make more informed decisions and build stronger, more resilient teams.
The reality, however, is often something different.
How common is it that we find institutional gameplay around estimates?
Now I've seen plenty of project managers that will add a contingency to a scheduled date. So while the team may say the 1st of September, the project manager may well communicate this as the 1st of October.
While hopefully a thing of the past, for decades project managers were held to the mantra of "delivery on time and on budget", which invariably led to project managers either inflating estimates or reducing scope to hopefully account for the unknown unknowns, or at least try and minimise the occurrences when they fell outside of the "delivery on time and on budget" mantra.
This always felt wrong to me.
While I believe it was done with the best of intentions, it built a level of distrust and suspicion between delivery teams and the stakeholders.
So much so that it was commonly accepted practice for a project manager to inflate a development estimate, only for a stakeholder to reduce the project manager's estimate and return it back as an expected commitment. It certainly wasn't uncommon for those adjustments to be unequal, and the original development team to be given significantly shorter time than they had originally estimated, because the new commitment was overly aggressive.
And what happened the next time? The development team knew to inflate their estimates before they even reached the project manager. And the whole cycle continued, with each link in the chain making their own adjustments because of a lack of faith and trust with those they worked with.
As an aside, I'd be very cautious about adding contingency to a scheduled date to account for unknown unknowns - as the new schedule becomes, as Parkinson's law states, "work expands to fill the time allotted for its completion".
If a given delivery team feel that a given delivery schedule is viable based on the available knowledge of the piece of work, then why artificially expand it? We're simply giving them a subconscious hint that they can take their time.
So again, my preference is to communicate honest and transparent schedule dates that have been created in good faith based on the available knowledge of the piece of work we have at that point in time.
So, with that warning in mind, let's revisit the 8th item in the Programmer's Oath - "I will produce estimates that are honest, both in magnitude and precision. I will not make promises without certainty".
This comes back to transparency and trust, being clear on how certain I am about an estimate and how I've arrived at it.
Thus, if I have low confidence in estimate, of which is more likely than not, then what should I do?
Is the more professional approach to declare a level of uncertainty over an estimate, and possibly even withhold it if it feels there's a danger that uncertainty will be diluted as estimates travel through the lines of communication? (Which is often how estimates transform from a guess to a commitment.)
Or simply provide the off-the-cuff response to keep the cogs of whatever project management methodology to keep turning.
To be crystal clear, the latter of these two options, in my opinion, is incredibly unprofessional.
In earlier drafts of this episode, I even went as far to describe them as potentially negligent to do so. However, that implies more intent than is likely.
I decided it was unfair to brand someone as negligence simply because they were following the organisation's norms of "everybody does it", or the temptation of "anything for a quiet life".
Rather, it's one of training and awareness of the values that comes from truth and honesty.
Thus, to the developer who finds himself in a situation of not having confidence, on having many known unknowns, on having too many variables to be confident in their estimation, then yes, the professional approach is to make that clear and understood.
Confidence levels, assumptions, risks, all of the grey area around an estimate make part of that estimate. Simply extracting the estimate as a single point value will be the unprofessional response in pretty much every circumstance.
And this is where we need both software developers and their leaders and managers to work together for a professional outcome.
If, as a leader or manager, you are getting a simple single point estimate, then you should be questioning if you or your organisation are encouraging unprofessional behaviour. Unfortunately, we still have too much muscle memory around taking the easy answer. Taking the 24-month estimate, plotting it out on a Gantt chart, adding it to a PowerPoint presentation and declaring, job done! Or at least until the end of the 24 months.
Leading and managing in the modern age requires much more from you than that.
As part of that communication chain, you need to provide the most honest and transparent view of the world. The most professional representation of reality, to provide the most accurate representation for your stakeholders. It needs to be the truth, the whole truth, and nothing but the truth.
If you and your team really don't know, then that, and why, should be what you are reporting. You should be encouraging them to be as professional as they possibly can be, as honest and transparent as they possibly can be.
And that will include not just coaching the team to be honest and transparent in their thinking, but also ensure that when it's forthcoming, that it isn't watered down just to make it more palatable.
In this episode, I wanted to address the myth that not providing an estimate is unprofessional.
When most of our estimation efforts are poor at best and dangerously misleading at worst, in many cases not providing an estimate is likely to be the more professional answer.
With a lack of formal definition, professionalism within software development is often in the eye of the beholder. I would bring it back to the generic professional characteristics of honesty and transparency. These are the cornerstones on which valid decisions can be made, the cornerstones that strategies can be built on. Often the correct answer is, we don't know, and the correct strategy works with that simple, humbling admission.
In next week's episode, the final episode in the mini-Series, I provide a wrap-up, recapping the guidelines and providing some additional tips that didn't have a home elsewhere in the series.
Thank you for taking the time to listen to this podcast. I look forward to speaking to you again next week.