During my career I had many technical interviews. This post is about one aspect that changed over time: development process paradigm.

Twenty years ago nobody was asking about methodologies. It was assumed that the project runs a waterfall process and nothing else was considered, at least not in the enterprise world with Microsoft technology. Around the millenium change I heard more questions about the Unified Process. I remember that I was warned about the question once and the evening before the interview I tried to get more information about it. At that time the internet was not as rich as it is today, so I was lucky to find some information in one of the books I owned.

The Unified Development Process was created by the same guys who invented UML: Booch, Jacobson and Rumbaugh. The new ideas were iterations - interleaving different phases of the development process - and a clear departure from a pure waterfall approach where one phase must end before the next phase can start. Around 2000 even the US DoD stated that they prefer an iterative approach to a waterfall approach. At the same time Beck’s Extreme Programming book was published and a little later the Agile Manifesto was released.

A few years later the project requirements changed and mostly included the question, if the prospective contractor has worked in an agile project. Of course, everybody said yes. And rightly so, because all projects pretended to be agile. They were not!

I think this pretending from the start without really implementing it is the problem of agile development today. No project manager will say that they are using waterfall, but in fact they use iterations and intertwined phases of the unified process coupled with daily meetings and endlessly updated backlogs. In addition, the definition of the agile process changes as well with different nuances like scrum or kanban being taken into the mix. And XP was in the background as the pure process.

Most probably we developers are guilty as well.

I was always an aficionado of proper architecture and design, expresses in UML diagrams. Not that I want to update them when the implementation starts in earnest, but at least at the start of a projects they give an overview what is needed: requirements, use cases, high level architecture, perhaps a deployment diagram. In the 90s we called this HLD. This architecturing and design phase was the first to disappear when doing agile. Later Iteration Zero was invented for this.

Daily meetings are misunderstood most of the time. They should be - in my understanding - a quick update what a developer has been doing yesterday, what they intend to do today and optionally what hinders them if anything. Not more than a few sentences per developer. If such a meeting does not extend to a full blown one-hour meeting, the usual reply to a question of a developer is that this will be talked about outside of the meeting. Many times this outside does not exist after everybody wanders off to their desks, getting headphones on and staying in their own world until the end of the day with a short interruption for lunch. If at all, one does not want to waste half an hour for lunch if paid by the hour, just having a sandwich at the desk.

Test Driven Development is another paradigm that eventually came up in interviews about 10 years ago. The fact is that project managers demand the skills, but once developers are in the project they realize that no time is allocated for writing tests. Stakeholders see it as a waste of time: “First we deliver something, then we can write some tests to verify.” I have to say I am guilty myself of not writing enough tests, especially when using code somebody else had written. I may have worked in the wrong projects, but I can’t remember a single project apart from my own little sidekicks that even tried to do TDD. Perhaps at the start of a green field project, but soon tests were either not written or their quality deteriorated because they were not updated once code changed without changing the test first.

Pair programming is one of the XP big ideas. I personally like to pair with another developer, one writes tests and the other the code to make the test green; the next day the roles change. Unfortunately this practice is almost never implemented. Many developers are so afraid of showing a weakness that they don’t want to work together with somebody else, especially more junior developers. Once you are an old hand with lots of years of experience it is easier to show how many times you need to search on the internet for sometimes embarrassingly trivial syntax. The more junior developer will be thankful to see that the senior ones don’t know everything. The big difference in knowledge often is just to know where to look. Sadly pair programming is a good, but not frequently used idea.

One of the deficiencies in our industry is estimating the time to develop a piece of software. There are too many variables to make estimations accurate: requirements are not complete or not understood, there are no designs for implementation of a feature, developers have their own ideas or code from previous projects, developers don’t have enough knowledge of programming languages or frameworks, managers or stakeholders want to hear certain estimations. This is where Planning Poker comes in. Do not estimate the time, but the complexity of a developing task relative to other known development tasks. The problem is that the base tasks are not defined in a project or different developers have different ideas of the complexity. And what happens if customers want to have a quote before a project starts? You tell them we had a nice planning poker and the team decided it has a complexity of 55 on a Fibonacci scale, but we don’t know yet the time it will take nor the overall costs. If you laugh now or shake your head not believing me then have a look at some of the government projects for example in the health service in the UK.

Velocity is the follow-up metrics to the planning poker numbers. Add up the points of each task that is completed after a sprint or iteration and compare those numbers over time. The idea is to see the performance of a team over time, but most probably it won’t change much, because the planning poker becomes a self-fulfilling prophesy. If the velocity numbers go down, the team will increase the complexity per task and assign higher numbers and vice versa. The management practice to try to filter out ‘badly performing’ developers is the logical consequence of a misunderstood number game.

Another output from the planning poker is the backlog. There is always a manager in the agile team who has two tasks: arrange and attend meetings and update the backlog. It is actually the same as they did a few years ago with MS Project files, spreadsheets or other planning tools. Also, the practice has not changed to print out the planning and now the backlogs on lots of paper, without wanting to know that the moment they print it out it is outdated. And most developers I know - including me - think that the whole thing is a waste of time, which is a mistake. It is the practice to have wrong tasks granularity. Is it too fine, developers feel controlled, otherwise it is just an intent.

One big topic in the agile process is refactoring. This means to change the implementation to the better without touching existing functionality. It is a very good concept, although not many teams are doing it deliberately. Often refactoring is a side effect when fixing bugs, but nothing else. Management does not buy in to take a code base, review it and change it. If the code is deployed to production, this won’t happen. Of course, as developers we need to see the business side as well and explain better, why refactoring would be an advantage.

So what is left of the agile development process? If used pragmatically, it can help. Just don’t get caught up in the discussion pure vs impure.