San Francisco, California

People > Process

Paul wrote this lovely piece that riffs on my thoughts about why software is bad and the the cool thing about it? Paul disagrees with me! He argues in part that building great software will always require some degree of communication and planning:

I’m currently helping design a service for the Department for Education, work which I consider to the be the most rewarding of my career too. But here’s the thing: we have plenty of process!

[...] even with all this structure, I believe we are building a valuable, robust, accessible and inclusive service — albeit one built upon a foundation of government tooling and prevailing delivery-focused culture.

If I’ve learnt anything working in this industry, its that if you don’t hire good people — by which I mean not only talented in their own domain, but able to work and communicate with others — any process will soon become a crutch.

I love this kind of back-and-forth blogging! But of course I jest about the disagreement here, as Paul fleshes out a lot of the ideas I glossed over in my rant-induced post. Planning is important and communication is vital for any team, and you certainly don’t want great people working in silos. But I guess I just don’t hear enough about how the planning part of software development is to some degree a threat to the software itself, and often the process around it all is done for the sake of fragile egos. Not to make a better product.

When the process is developed by the team, like in Paul’s case above? Wonderful! Great! I’m all for it. But when the team is driven by management and people without context required to do the planning effectively? That’s when the process has become more important than the people.

And that’s when something has gone terribly wrong.