Responsibilities of Modern Software Developers part 1

Consider a Scenario…

Consider a scenario: One developer, one manager. The manager asks the developer to estimate a piece of work, and the developer provides that estimate. “A couple of days”, he says. “Great!”, the manager replies. A couple of days pass and the manager taps the developer on the shoulder – “Hey, how’s it going, are we done yet?”. “No, sorry”, the developer replies, “it took much longer than expected, the codebase is riddled with nasty surprises and I was dragged into a half day meeting yesterday. I should be done by tomorrow”.

Now consider: Who’s at fault here? If you’re thinking: “the developer, definitely the developer”, you’re a better person than I am (or you’re a manager). If you’re like me, however, you may have been thinking: “the developer did nothing wrong, software development is complex and often unexpected. All the developer did was provide an estimate. He never promised anything and he never expected to be pulled into a meeting!”

Unfortunately we’re all wrong…

Like me, however, you would be mistaken. Sure, the developer is not at fault for his estimate it is, after all, just an estimate. The state of the codebase may not be his responsibility either, especially if he’s new. However, we can safely assume he realised before the couple of days were up that he’d miss his estimate. At that point, he should have informed his manager. He should have also informed the manager when asked to attend that half day meeting, or at least ensured he was made aware.

I’ll admit I have been that developer many times. Often I’ve cursed “management” for having a meeting dropped on me last minute, pulling me in different directions, not giving me enough time to write quality code or unit tests. However, though it is management’s responsibility to support us in all this, it is our responsibility individually to manage our time, to ensure stakeholders are aware when situations change, to make time for our other responsibilities.

Most companies will perceive the role of Software Developers in a similarly broad way: to produce software – to write and review code. However, like with all roles, the responsibilities are far more multi-faceted. Below are specific responsibilities of a Software Developer that I feel are often overlooked, instead perceived as responsibilities of management.

1. Commit to Estimates

Estimates are estimates, not promises, sure. But they are used by the team, product owners, management and stakeholders to help plan releases, communications, training, budget and recruitment.

Whether you use hours, days or relative estimates (e.g. story points), by committing to estimates we not only build trust with the stakeholders, we also make ourselves more conscious of how often we actually achieve these estimates.

Being more conscious regarding our success rate for estimates allows for more accurate predictions going forward. Developers will often get their estimates wrong, but over time they will notice some consistency or at the very least identify reasons why they are erratic and find ways to mitigate this. For example: if you’re constantly being caught out by nasty surprises in the codebase then perhaps it requires more test coverage, a different design or better documentation.

2. Acknowledge Affected Estimates

There will always be things that affect our estimates for a piece of work. As soon as we feel our estimates have changed we as developers are responsible for communicating this to the appropriate members of our delivery/project team. This could be your Scrum Master, Project Manager or stakeholders. Depending on the urgency, stand-ups are a good platform for this.

This doesn’t just go for unrealised work or complexity. Sometimes changes outside of our control affect our commitments, such as a teammate off sick etc. Although the estimate for the work may not have changed, you may now realise it’s not possible to achieve the team’s overall commitment.

In these scenarios it’s our responsibility to highlight if this affects our deadlines as it may not be obvious to others. Assumptions may have been made by stakeholders or management that you’re going to work a few extra hours, for example.

3. Make Time for Best Practices

Each work-place values best practices differently. Some may appreciate documentation but see unit tests as nice-to-have, others may enforce high test coverage as part of CI but see knowledge-sharing within the team as less of a priority. Although there are common standards in the industry, even developers will naturally share different opinions on what are best practices.

Regardless of what they are, it is ultimately our responsibility as developers to ensure we have time for these best practices. When giving estimates, we need to consider how long the likes of unit tests and supporting documentation will likely take to write, any knowledge sharing required or time to research the best library or framework for the task.

Good management and support staff will protect against any external pressures that may cause us to cut corners, and may even ensure themselves that appropriate time is made by a developer. But the only person who can ensure this is done is the developer.

If questioned, we need to take the time to explain and help others appreciate the value. Granted this is difficult a lot of the time. It helps if management understand the value of these best practices, but regardless it is our responsibility to make time for them.

For Part 2, click here…

  1. Duncan Fletcher says:

    Hi Richard, good post and good points!

    For me this draws a parallel with topics often considered with an Agile approach:

    1. For estimates, it would be the whole team who provide the estimate and do so challenging each other (e.g. using planning poker).

    2. It is not the estimate a scrum team for example commit to but rather a sprint goal, comprising of stories with estimates that would sum up to the teams typical velocity.

    3. The progress towards this goal with all its deliverables is what is assessed everyday at a daily stand up and communicated to the Product Owner who is responsible for managing stakeholder expectations.

    4. The velocity of the team is more stable than one estimate. A team member being sick or on holiday has less impact on the general team velocity of course depending on the team size and length of absence especially if the members of the team strive to be cross functional.

    • Richard Ingram says:

      Cheers Duncan, great points! Thanks for taking the time to share them.

      I particular like your point regarding commitments – teams should commit to collective goals (e.g. a set of stories) rather than the estimates themselves. Estimates are simply a tool to help teams and stakeholders plan. That said, although estimates are not the ultimate focus, they should be continuously referenced when when working towards that collective goal.

      I find team velocity an interesting one. Velocity can be more reliable, but it often seems tricky to achieve if the environment, team members or the scope/direction of the project change too frequently. I completely agree it should be used for planning further ahead (weeks, months) as opposed to individual estimates – appreciating that estimates become less accurate the larger they become.

  2. Good read and crucial when leasing between multiple teams/departments. Thank you.

Leave a Reply

Your email address will not be published. Required fields are marked *