This is what management is supposed to do, and what very few managers do well. The real job of management isn’t protecting their territory and schmoozing in the office, but that’s what an awful lot of them do instead of doing their damn jobs.
Engineers, as a breed, are optimistic and occasionally arrogant. They nearly always overestimate their ability to produce. Many of the good ones also have a streak of perfectionism and passion for an elegant solution that leads them to spend a lot of time finding a perfect way of doing something, instead of doing something that works. There needs to be a balance between an ugly hack that can’t be maintained and throwing away time on redoing the project over and over because you find that part of the foundation is flawed or you find another way that will probably work better in the long run, but will take much longer to implement.
And then there’s the distraction of shiny new features. Duke Nuke ‘Em’s nearly fatal path was the, “but we can do it better now, so let’s throw out most of the stuff we did before and add feature X, and graphics engine Y, with new procedural path Z” treadmill.
Again, that’s a management failure. Management is supposed to handle schedules, targets, features, and scope. If they let the focus get blurry, the schedule slips, necessary features suffer from time spend on implementing new bling that may or may not offer any real value, and bloat becomes a real problem along with everything else.
Two Steve Jobs quotes are very appropriate here: “People think focus means saying yes to the thing you’ve got to focus on. But that’s not what it means at all. It means saying no to the hundred other good ideas that there are. You have to pick carefully. Focus is about saying no.” (bolding mine)
And, “Real artists ship.”
I think both quotes demonstrate why Apple did a lot of the things they did. The iPhone didn’t have copy and paste for, what, two years? But then they implemented an approach that was regarded as about the best way possible to do C&P on a dedicated touchscreen device.
Why? Focus: they didn’t include something that they felt they couldn’t do properly. They worked on the stuff that needed doing now, and implemented the best possible approach later when they could devote more time and resources to that specific problem. And partially because of that tight focus, they generally hit their ship dates.
I’m not privy to any internal workings at Apple, but I’d be willing to bet that there was an official priority list of features at different tiers, and ship status was predicated on getting all tier 1 stuff to an acceptable level of doneness before implementing any extraneous projects.
Something that probably also helps is that Apple didn’t pre-announce things, so while I’m dead certain there were hard internal deadlines set, they weren’t beholden to an outside time schedule. That cuts some of the complexity, potential time and energy wasted on managing the interface between an outside company or companies, and also means that the right hand knew what the left was doing.
So if you want to keep a project on budget and on time you:
[ul]
[li]hire competent managers who[/li][li]create a realistic schedule and budget and who[/li][li]keep the engineers on task,[/li][li]say no to features that weren’t part of the original project unless something absolutely necessary for the actual functions was overlooked, in which case someone responsible for planning the mess fucked up and should be held accountable, and who[/li][li]deal with any of the outside concerns that suck up time and energy in project management, like multi-company interfaces, external schedules, and the like.[/li][/ul]
The only things engineers should have to deal with are the problems involved in building shit that works, and preferably works well. As much as is actually feasible they shouldn’t have to deal with people, budgets, schedules, or anything outside of their area of strength.
On the project end, you need to:
[ul][li]decide on a feature set[/li][li]stick to it[/li][li]limit complexity from the start, and prune as much as possible while building; simple code is code you can write more quickly, and is more maintainable[/li][li]set priorities and targets for the steps you need to do to implement a feature[/li][li]ship[/li][/ul]
If you know what steps you need to take, and have target dates or metrics to evaluate progress, you can find out pretty damn early on if there’s going to be a problem with meeting your schedule. If you don’t, then “it’ll be done when it gets done” becomes the prevailing mantra, and that leads to huge problems. Your managers should be riding herd anyway, but coders should also know to set aside ideas for features that come up along the way for future releases, not this one. Planning is also important. Figuring out both what you want to do and how you’re going to do it is far preferable to diving in enthusiastically like you’re building a treehouse with no plans, and then figuring out that you need more wood, some nails, and that brace you thought would work at the time is a little too rickety for comfort…so let’s pull this apart and re-use the wood for a new start.
On the other hand, I’m an industry outsider who has only gleaned this second-hand, from people who do work creating software, and in reading about the many, many failures of tech companies, so I could be full of shit. The same basic problems seem to crop up in multiple industries, though, and it doesn’t seem to me to be a unique set of problems in tech.