Here's why your software developers are delivering so slow.

So here’s the deal. I started listening to some podcasts related to content marketing and social media, since I want to up my game a bit.

One of the things that bothered me the most is the continuous bickering of the podcast hosts about how they avoid to go to developers because it always takes a lot of time to get stuff done with devs. So I thought I would write an article detailing the struggles of developers when they get “work” that’s supposed to be ready yesterday.

To set the stage, let me first tell you what developers are not.

Developers are not code monkeys. Software development is not just the practice of writing code that is known a priori to solve a problem and you only need to be a monkey with a very good memory and remember a lot of shit, so that you can type it into a computer and make a button green.

A whole different skill set is needed when trying to make a button green, than it is to figure out the interactions for that button and use gradients instead of solid colors to implement the “requirement”. And this is only the frontend. Forget about form validations, sequencing those validators properly, replicating on the backend, saving to a DB.

Well, you could say that work is meant to be hard and that I shouldn’t complain. I’m not. That’s my opinion, too. And I also believe that work is as hard on you as you allow it to be.

People assume developers are these lazy dudes and dudettes who hide behind the complexity of the technologies they use to justify why things are taking longer than everyone expects. And that they tend to over-complicate things so that they become indispensable to the project.

That’s communist mentality on both ends — a business owner thinking that devs are like that, or a developer actually behaving like that.

Yes, developers suck at setting expectations, but that’s mostly because we’re always pressured to give an estimate (a very short/small one, that is) and then jump directly to work.

You should understand that planning is not something reserved for the upper tier in the company. It’s not something that’s only used so that your plans as a business match your expectations as business people.

Developers also plan their work. In fact, I like the teams I work with more, if they spend an equal amount of time planning vs. doing.

Why? Because they will have more data and would have already explored more options to make more informed decisions. I also like people who can defer decisions for as long as possible. It’s always better to make decisions with the most amount of data you can get your hands on.

So what’s the problem, then?

Well, part of it is that you have a shitty culture. It’s you not having planning and feedback as core values/practices within your organization.

A software project / feature request usually starts like this: business asks for some unfeasible, ludicrous shit, they probably heard about at one of their fine dinners with competitors or partners with teams 10x larger. Next, you ask for an estimate but also mention a deadline tht doesn’t take into account the fact that you have resources blocked on other projects, the context-switching involved and other sensitive and less-obvious things. Next, developers offer a dumb estimate just to please you and then try to put square pegs in round holes.

3 months pass without communication and feedback on both ends. Developers grow more frustrated as they realize the deadline is approaching and they can’t deliver on the promise, you also become frustrated because it took 3 months for you to get a damn feature out and the market is already becoming crowded with similar features from competitors…

After an extra more month of testing, improvement and “stabilization” of the feature (we all know that means rewriting the crap devs initially wrote), it becomes irrelevant to the business and you decide to drop it. This builds up even more frustration since devs now think you are disrespecting their work. Without proper communication from you from start to finish, they will just think you’re treating them as shovel-handlers.

If you’re a developer, you might ask if this could be avoided. Yes, it totally could be!! Just talk! Speak out about it. I don’t care that your boss is some knucklehead and sometimes is intimidating. Tell them they’re wrong.

There’s a catch, though. You need to tell them they’re wrong but also offer alternatives. Give them options, guide them.

As the business owner or the person asking for the feature, treat your tech people as the professionals they are, get feedback from them and process it accordingly. They’re not providing proper feedback? Maybe you will have to teach them that. Maybe you will have to make your expectations more obvious.

The first thing I try to do when my team starts doing weird stuff I don’t agree with is I try to talk more, give them more information into what I’m thinking, offer them more context so that they can make more informed decisions. I always assume I was ignorant and I expected them to know something that was clear in my head.

I recently had a feature request from the client, on a project I’m working on, that drove me bonkers.

The client wanted us to implement a special excel export feature on the admin panel, then use that excel in a feature that would parse the file, import the accounts back, then trigger an application workflow on it, that was also automatically handled by a Cron job.

I kept acting dumb and asking “Why?”. “Why do we need this?” , “What are you going to do with this?”. I drove them crazy. I looked like I didn’t know anything about software development, I was the dumbest person in the room.

Want to know the outcome? Do you know what they needed?

A fucking button to manually trigger that workflow managed by the Cron job! On all the registered users of the website, excluding the ones already processed automatically by the Cron job.

A… damn… button!!

The moment I understood what they wanted and they understood what they needed, I replayed everything that could go wrong with their initial reqruiement, in my head, in a loop.

Us starting development on this monster just to be able to manually trigger the functionality. Something we can easily do using a button and some custom code. All that XML parsing and validating … I was ready to tear my hair off my head, but fortunately, the many years of being a father and a software developer helped me by ridding me of my hair.

To conclude, you need planning on all ends. Business, content, development.

You need a higher goal that all plans converge towards. If you want to drive in more sales, marketing wants to create a more meaningful brand and development is focused on improving the tech stack, all your efforts will burn down in flames.

You need to make work visible and priorities obvious — use a damn Kanban board! Stop usig Scrum just because you heard everyone is using it. From my experience, everyone is using int WRONG!

You need to empower people to say “No”. And take their answer as being the correct one, since they are the professionals. Don’t be like our dearly departed Ceausescu and assume that if you’re the manager of all people you also know more than they do. If they dug a tunnel on one end, trust that their judgement is sound. Challenge their decisions at every step, so that they’re able to reflect properly, but don’t ask for explicit changes, let them do course correction.

As a member of the development team, you need to know that business is not just a bunch of money-loving monkeys. They’re professionals who want to keep the business afloat and keep money coming in so you can get paid. They might also have an interest in keeping the prestige of the company, upping the service level standards.

You need to inform those people on the decisions you make on your end and make sure your decisions align with their goals. Try to talk in their language, they don’t necessarily understand your amazing caching systems and load-balancer gymnastics. But they do understand you want to save time and resource usage by storing the data somewhere closer, in a form that the application already understands. They will understand that you’re trying to offer a better user experience by trimming down the number of fields a user has to fill in to use a specific feature.

And don’t think marketing is a bunch of social media monkeys just posting to Facebook day-in and day-out. There’s a lot of strategy and planning that goes into this posting part. Creating an ad could take 1 week because they have to make sure the headline is effective. And this doesn’t take into account that they have to write compelling body copy and also choose an image that draws the eye.

Keep an open mind!

Image credits: Kanban Boards (Training) by Nadja Schnetzler, CC BY 2.0