Why developers at Google consider Agile to be nonsense?

Responding to a junior developer who asked “Why developers at Google consider Agile to be nonsense?”

I said,  because in practice, “agile” is code for sloppy thinking & lack of design. Code first, think later. It’s also great for giving managers metrics they can report against that sound good (e.g, “tickets closed”), while not having to show real results – like sales, or lawsuits avoided.

Ok, let’s start with the four principles from the Agile Manifesto. The mindset of a hacker, not an engineer. You wouldn’t even think of applying them to a construction project – buildings would be falling down all over the place (if you could get approval to start construction, without detailed plans to approve), and all involved would be spending most of their time in court.

  • Individuals and interactions over processes and tools: For any complex piece of software, one needs to be very disciplined about pinning down design details (e.g., interfaces), about configuration management, about testing, etc. All of those are process intensive activities. The work can sometimes be reduced by good tools (e.g., a good version control system, automated build/test).
  • Working software over comprehensive documentation: A rather poor dichotomy. What does “working software” mean, without documented specs? How does one install, use, interface to, or maintain software without comprehensive documentation? Personally, I’m a big proponent of “write the documentation first” – otherwise, you don’t know what you’re building, or buying.
  • Customer collaboration over contract negotiation: Again, a poor dichotomy. In a lot of cases, contract negotiation IS collaboration, and/or defines the framework for collaboration. If you’re in business, particularly if you’re building custom software, the absolute last thing you want to do is spend a lot of time coding, only to have a customer tell you “that’s not what I meant.” Collaborate over use cases, storyboards, test & acceptance criteria, transition plans – but be damn sure to get to an agreement over what goes into a release, and how it’s going to be accepted, before starting to write code – otherwise you’re going to be out of business very, very, soon. (Might I add, that almost all companies try to insulate developers from end users. It’s kind of hard to actually get anything done if you’re spending all your time responding to support calls, or “can you just change this one thing?”)
  • Responding to change over following a plan: Yes, things change. But by and large, this says “code first, think later.” That’s just sloppy. If you’re fighting a war, agility is critical (“no plan survives first contact with the enemy”), or if you’re playing basketball. But if you’re writing software, you’re a lot better advised to “plan the work, then work the plan” – and if things change, change the plan. (One might note that most of what pass for “agile methodologies” – such as scrum – are really planning processes, just ones with very short time horizons.)

By and large, “agile” is code for laziness in up-front design. Just fix the bugs & add features in future releases. Sometimes, that works – Microsoft has been very successful in shipping quickly, then fixing things later. It also works fairly well for periodic releases of mature software (fix some bugs, patch some security holes, add a few features). And, it’s absolutely necessary if you’re responding to a security attack, at the moment.

It doesn’t work as well if you’re building buildings, or mission-critical software (no, we can’t recall the spacecraft after it goes off course), or laying rail tracks from the coasts, that have to meet in the middle of the country. Or if you’re a large team, building 100s of modules that all have to fit together – you’d better get the architecture, interfaces, and databases all pinned down well before writing a single line of code. Otherwise, you’re just going to have to do lots of re-work down the line, and God help you if you want to add new features, without having well-defined hooks built in from the start.

And then there’s: Dilbert Comic Strip on 1993-05-04

Why do programmers wear headphones while working?

There is one critically important reason to wear headphones while programming. When you understand the impact of this, it will change how you think about what it means to make things and what that process really requires.

Programmers wear headphones so that they won’t be bothered. That much is pretty obvious. The reason why being bothered is an issue is something I’ll get to in a moment.

You see, the modern workplace is designed to ruin programmer productivity. If I were to design an office space to maximize programmer output, it would look like the opposite of nearly every modern office space I’ve ever worked out of.

Actually, I now work in an office that basically maximizes my potential output as a programmer and it really does look like the opposite of most modern corporate offices.

The big gimmick right now in office space design is “open office spaces”. This is designed to improve collaboration (as if that is the great problem of modern work).

Open office spaces really exist so that it looks like everybody is busy working. It looks cool to see so many people busily walking around, talking, and in general looking busy. There is a sound component to it as well.

Open office spaces are loud!

But again, it looks and feels like an improvement over the previous decades’ bad idea – cubicle farms.

Also, open office spaces are cheaper than cube farms, so companies are saving money while making everybody look busy (even at the cost of huge productivity decreases).

In general, all of this is terrible for the actual act of programming.

The art of programming tends to rely on the same thing most art relies on – flow.

Getting into the “flow state” where you are focused on a problem deep enough to make connections and leaps and do your best work without “thinking” is where the real magic of programming happens. This is very similar to playing music, writing, and painting.

Imagine if Leonardo da Vinci was expected to paint the Mona Lisa in an open office space while his coworkers and manager would stop him mid stroke every 15 minutes to ask a question. Would he have ever painted it?

No, I don’t think so.

And yet, programming is a creative process that requires a similarly creative environment as most other art does.

Take authors as a similar example. Stephen King doesn’t “collaborate” to write his books. He sits down at the typewriter or keyboard and starts writing. Imagine if he had to do a daily standup about his latest few pages each day with a committee of his peers.

His work would suffer.

It turns out that to code well we rely on that same kind of process of getting into the flow and doing creative work with our minds. It’s how our brains seem to be wired for creative work.

People like Paul Graham have written about Makers Schedule vs. Managers Schedule before with a similar understanding.

It takes something like 5–30 minutes to get into a flow state. If uninterrupted, time distortion kicks in and a couple hours fly by and a bunch of code is created.

Every interruption resets the clock on that process.

So, what programmers need to maximize flow (and thus output) is blocks of 2–4 hours without interruption. Ideally, a whole day without interruption would allow for as many as 3 or 4 blocks of “flow”.

