Building a technology startup is tricky. When your model for business success depends upon having a team of people put together tens of thousands of lines of code that, based on your experience and careful evaluation, you expect to fill a void in the market, it's easy to see why your ideal outcome and reality tend to diverge. Building a successful tech startup ALWAYS involves iteration, pivoting, and executing contingencies. Companies that are successful are typically agile, responsive to input and feedback. Companies that fail are slow, bloated, and soon out of business, or at least performing well below their potential.
Why Startups Fail
A Forbes article explaining the findings of a survey of failed business owners listed the following among the top 20 reasons why startups fail:
- Ran out of cash
- Not the right team
- Got outcompeted
- Poor product
- Product mis-timed
- Lost focus
- Pivot gone bad
- Failure to pivot
While these reasons for a business not surviving can come from a variety of weaknesses that are likely found in any particular software company - personnel fits, poor management, etc. - there is certainly a common theme. These problems as a group can be traced back to simply not being able to get done on a daily basis those tasks that need to get done to make a business succeed.
For startups, there is a race against time. In the typical startup scenario, money raised to start the business has to be put to work to create a system of profitability. If you don't put that system in place quickly enough, the doors get shut.
For software companies, this failure is often connected developers not writing the lines of code that become the app that comprises the core of a successful business. Essentially, there is a proverbial stack of digital logs that need to be cut and neatly stacked before the winter sets in, but it didn't get done in time.
Improving Developer Productivity
So there's this developer productivity thing that people in the tech industry seem to talk about a lot. Agile development methodologies like Extreme Programming, Scrum, Lean Development, and Feature-Driven Development are born out of general and specific needs to help developers keep up with demand. Well-funded technology companies have even turned their offices into work-live environments to motivate developers to essentially live at work. The more hours out of each day that a developer spends at work, the more lines of code he'll produce, the more productive he'll be.
Ideas on how to measure developer productivity are discussed and debated frequently, with no real consensus about what exactly should be assessed. However, many of the productivity measurement approaches involve looking for places where there is waste so that it can be reduced or eliminated.
Is DevOps Killing the Developer?
Python developer Jeff Knupp wrote about the problem of expecting developers to be cross-trained on the downstream and cross-stream elements of their roles. In his article, "How 'DevOps' is Killing the Developer", Knupp explains that the role of "developer" is being replaced by people who are "technology utility-player[s]". He makes some powerful statements about watering down a developer's job with other, distracting activities.
When you make developers take on other roles, you don't have anyone to take on the role of development!
...actual development becomes a vanishingly small part of a developer's job
Developing Apps for the Cloud
At Nanobox, we fully agree with Jeff. In fact, you'll find his argument fully explored in our promo video:
Compared to a decade or more ago, many developers are dealing with a much more complicated job description. Now that the cloud has become the place for legitimate apps to live, and now that scalability, uptime, and other aspects of a production app have become more significant, there is an entire new skill set that has been pushed onto what was once a highly specialized job: simply writing beautiful code.
The concept of opportunity cost is most applicable here. Simply put, whatever time a developer spends learning how to deploy to AWS, Azure, or Google Compute - including provisioning servers, setting up networks and firewalls, dealing with production app logs, scaling - can't be spent creating features, optimizing code, or helping the company meet deadlines.
This situation exists even in large, established companies, where budgets are large and stability has been achieved. However, it's even more pronounced in startups, where limited budgets and aggressive deadlines turn eager developers into frustrated, burned out "technology utility-players."
Docker, Kubernetes Make DevOps Easier, but...
The changing landscape of development has brought about the invention of lots of tools that automate one part or another of the DevOps/SysAdmin spectrum. StackOverflow and other forums are full of questions from developers trying to figure out how to do this or that with Docker, Kubernetes, Vagrant, and other virtualization technologies for apps.
But if your developers are talking about Docker and Kubernetes, what are they not talking about (or more importantly, working on)? That's right: development. To IT managers, developers talking about implementing containers or muddling through AWS documentation tends to feel a lot like waste when there is an important product feature to be finished or bug fixes that keep getting put off.
One approach to keeping developers from having to learn DevOps is to outsource the DevOps chores altogether. There are companies out there with billable people who have the expertise to create custom solutions for you. However, that can get expensive quickly.
One that I came across, opsZero, charges $15k for setting up Kubernetes with a CI/CD implementation. As nice as it is to have those chores off your devs' plates, it feels a bit pricey. For most startups, this solution is out of the budget.
Can DevOps Be Automated?
The question for startups still remains: How do we remove DevOps from the list of our developers' responsibilities?
Heroku has proven that for their customer base, DevOps can be automated. Heroku doesn't work for everyone, but it has proven that for millions of apps, DevOps can be automated.
Nanobox's existence is dedicated to empowering developers to do more. We've included enough configuration to allow developers to be in control of the parts they want to control. But for all the other stuff, we've found a way to automate it, putting DevOps capabilities in the hands of developers without a need for classes, research, and so much else that distracts from actual coding.
Guys, this project squeezes 1000s hours of Docker configuration research into a single entity...bravo!
petrosp - Nanobox User
We've priced our product so that it's consumable for startups and individual developers. At Nanobox, we feel like we've made a way for DevOps to finally be simple and affordable, especially for startup companies.
Subscribe to Nanobox
Get the latest posts delivered right to your inbox