Software development is a rapidly evolving field that got off to a very rocky start.
Conventional wisdom for many years was that software engineering should be like other types of engineering: design carefully, specify precisely, and then just build it – exactly to spec. Just like building a bridge, right? The problem with this approach is that software is just that. Soft. It’s endlessly malleable. You can change software pretty much any time you want, and people do. Also, since software can be used to model just about anything, the possibilities for what you can ask software developers to do are pretty much infinite. Want to simulate a circuit in software? Go ahead. Run a bank? No problem. Connect half a billion people to their friends? Why not, piece of cake. Not only that, but what we ask programmers to produce changes in the middle of the development, often in unpredictable ways.
This is not bridge-building.
Denying the reality of constant change doomed many software projects, for many decades, to either abject failure or huge budget overruns. So why did an entire industry hew to this conventional wisdom that flew in the face of all evidence? Hard to say. Finally, however, there has begun to emerge a new consensus: software development needs to respond well to change. In fact, it needs to be optimized for change. Nowhere is this embraced more than in today’s web start-up development community. So-called agile methods have gained currency, and the “lean start-up†movement calls for exceedingly rapid change, often automated and based on experimentation with the live system.
So we’re all good, right? Not so fast. In spite of the acceptance of more agile methods, there’s plenty of received wisdom hanging around… and most of it ought to be thrown out the window.
1. Myth: You have to hire “ninjasâ€.
The myth of the hero hacker is one of the most pervasive pathologies to be found in Silicon Valley start-ups: the idea that a lone programmer, fueled by pizza and caffeine, swaddled in headphones, works all hours of the night to build a complex system, all by himself. Time out. Software development, it turns out, is a team sport. All start-ups grow, if they experience any meaningful success. What works for a lone programmer will not work in a company of 10. And what’s worse, encouraging the hero mentality leads to corrosive dysfunction in software teams. Invariably the developers who do a yeoman’s 9-to-5, week after week, cranking out solid features that the business is built on, lose out to the grasping egomaniacs who stay up all night (usually just one night) looking to garner lavish praise. Rather than reward the hero, it’s better to cultivate a true esprit de corps.
2. Myth: Programmers need to work in quiet, without interruption.
This makes sense … if people are working on their own. Every
interruption does indeed break concentration, and it takes a while to
get back “in the zoneâ€. Some well-known software companies even insist
that each programmer have their own private office. That way they’ll
never be interrupted, right? Except that modern-day interruptions have
little to do with an actual person tapping you on the shoulder, and
everything to do with instant messaging, mobile phones, Facebook and
Twitter, email, and the music coming in through headphones that
programmers swear helps them concentrate. The reality is that most
programmers working on their own only spend a small fraction of their
day actually programming: the interruptions are legion, and dropping in
and out of a state of concentrated focus takes most of their day. There
is a solution, however: pair program. Two programmers, one computer.
No email, no Twitter, no phone calls (at least not unscheduled; you can
take breaks at regular intervals to handle these things). If you do
this, what you get is a full day of pure programming. And “getting in
the zone†with someone else actually takes almost no time at all. It’s a
completely different way of working, and I maintain that it is far more
efficient than working alone ever can be. And in fact, with the
current level of device-driven distraction in the workplace, I’d suggest
it is the only way that software teams can operate at peak efficiency.
3. Myth: Start-ups run hot, so we’re just gonna have to burn everyone out.
Working crazy hours doesn’t get you there faster. In fact, it slows you
down. Sure, you can do it for a week. But most start-ups plan to be
around for a little longer than that, and developers will going to have
to keep programming for months, if not years, to build a successful
product. Many start-ups operate as if the pot of gold is just around
the corner; if we only work a little harder, we’ll get there. Pretty
soon developers burn out, and simply go through the motions of working
long hours without any corresponding productivity. Working intensely,
for shorter periods of time, is far more effective. Pivotal has helped
hundreds of start-ups build systems, and has done it on a strict 40-hour
week.
4. Myth: Looming deadlines necessitate shortcuts.
Many software teams use the excuse of a high-pressure market and the
need to ship product right now as an excuse to do shoddy work. Writing
tests goes by the wayside; careful design is forgotten in the rush of
frenzied hacking. But software teams are no different than other teams
we’re all familiar with, and the way high-performing teams succeed is
not to lose their cool: on the contrary, when the pressure’s on, you
stay frosty, and let your training carry you through. How many times
have we heard stories of remarkable performance under unimaginable
pressure – whether it be military, professional sports, or a pilot
landing a plane on a river – and the explanation almost invariably
involves the heroes saying, “We trained for this situation.â€
5. Myth: Developers should take ownership of their code.
Ownership sounds good. As American as apple pie. Personal
responsibility, right? But “ownership†in a software team implies that
only one developer writes – and understands – each module of code. This
leads to defensiveness on the part of the developer. It also creates
risk for the business owner, since the loss of one person could slow the
team, or potentially cripple the business if they were responsible for a
particularly crucial part of the system. A much healthier process
allows any developer to work on any code in the system. Pair
programming facilitates this, because knowledge is passed from person to
person. The so-called “bus count†(how many people in your team have
to get hit by a bus before you’re all dead in the water) is a critical
indicator of risk for the software start-up. And it’s not really a bus
we’re talking about here – it’s your competitors, who would love to hire
your best developers. The more people who understand the whole system,
the stronger and more resilient your organization.
6. Myth: You need a quirky hiring process.
Would you hire an actor without an audition? You wouldn’t last long as a
director if you did. But this is exactly what almost all companies who
hire software developers do today. Usually the process involves
talking through an applicant’s experience with them. And that’s all.
Imagine asking an aspiring actor if they enjoyed their role as Hamlet.
Did you play him well? Good. You’re hired! Many famous software
companies propose brainteasers for their applicants. Some top companies
even give candidates an IQ test. The best of them run candidates
through a simulated software problem on a whiteboard. This is a sorry
state of affairs. I’m going to state (what should be) the obvious: the
only way to hire good programmers reliably is to program with them. I
run programmers though a one-hour, rapid-fire, pair programming
interview – and that’s just the start. Having done it over a thousand
times, I can score developers relative to each other on a 100-point
scale. What do I look for? Mental quickness, ability to think
abstractly, algorithmic facility, problem-solving ability. And most
importantly, empathy. Because collaboration is the most important thing
we do, and it doesn’t matter how smart you are if you can’t relate to
how other people think.
7. Myth: Specialization is essential.
Managers, quite naturally, want to attack problems by dividing and
conquering. In software teams, this often manifests as an urge to force
specialization. Front-end vs. back-end, database administrators, and
so on. Brad Feld suggests
in his blog that every team should have one “full-stack programmerâ€,
someone who’s a true generalist. He’s right, but he’s not going far
enough. Everyone, in every team, should know the full stack [Tim: read Carlos Bueno's piece here].
Why? Because specialization makes a team fragile. Remember that bus
count? Every specialist is a liability; if they leave, and you can’t
replace them, you’re sunk. Not only that, but it makes a team sluggish.
Specialists need to make their disparate parts of the system
communicate through defined interfaces. In effect, they end up writing
informal contracts with each other about how to do it. This leads to a
lot of overhead, and often defensiveness or finger-pointing. At
Pivotal, every developer works on every level of the system, from HTML
and JavaScript, to Ruby, and down to the database. And the argument
that specialists will be better at a particular layer of the system if
they’re allowed to focus on it doesn’t really hold water. The state of
software technology today is simply not that difficult. Programmers are
better off knowing all layers and how they interoperate. By the way,
another important implication of all this: you don’t need to hire for a
particular technology. Ruby programmers in short supply? Fine, hire a
Java programmer and train them in Ruby (pair programming works great for
this). Someone defines themselves as a “server-side†programmer? No
problem, make them do JavaScript, they’ll pick it up.
If they’re any good, that is.
Source : http://www.fourhourworkweek.com/blog/2011/06/07/whats-your-start-up-bus-count-7-myths-of-entrepreneurship-and-programming/