Thinking Hurts — Things That Need to Change in Software Development
It is easy to convince people to eat sugar, it tastes good. I think it is also easy to convince people not to think, especially in the context of software development projects. Decide what you want to build and just go go go!
In my post “Things Need to Change in the Software Development World”, I listed three issues I see our industry struggle with. The first one was the lack of “thinking time” provided to software developers. Below are some of the reasons why I believe thinking is avoided, and they all stem from fear.
Fear of Missing Deadlines
Developers often feel like they have to get some code written, any code at all. If they don’t, the fear is that they won’t get all their work done. Some code (even if it’s poor) is better than no code at all, right? It’s not, but that’s the conventional mindset.
Unfortunately, developers are usually held to the standard of “did you get your work done,” not to the standard of “does your code function as designed.” This creates behaviors that do not produce quality. In fact, this makes future work much more complicated – especially if you are making haphazard design decisions along the way.
Fear of the Unknown
Most developers believe that to complete some set amount of work will require a few iterations on their part. It is a fear that they just can’t write the code, they have to figure it out along the way. This is a real issue; developers are left to discern the requirements on their own while writing the code. That’s a recipe for disaster.
This is a tough issue to solve. The best thing we can do is make sure developers have everything they need. This can include having a resource they can call upon when particularly sticky problems arise. We have to do whatever we can to reduce the “have to figure it out” behaviors.
Fear of Not Having Fingers on the Keyboard
I’m sorry managers, but I’m going to throw you under the bus a bit. Developers are given a not-explicitly-spoken expectation that they should always have their fingers on the keyboard. This comes from the misguided belief that if fingers aren’t typing, work isn’t happening. Not only is this an extremely unhealthy way to see work, but it also doesn’t produce quality work. Forcing a team to work under this fear means project success as a whole is not valued. It is expecting a single successful activity done quickly. In reality, projects are made up of many successful smaller activities. Poorly-done activities will impact everything downstream.
There is no easy solution for the “thinking problem”. But when we’re looking at projects, our goal first and foremost should be that we want our project to be successful. And by successful, I mean minimal rework and well-thought-out architectural decisions, especially in complex systems. Those do not come from anyone working in fear.
If developers are just in “go” mode all the time, you should be afraid of failure (because that is what will happen). Everyone heads down all the time and constantly typing is a recipe for failure.
