Let’s look at how most software is developed. I’m not talking about those shiny SaaS products like Slack. Those were built for developers, by other developers. No, I’m talking about the large underwater iceberg of boring software running enterprises, governments, hospitals and nuclear reactors. Real-world software. Software outside the Silicon Valley tech bubble.
How does any such development process unfold?
Step one. Businesspeople visit potential customers. This activity is commonly called market research and/or gathering customer requirements. In the end, it’s just some people visiting some other people. More importantly, the businesspeople are observers of real problems the customers face. The businesspeople don’t experience them first-hand; they only see how others experience it. This distinction is important.
Step two. After having observed customers problems, they come up with a product which attempts to solve at least one of them. In our industry, this product is software.
Step three. The specification of bespoke software (let’s hope there is one) is handed to developers who shall implement it. But wait, you’ll say, those developers have never been exposed to the problem they ought to solve – they’re relying on descriptions by businesspeople who themselves only observed other people experiencing it. And how long did they do that? An hour between drawing Powerpoint slides, maybe?
You don’t have to be a developer to realize that this process is flawed. Developing the wrong thing is one of the main pitfalls of modern software development.
Luckily, Agile Development came to the rescue, putting more emphasis on iterative software design with more customer involvement. As Steve Yegge accurately points out, Agile Development is all about giving developers revenge: Now it’s their turn to treat businesspeople like infants.
They introduced stand-up meetings so that people would talk to each other. Okay. They involved the customer regularly by forcing one of them to sit in developer meetings. Fine.
And it worked – sort of. Software development has become more iterative. We still develop the wrong thing and miss deadlines. But now we notice earlier.
But the core problem still remains unsolved: A huge amount of human overhead is lost to communicating. And most of that communication is a feedback loop whether developers are developing the right thing.
What if we could have a stand-up meeting in your head, with infinite bandwidth, every few seconds? What if we could get customers feedback on every subtle UI change instantly?
Enter the full-stack person. Not to be confused with the full-stack developer. While the full-stack developer covers everything from frontend to backend, the full-stack person covers that and everything else, too. Everything. Because he is the customer – and the developer.
The full-stack person is a jack of all trades – enough trades at least – and an expert at nothing. He has been sufficiently exposed to the problem to be solved; he knows exactly what a product must deliver to be a great solution. He’s a sufficiently good coder – not a master – but solid enough to whip out a Rails app and deploy it in a matter of hours.
Efforts for developing a product can roughly be grouped into the customer/problem side which is concerned about solving the right problem the right way, and the tech side which ensures that the solution is implemented correctly.
On the customer/problem side, this means that the full-stack person must have significant work experience in the field of the problem. Best case, he’s still working there. Imagine being treated by a doctor who discovers a bug in his hospital’s software and comes back the next day having fixed it himself.
On the tech side, this means that the full-stack person must get things done, fast. He can’t allow himself to get sucked into bike-shedding technical details: Anything which slows down rapid implementation is strictly prohibited. Copy-pasting error messages to Google must yield fast and actionable results. Single page apps are verboten, no native iOS / Android stuff, DevOps shouldn’t exceed Heroku or nginx with something else, hell, if it can be done in Rails, use Rails!
So, how does the full-stack person compare in real life with the traditional team of businesspeople and developers?
While the businesspeople are visiting customers and searching for problems to solve, the full-stack person already knows which problem to work on and is thinking about solutions.
While the businesspeople come up with various solutions and iterate on them by presenting them to customers each time, the full-stack person can try out any solution in his head in a matter of seconds. He can lie in the bathtub and think: I have this new idea. Will it solve the problem? A few second later, he knows.
While the businesspeople are busy writing user stories and giving the designer instructions for mock-ups, the full-stack person already has a working MVP. It’s unpolished, but it’s a product.
While the designer is busy designing things which developers are subsequently busy with translating into HTML and CSS, a matter of days, the full-stack person just designs things in real-time by editing code directly, in a matter of seconds.
While the businesspeople are tied down in repeat meetings with developers to monitor progress and no one has a clear sense of when the product is done, the full-stack person knows this instantly. Every night before sleeping, the full-stack person has a five-second meeting in his head, reviewing his progress.
While the developers don’t fully understand the problem at hand and start coping with this crisis of purpose by focusing on technical details which are irrelevant (“Let’s model it as microservices! It must scale!”), the full-stack person uses battle-proven, withered technology that gets the job done with minimum effort and risk.
And that’s by far the most efficient way of building things. But actually, efficiency isn’t even the primary goal; efficacy is, solving the problem, building the right thing.
Once you become a full-stack person, you’re not building software for others, you’re solving problems for yourself.
If you’re not one of those and all you can do is code, just approach it from the other side: Immerse yourself in a field which is far away from tech. You won’t believe how many low-hanging fruit there are out there – technology-wise, our world is still very underdeveloped.
In a world in which people are becoming ever more specialized while losing sight of the big picture, we need generalists, not specialists, to get things done. We’re already moving in the right direction by making programming more accessible. Let’s hope that, gradually, a new generation of developers will emerge: People from non-tech fields who’ve taught themselves to code for solving their own problems. Full-stack people.
Leave a Reply