What’s the best advice you’d give to someone younger than you?

View all responses

There once was a guy called Ed Yourdon. Ever hear of him? He was a US baby boomer (1944 – 2016), one of the early computer software practitioners. In those days, that industry was pretty small.

Yourdon made a name for himself because, rather than hacking and slashing until something came together, he developed a methodology. A disciplined approach which could be applied not just to one software project, but to any number of challenges.

It’s like, if you build a car, there’s a production line. There are a set number of steps, each one small enough to be well-defined, and Step B happens after Step A, but before Step C, and so on. Put the completed steps together, in the right order, and you have a car. You don’t just turn up with a block of steel and say, “right, let’s get started”.

This was as early as the Seventies and Eighties, when the software industry was becoming, well, an industry. By the Nineties, when I was just starting out (very much hacking and slashing my way forwards), Yourdon was famous for his methodology, and a published author because of it.

By the Noughties, I was a big advocate of using methodologies. Just using tried-and-tested, repeatable steps to try to drive up quality. Better quality = fewer bugs = shorter time to market. By that time, Yourdon’s original methodology had been superceded, tweaked into whatever happened to be the latest fashion. But they were only tweaks which worked better for some types of task than for others. The important thing was that there was a methodology in play. A production line, if you will.

At that time, I read the book above. Yourdon had this concept of a “mission impossible” project. (You could apply this concept to any industry.) One where the requirements are way too complex to fit into the time available, or the budget way too small, or there simply aren’t enough staff, etc. The book was about how to spot such a project, and how to avoid getting yourself into the situation.

No developer wants to be involved in such a project. It means cutting corners, doing things on the cheap rather than doing them properly. Bottom line, it means 20-hour working days and having to fix bugs at 3am before that 9am presentation.

And yet many developers find themselves sucked into such endeavours.

Yourdon concluded that there are circumstances when, no matter how many carrots a developer is promised, they simply need to walk away. I think his exact words were, there’s nothing an old fart like me can bring to the table.

I mean, strictly speaking, Yourdon is right. But I think he was speaking from the perspective of a guy who could afford to turn down work. I was not in that position until my early-forties. Up to that point, I had bills I had to pay every month.

But in terms of any situation, really, it’s good advice if you can afford to follow it. You have to learn to say “no, thanks”. There’s something more than money. You want to uphold certain standards, because it will make life easier going forward. For the next person, sure, but maybe even for you. In my professional life, it’s something I took on board, and it’s something I used to impart to younger developers once I started to have mentor roles. But really, forget software development. It’s good advice just for life.