Software Engineers Are Wasteful Resources

Kenneth Jiang
4 min readNov 4, 2018

--

My previous post on Autonomy and Accountability generated quite a bit of debates on reddit.

Most of the criticisms I received were that I “wasted” company’s precious engineering resources on a project that failed to deliver value.

Did the project fail to delivery value? Yes.

Did the resources get wasted? No doubt.

But do I think I should have shut down that engineer’s idea so that he wouldn’t have wasted him time on that project? Hell No!!!

The reason is that software engineers are necessarily wasteful resources. Whether or not you admit it, chances are that your engineering resources are wasted one way or another. This sounds like an extreme statement, but if you have some first-hand experience in software projects, I’ll ask you to answer the following questions in all honesty:

  • How many softwares were over-engineered just so that someone can show “I’m important. I’m valuable.”? If you don’t understand this question, you should check how Microsoft would design an iPod.
  • How many lines of code were written and pushed to production only to produce bugs, not values?
  • How many lines of code were buried in the startup graveyard along with millions of dollar investor’s money?
  • How many hours were spent in meetings that produce designs or processes that are irrelevant or even harmful when the rubber hits the road?
  • How many hours were spent in pages and pages of documentations that were already outdated before being read by anyone?

The worst part about these kinds of wastes is that the leaders or team members don’t admit or even recognize them. These are the people or organizations who pride themselves for their “highly efficient engineering processes”. Every one on the team are so busy that no codes are written until 5pm, and no emails get responded to until 11pm. But the sad truth is just nobody steps up and says “We barely built anything valuable for our users. The Emperor Wears No Clothes”.

But I don’t blame these people or organizations. After all, we live in a world where hardly any businesses have stomach for wastes. The same is true for software industry. Imagine a VP Of Engineering opens the inaugural speech with “I know most of your work will be wasted and it’ll be ok”, it’d probably also be his/her last speech in that position.

But this is exactly the mindset that I’m trying to change. Software engineers are necessarily wasteful resources. The reason is simple: the nature of engineer’s work is creating something new. Since most of the creative activities end up in failures and being wasteful(do I have to remind you how many times Edison failed at creating the 1st lightbulb?), so will the softwares.

The only difference I’m trying to make is to bring the probability of waste to everyone’s awareness. This awareness is important for two reasons:

  • No improvement is possible if the awareness is not there.
  • It’s essential to build an engineering culture that genuinely embraces transparency and integrity.

Let me use an example to explain. Team A and Team B both just launched a massively over-engineered project (tell me you have never been in such projects).

Team A:

Let’s celebrate the heroic effort from everyone in the past 6 months to launch such a difficult and complex project.

Kudos to Architect John for spearheading the first React Native design in our company.

Well-deserved bonus goes to Senior Engineer Jane for fighting countless bugs.

Team B:

Why did this project take 6 months and 500k lines of code? A past project with comparable requirements took half of the time and resource. What could have been simplified?

Would we have been better off if we had decided to build a native mobile app, instead of using React Native? After all, 95% of our users are using Android.

This project wasn’t much more than RESTful APIs + a mobile frontend. Why did we end up with so many bugs? What could have been done differently?

For the engineers who don’t care too much about the quality of their work, and how big of a difference their code actually makes to the world, Team A is a much more comfortable and attractive environment to be in.

But for the engineers who want to become great at what they do, who care about why they are working on what they are working on, Team B is the no-brainer. When you get a team of such engineers, yes a lot of their work will still end up being wasted, but you have got much better shot at building something that’s actually useful.

Software engineers are wasteful resources. And it’s ok. The majority of Mozart’s 600 works were never played by anyone and “wasted”. Merely acknowledging this will put your team head and shoulders above others.

--

--