I’ve worked as a software developer for a decade and a half now. In that time I’ve had a run at management, I’ve been an “Enterprise Architect” and I’ve had th

I’ve worked as a software developer for a decade and a half now. In that time I’ve had a run at management, I’ve been an “Enterprise Architect” and I’ve had the honour to be selected to work as an external examiner for CS students for the past 6 or 7 years. I’ve spent most of my time in non-tech enterprise organisations, and recently working with non-tech start-ups that are transitioning into enterprise organisations. In my years in the public sector I had the fortune to both make an impact on our national strategies and work along some of the best talent in the Danish Software Industry, both from major software houses and tiny ones. I’ve never seen anyone make good use of estimation. Or indeed any of the agile tools. This is not to say that I haven’t seen organisations make successful Agile, CI/CD, code-as-infrastructure or any of those things operations. It’s to say that it always come with a hefty price of needing a bunch of people to do what is essentially pseudo-work, to enable the processes. In my very anecdotal experience buying and building software with over 200 different companies, and more than 200 different ways of doing project management, I’ve never really seen how any PM techniques have had much of a repeatable impact on quality or deadlines. I sometimes have to work very hard not to snicker when a teacher and a student get into the project management parts or their examinations. Partly because almost nobody does it by the books, but also because it almost never works the way the academics who came up with these process models for “how to work” intended. Sometimes it’s due to incompetence. I can think of very few Scrum Masters or Process Developers or any of those fancy titles, who actually ought to be doing that. Mostly it’s the developers who no longer want to code, for whatever reason, who end up in those situations and as they get further and further away from what produces actual value, they seem to double down ever harder on what ever theory caught their fancy. But for the most part it’s because organisations don’t really want to follow the rules they set up for themselves as soon as the rules get in the way. Yet here we are, grilling students on methodologies that won’t work. I know why we do it. It’s because nobody really cares enough about digitalisation to get involved with managing it. Which means we’re left with managing it ourselves and since every CS student gets “agile good, waterfall bad” into them, and the fact that there is a huge industry that will sell you agile training and models and processes and so on, it’s where almost everyone eventually ends up turning. Because why wouldn’t they? Then we all pretend that anyone will sign your “we don’t know what features we can finish” contract. Or that everyone basically expects your estimates and deadlines to fail. Now now, I know some of you may work in a big American tech company, where these methodologies might actually work out. Because you actually have more than 3 people working on the same thing, and may even have reasonable ways to estimate time because none of those 3+ people will get pulled away at a moments notice to “fix this issue, no. But that’s not the story of software development in general. So on a large generalising scale, things like estimations is basically a lie that we pretend isn’t a lie because business people that don’t care about digitalisation need a deadline for their finance people, so they’ll pretend they believe you’ll keep your estimate, while they secretly have the finance people set off 20-40% extra budgeting for when the estimation eventually fail. Then once those 20-40% are used and they need another 30-50%, things start to get fun. Anyway. I tend to take the “easy” road. I fairly quickly figured out management wasn’t for me. I’ll still do architecture, but I’ll never do it in a way that dictates anything by ever again, enable? Sure, but I won’t boss devs around. Mostly though, I’ll work with development and try to help teams become efficient at building software with the least project management possible. We’ll the PM people be PMs and then let them send their user stories or whatever format they want to the developers once they are deemed so ready that a fresh hire could program them in whatever way they want. Then on the programming side, we streamline as much of the process as possible so they developers won’t have to make a lot of infrastructure or coding-standards decisions, but see completely free to just work on coding. I like that, and as long as our business has enough of a need for developers, I’d encourage people to find what they like and work in that. So when the head hunters contact you, ask them what sort of processes they have, and if they say stuff you don’t like, then hang up. That way you’ll never have to do estimation again unless you chose to. At least for as long as we’re in a buyers market. Once that ends, there is always woodworking.