When I graduated (many years ago!) my first job was as a Developer. I was one of about 90 developers on a multi-year project (I think it was in its third year when I joined) and my role required me to churn out code according to the detailed design specification. Follow the design, turn it into C code, make sure it compiled and passed some basic tests then throw it over the wall to the QA team. You won’t be surprised to hear that the project was not a success. In fact, when the company was sold about four years later the new owners discovered two other very similar projects had been underway for about the same time, and none were close to done.
Rather than point out how things could have been far better if they had used an Agile approach, I want to explore how the role of the Developer has changed. Even though we may still use the term these days, the expectations of a Developer have grown significantly. Writing code is just part of the job; as a Software Engineer, the expectation is no longer that of an individual following a design doc and converting it into code then handing it off to the next group in the chain. I’ve seen many argue (and I would agree) that coding is the least challenging part because it’s often what comes naturally as well as being the focus of most training.
Coding is still important, of course, but it’s not where most Engineers need help. Engineers are expected to participate right across the software development lifecycle. They need to be able to talk to their customer and understand the business needs; this used to be the Business Analysts’ role, who would spend a long time learning the domain’s terminology and nuances. They need to take that understanding and merge it with their knowledge of the system; this may require thinking like an Architect, to see not only how to get from where we are to what’s needed to address this particular problem but also to consider how that could impact aspects of the wider system, and even whether that direction is in line with the organisation’s overall technical strategy.
Now they need to implement that design, ideally writing tests first but if not then at least developing tests whilst creating the code. Producing small, testable, incremental steps towards solving the problem; don’t forget to check in with your customer to demonstrate the work in progress and get feedback…