As near as I can tell, the average programmer tends to only get maybe one flow block a day. Sometimes a really diligent programmer will manage two or three flow blocks a day, but that doesn’t happen very often from what I can tell.

Headphones, especially noise canceling headphones (like the ones I’m wearing right now), are an effort by programmers to block out interruptions and stay in a flow state.

With open offices, email, slack notifications, coworkers tapping you on the shoulder, and so on…

It’s almost impossible to get to a flow state as a programmer.

So, my advice to you is simple. If you are a programmer trying to maximize the total productivity and flow blocks each day, wear headphones, avoid meetings, don’t check email, turn off slack, and basically go into a cave and write code.

And if you don’t have the option to do that, accept the fact that you might only be able to get one flow block a day and plan accordingly.

The typical stages in the career of a software engineer?

The career of a software engineer is not an easy one. It’s a tale of hardship and woe, filled with ladders to climb, and management to appease.

Level 1 (0 – 2 years):

You just graduated from college, a young boy with a young boy’s dreams, big eyes and a thirst for life. You start your work hoping to change the world, invent the next big app or make enough money to retire young and spend the rest of your life on exotic beaches, sleeping with models, who have a thing for nerds.

The first few months seem very alike, you’re assigned the same tasks every day, and your only job is not to screw up big time. It’s not what you were hoping for, giving your superior level of intellect and mad skills on the keyboard, but you’re certain that soon enough things will change.

You wake up one day after two years and realize that you’ve been living the same day and writing the same code over and over again. It makes you sad, but you feel a wind of change coming.

Level 2 (2–5 years):

You’re no longer a junior developer now, you’ve been promoted to a full-blown software engineer, basically a rock star, without the money, women, and fame.

You’re no longer being supervised by that old mean engineer who hates you because he knows you’re a better coder than he is. You’re being assigned small tasks, which you accomplish flawlessly -most of the time- and you can finally start feeling valued and useful. Everyone respects you now!… right?

Level 3 (5–10 years):

You’ve been doing this long enough now to be called a senior developer and assigned your own team. You’ve long have given up on your dreams to change the world, sleep with models or even make the next big app, after years of seeing people try to do it and fail, and having tried yourself to launch something and failed at it too, though you wouldn’t admit it, and hide behind the excuse of not giving it much attention or that people are not ready for your creation yet.

On the bright side, you get to handle big projects now and manage your team the way you want to. You also make a lot of money, which is what you always hoped for! But on the downside, you’re honestly not into coding that much anymore, your team is a bunch of brats who constantly think they’re better than you, without realizing you’ve been helping them grow all along, and you’re very sure they see you as the old mean guy who’s there to make their life hell, oh! And although you do make a lot of money, almost half of it goes to pay the rent or mortgage, because you had to move to an expensive city to get a big offer.

Level 4 (10–20 years):

At this point in your career, you have a choice to make, either you join management and become another suit who’s only concern is cutting corners to save money, and to meet this quarter’s earnings expectations, or to continue being a developer, who’s work now consists of managing multiple teams and making sure everyone’s doing their job.

You were always a rebel, you chose to code because it gave you freedom, heck, you wrote your best lines listening to Rock and Roll, so I’ll assume you’d go with continuing on your path as a developer.

It’s been years since you enjoyed coding or even went to the office excited about something. Last night you looked in the mirror and saw your empty dead eyes looking back at you, and you couldn’t help but remember the young boy with dreams and hopes who came into work with a big stupid smile and shiny eyes, and you decide to do something about this. You realized that just because you didn’t get everything you wanted, it doesn’t mean that your life or career was not fulfilling, and maybe its time for you to move on, and to start giving lectures or maybe even take a teaching position, to make sure that the newer generation does not end up the way you did.

Level 5 (20 years+):

At this point, you discover that you’ve been granted the powers of an almighty wizard, by the benevolent gods of coding. You magically turn to 24 again and have a spell for infinite money.

You get your happy ending after all, and you spend the rest of your life on exotic beaches sleeping with models.

What are the downsides to a career in software development?

The career has some similarities to the career of a professional athlete – it is very difficult to stay in the role for your entire career.

There are multiple reasons which are subtle and are not anything as simple as “older people can’t keep up” (absolutely not true).

Closer to the truth is that the industry really doesn’t have that many projects and leadership roles in teams that are creating the grand, new “something” from a blank sheet of paper. Rather, the vast majority of the activity is bug fixes and small tweaks to big blobs of legacy code. Most managers who are hiring for these roles would rather hire younger people who are still learning. Although this attitude is frustrating if you are an older person applying for the job, the attitude is not “evil”. Rather, if you are a manager and you have a lot of repetitive, banal work to do, you will naturally want to hire someone who is happy to have the work – and that would be someone young and inexperienced who is just starting to learn the ropes.

What about startups? Well… most startups involve trying to create something out of nothing and the particularly non-existent nothing tends to be money. Naturally, such startups love to hire inexperienced, young talent, feed them a grand dream of the wonderful life to be, hand out rolls of stock options (conveniently sized to fit in your bathroom’s toilet paper dispenser) and work that young talent 80 hours per week. If you are an older, experienced professional and you already have a linen closet well-stocked with such rolls of stock options, it is really hard to fit into this sort of organization…unless you are the founder and are the one handing out the rolls of stock options.

In my experience, very few software engineers really make it all the way from college to retirement with their hands still on the keyboard hammering out code. Somewhere along the way, the vast majority of them become managers, go into marketing, start selling real estate, found religious cults, get MBAs, or otherwise disappear from the scene.

In summary, my view is that if you are embarking on a career as a software engineer, you need to think about two phases: the first phase in which you actually write code, and the phase after that in which you do other things.

Hope this helps.