As programmers, technologists, and engineers, we have a collective need to solve problems. It is who we are, not just what we do. As more and more powerful tools come into use, it becomes ever-easier to grab one and start building a solution.
This can be considered a feature or a bug of our toolsets depending on how they are used. When actually building a solution approaches zero effort, the tendency is to start building immediately after encountering a problem to be solved. Building becomes the easiest and most attractive aspect of what we do. This is particularly true in the world of software development. So true, in fact, that we have started changing our processes to defer what I would consider the most difficult part of our job until after we get the satisfaction of building something and seeing it work. This is commonly referred to as “Agile” methodologies.
The Danger of Being Too Agile
Agile is very attractive, especially to the Attention Deficit Disorder-heavy workforce that gravitates to software development. Instead of gathering requirements, analyzing them, and planning how they will meet them (i.e. solve the problem), Agile encourages developers to start building with a mere whiff of an understanding of what will be built, with the idea that not only is it impossible to fully understand the requirements up front, but it is more efficient to start with something very basic and then modify it to meet the needs…a sort of organic growth of software.
Hey, I Know…Let’s Do What We Want And Call it Agile!
When I was first exposed to what was at the time considered the radical idea of Agile development, I was very skeptical. My take on it was that a group of developers got together for an all night pizza, Mountain Dew, and code session and sometime after midnight one of them said “Man, this is awesome. No meetings, no requirements, no design specifications…why can’t we get paid to code this way?” One of these developers, having been around the block a few times since he learned to write BASIC on a Tandy TRS-80 personal computer, was inspired. “Maybe we could!” he announced.
What followed was the seed of a revolution in software development. Obviously if they were going to try to get rid of meetings, design documents, and requirements and just write code, they would have to be clever about how they sold the idea. No company or manager in their right mind would agree to it in its raw, blatant form. What it needed was some magic fairy dust sprinkled in to make it appear to be legitimate.
Noticing that the only people who actually did seem to enjoy endless meetings were Project Managers, the first winning idea was to prevent him from sitting down to start with. Once he sat down with his cup of coffee and three donuts, there was no way the meeting was ending in less than an hour. This inspired the idea of a “Standup” meeting, because if he had nowhere to set down his coffee while he ate his donuts, he would want to get back to his desk as soon as possible.
Next up was requirements, What a bummer they were! Just give us a general idea of what you need and let us go build something, then you can tell us how close it is to the picture in your head. This became the “backlog”. Of course if they wanted to get this idea across the finish line, they needed something that would make it seem better to management, and they knew that to management, faster and less buggy is always better. Since they had already pretty much eliminated the possibility of bugs by getting rid of requirements to compare the end result to, and they knew that the longest a project manager could stand to let them work without seeing something pretty, they settled on a two weeks of peace and quiet in exchange for actually producing something that looked like it worked. To make it seem like it would be faster, they called it a “sprint”.
Back then I distilled the Agile methodology down to a few lines:
- Write something. Anything. A calendar. A sign-up form. Whatever.
- Demonstrate it to the client (hey, it works, doesn’t it?)
- Find out what they really wish you had built
- Repeat
Agile != Evil
It is not my intention to knock the Agile process. I have been doing software development long enough to have lived through at least a decade of pre-Agile and a another one of post-Agile projects and there are a lot of things to like about the newer approaches. What concerns me though is that developers seem to be losing the ability to approach problem solving in a structured, comprehensive way. When the tools they are using work, they are happy and when they don’t work (or they give different results that what was expected), they are stumped.
In my work at a software development center, I see this every day. A client contracts us to build a new solution and on day one, developers are building stuff. What are they building? What are they basing the design on? The truth is that very often…no, nearly always…they have no idea what they are building. They are just building something. They will figure out just what it is and what it does later. “
It’s OK, dude…it’s Agile!”
What’t the problem?
As a programming Technical Lead, I am often asked by other developers to take a look at a problem they are having with the code they are working on. Many times, in the middle of showing me the problem, they see the problem and sheepishly say “Oh. I forgot to ____________ .” My typical response is “Anytime I can do nothing for you, let me know!”
Often though, there isn’t an obvious problem. Everything looks like it should work. But it doesn’t. As I dig through the code trying to get a good mental picture of what it is supposed to be doing and what it is actually doing, I will often reach the point where I am as confused as they are. Things don’t make sense. There seems to be way to much code to do the simple task they are attempting to do. At that point I will ask the question that they have learned to dread:
“What problem are you trying to solve here?”
That question is dreaded so much because in one simple sentence, it forces them to think through the What and Why, not just the How. Occasionally they will attempt to sidestep the question with an answer like “I’m trying to make the @$#% calculation come out right!” I don’t let them off the hook that easily though. A typical response is the other dreaded question:
“How would you do it on paper?”
This is usually where I get a blank stare as it slowly dawns on them that they have spent seven hours solving a problem that they didn’t come close to understanding in the first place.
The truth is, we can’t solve any problem until we understand it. Sure, we might hit it with a stick and make it work, but that isn’t a solution, it’s a workaround. That necessary understanding can come from a dozen tiny bits of information spread across a couple of months or it can come from an up-front analysis, but either way, the problem isn’t getting solved until the person writing the code understands it. The question of how they would do it on paper forces them into a frame of mind that seeks to understand before they solve.
This comes back to my statement earlier that the easier it is to produce code, the more attractive it is just to start coding. Understanding is hard. It requires the brain to seek out the missing information and assemble it into something that will result in a legitimate solution. It is much easier to just build something…anything…and hope it does what it needs to. That almost never happens though.
A Simple Truth
You must understand a problem to formulate a valid solution to it.
Over the years, I have learned to apply this simple truth to many situations I encounter, not just writing code. When my car won’t crank, I try to figure out what component of internal combustion is failing (Fuel, Air & Fire…sounds like the name of a 70’s band). But before that information is useful, I already have to know what components of the car provide each of those and how to determine if they are functioning properly. I could just start pulling things off and replacing them, but that would get real expensive real fast and my odds of success would be pretty slim. Or I could call the mechanic and he would ask me to show him the problem and halfway through explaining it I would realize that I forgot to fill the gas tank again. So to save money and my ego, I seek to understand it myself.
The more you internalize this philosophy, the more scenarios you will find to put it to practical use. I have fixed cars, stoves, satellite systems and network servers the same way.
Simple order of operations: Understand first, then fix.