Developers don’t need an office to get things done… Daily commute, meetings, and business issues actually hurt both the quality and time in which a product can be delivered. In this post, we discuss important differences between business processes that require daily interaction and communication, and remote software development that’s normally part of almost every company’s development cycle.
Working from home
Every morning at hi-tech companies starts with a string of “wfh” messages.
Developers like to work from home. Whether they live in Palo Alto, CA, Buenos Aires, Argentina, or Tallinn, Estonia, most of them see few reasons for an office commute to sit with a notebook behind a desk with 4 other people when they can do the same in the luxury of their own home.
It’s probably fair to say that every software product on the market has been developed by people who work from home at least some of their time.
What’s wrong with working from home?
If you’re a manager, marketing person, designer or in sales, there is a lot to miss if you’re not in the office. It’s harder to get approvals when you’re remote, harder to influence people, ideas don’t get developed without face to face brainstorming, and morale suffers when people are not around.
If you’re a software engineer working from home and the program you’re working on is not functioning well – what is there to gain if you’re in the office? Nothing, except complaining or sucking up other people’s time if you can’t figure it out on your own.
Almost everybody agrees that as long as things get done, there is absolutely no problem with working from any place on earth. Problems start to arise when things go wrong – timelines missed, quality skipped, tests not developed, or instant messaging not answered by people who are supposedly “working” remotely.
Paradigm shift
Since business minded people run companies, bringing people together, team building, daily interactions, enabling communication between team members, face to face discussions may seem like obvious choices to improve the software development process when things start slipping.
It is not. These remedies don’t translate to software development at all.
The software development’s goal is to create code per spec that gets executed by a computer without errors. Business goals of influencing people to buy products or sign contracts is a completely different paradigm that requires different solutions.
It may be fair to say that confusing the two paradigms is what gives executives an idea that if engineers start coming to the office more often, things will improve.
Working in the office environment hurts engineering products
Let’s be honest — managers have no idea what engineers do whether they are in the office or some place else.
Yet, there is literally nothing more objective than computer engineering. The true measure of success is crystal clear — you code runs without errors as expected. That should be the only indicator of productivity for engineers. Trying to patch things up by making the software development process more “transparent” or providing more “visibility” is lipstick on a pig when things go bad, or redundant and hurtful when software is functional.
Ironically, it is the mediocre engineers who like to come to the office and work regular shifts or even overtime. No managers can blame them for slacking off. They are often good communicators, ask smart questions, and provide clever suggestions. What code they write and how well is written is often overlooked because they are “team players” and help with the “process.”
Nothing hurts software development more than mediocracy — when it’s not crystal clear whether the developer needs to be let go or get a raise, and things drag on eating up other engineering resources and time.
If you have talented developers, they will build a good quality product
The first answer to building quality software products is talented engineers. The second answer is creating an environment for the engineers to do their best, which is often leaving them alone and allowing them to work from whatever place they like.
If problems persist, the problem is with management who can’t tell bad engineers from good ones.
