Where Startups Get It Wrong - What We Know from Software Engineering Research

I never fail to be amazed by the very basic aspects of software engineering that startups get wrong. And we’re not talking a little bit wrong here - I’m talking just plain staggeringly wrong. People always ask me things like “How do you know that?” or “Why are you so certain?”. Well, it really isn’t hard: I read and I read everything I can get. I’m an absolute book-a-holic and here’s what my wife says about it: “If I ever die, well, it will be in a bookalanche; crushed by all your books”. Or as I describe it, I’m seeking a 12 step program “I’m Scott and I have a problem (picture a chorus of similar book nerds answering ‘Hi Scott’)”. I read everything I can find on software engineering, startups, histories of high tech companies and the like.

One of the things that most startups don’t realize is that computer science is an academic discipline and that it is extraordinarily well studied. All aspects of it are well studied including things like engineer productivity, working environments, test coverage, pair programming, etc. Personally I started attending ACM (association of computing machinery) conferences at age 1987 with the first conference on hypertext held in Fall ‘87 at UNC Chapel Hill. I’ve always been aware that software engineering was an academic discipline. Here were some of the experiences I got at 19 from that conference that set all of this in my head forever more:

• The keynote speaker there was Fred Brooks who is the author of the Mythical Man Month (TMMM). TMMM is an essential read for anyone in the startup world because a huge amount of everything we know about practical software engineering came from TMMM. Now given that TMMM talks about the development of the IBM OS 360, a mainframe operating system, you might think “Poppycock! How can that possibly be relevant”. Well we’re still sitting at keyboards and solving hard problems - that part has never changed.
• At a cocktail party, I got an explanation of Booyer Moore string searching from Jef Raskin who had just implemented it in the Canon Cat
• I got to eat lunch with a bunch of engineers from Bell Labs when it was still bell labs

This experience made it clear to me that software engineering wasn’t just hacking out code on a PC. And even tho that is all I was at the time, I realized that it was a discipline and it was well understood. Ever since 1987 I’ve held the ACM in high esteem although my membership is rarely current. A personal high point was being published in Communications of the ACM on Hypertext Quality Control (just a citation; its long since offline).

What Startups Get Wrong

So here’s the meat of the post. I’ve written it in bullet form for brevity. And there are lots and lots missing. At some point I’ll loop back

• Office Environment. I don’t care what anyone says about open plan offices fostering creativity, etc. They are flat out wrong for any kind of serious software engineering. Software engineering, at its core, boils down to “Think a lot; type a litt;e”. And that first part, think a lot, is where the real work gets done. For the past several weeks I’ve been intensively involved in design work on a large port of an existing application onto AWS. We’re finally moving off classic hosting and into the cloud. During the period of time I’ve written less code than any same duration period in the preceding 6 years. There is no way that you will ever convince me that the amount of thinking that was necessary would have been facilitated by an open plan office. One of the very reasons I work remotely for all my clients is that I don’t believe in open plan and that’s the way of the world. This is one of those things that @joel / Fog Creek Software gets right and I suspect its one of the key factors in his success. He’s also from Microsoft which also gets this right (or at least has historically; I may be wrong about current Microsoft).
• Eye Strain. Even if you accept that open plan offices foster creativity, there are still things you can do wrong that brutalize your engineers. I once turned down a well paid, full time SF position in the podcasting area, with the opportunity to work for one of the people I like best in the industry based on nothing more than desk position. Why? They had a beautiful loft office in San Francisco with all the engineers lined up in a row. And the sun beamed straight onto every engineer’s display like Apollo himself was riding in his chariot. There was about a 3 hour period where you would just squint mightily. I already have bad eyes thank you very much. I’d put good odds on these things being true:
  • The rate of code commits was lower in the morning
  • The quality of code commits was lower in the morning
  • A lot of people didn’t work in the morning
• And, yes, management there proudly showed me their offices. They couldn’t stop beaming about them. I looked at it and wanted to run away as fast as I could.
• Misunderstanding their costs. The concept of fully loaded cost for an engineer is basic accounting and its simple. You take your salary for an engineer and you multiply it by 1.5 (or 2.0 depending on your benefit structure). 1.5x salary is generally what it costs you to employ an engineer and that includes vacation, benefits, equipment, etc. Let’s you have a 6 person engineering team with everyone making the same $125,000 salary. So your cost per engineer is 125,000 * 1.5 or $187,500 per person. Since these are full time people they get vacation so you divide that by 52 and you get your cost per week or $3605 per week. Now multiply that by 6 and your cost for your engineering department is $21,630 / week. Now, here’s the hard part. Go to the bank and take out $21,630 dollars and put it in a fireplace and burn it. Guess what – that’s what it means when you have an unproductive week in your engineering department. I can not tell you the number of places I’ve seen engineers sitting around and waiting for specifications. I don’t care whether your financing came out of your own pocket or from venture capital but if you don’t have the hutzpah to burn $21,630 in a fireplace then you should never have engineers waiting on specifications. And if you’re a product manager then I’d strongly encourage you to read this paragraph about 3 times over until it imprints on your brain. Because product managers don’t typically report to engineering the concept of what an engineer costs is obvious but not something that they think about. A product manager doens’t see the engineering budget and the \($ for an engineer doesn't come out their pocket so this isn't easy for them. Personally I always look at week of an engineering team and ask myself - "Welp. Was this week worth X\)$?” And if it wasn’t I want to kick myself. Oh and there’s also opportunity cost which in a startup is even greater than explicit out of pocket cost…
• We’re moving too fast for process. I cannot tell you how many times I’ve heard this. Yes I understand a full scrum approach may not be right but without some kind of process all you end up with is inefficient hacking where people are given conflicting marching orders three times a day. You don’t need Jira for process. Just some kind of basic ticketing system will do and a commitment to use it. If you don’t want to spend any $$$ then there’s always Github Issues which is free with your github account.
• Agile Velocity is a Myth. Well that’s not entirely true. That’s the dramatic, get your attention blog version. The real truth is that agile velocity only works when your team is large enough that the number of people in the team smoothes out any blockages that stop progress dead. When you have a small team, say 4 people, one person getting stopped on a tricky issue effectively nukes your agile velocity. I’d thought for a long time that I was being my reactionary self on this one until Winston, in a recent interview with me, confirmed it in the context of even a large team.
• Intermixing Departments in Shared Environments. Similarly to shared office space, you often see engineers intermixed with marketing staff, sales or other people. And those people talk whereas engineers tend to prefer quiet. And you know what you see then – noise cancelling headphones everywhere – so then why are people sitting together if they’re just going to tune everyone else out.
• Large Monitors Matter. The current trend of giving every engineer a laptop and saying something akin to “Go forth and code wherever you are” is baffling to me. It is well understood that large monitors improve productivity. So why would you ever want someone to work solely on a laptop without a decent monitor. Which brings us to the next one…
• Work in a Coffee Shop. I understand the actual value of changing your context and a laptop does allow that brilliantly and there are times when you actually need that but if you truly believe that an engineer’s productivity improves with a proper environment (less noise, big screen), why then would you so willingly accept people freely choosing to work in less productive environments? And I don’t mean to sound like a control freak here but if someone on your payroll said it to you this way: “Hey Boss, I’m going to choose to be less productive today and you’re going to still me my full salary, that’s ok right?”

There are literally dozens of other things I could point out on this topic and I’m sure I’ll return to it. Honestly it is just like Santayana said - if you don’t know history then you are doomed to repeat it. I see so many startups that never bothered to learn anything about software engineering start from ground zero. All of this stuff is written down and all it takes is reading. I will admit that it is very hard to find an academic program which teaches a course like “Practical Software Engineer, The Good Stuff”. I suspect there’s an opportunity there.