I’ve seen projects fail, and it sucks. It sucks team moral, it sucks resources, and it sucks energy from other projects. Granted, there are degrees of failure, but generally a project is considered a failure when it is significantly over schedule, over budget, under quality, ships with too many bugs, or simply never even ships at all. I wouldn’t consider a project to be a failure if afterwards you find a more optimal way, or management throws the completed project away because of new business direction – in that case the project itself still succeeded.
It’s well known, and well experienced by developers, that many software projects fail. In the 80’s or 90’s, insufficient technical skill often contributed to project failure – the mere act of programming was complicated, the frameworks still young, even finding the right syntax was challenging. Today, there are powerful frameworks, open source projects to pull from, tools to assist almost any technical problem, Google, and years of precedent for most types of projects. Some may say that mere “coding” has become so easy that it’s as if platform companies like Microsoft are trying to make all developers dumb, or at least lower the bar so that anyone can develop.
Of course, projects can still fail today due to insufficient technical skills, but most of the time these days, they seem to fail for non-technical reasons: constantly changing requirements, poor communication among teams (because today’s complicated projects require lots of cross-team coordination), scope creep, bad estimation not allowing the team enough time to do it right, insufficient development infrastructure not allowing the dev team to actually build and deploy code, bureaucratic red-tape that prevents the team from procuring the right tools, poor team chemistry that results in internal conflicts, poor project management, lack of user input, etc…
Ironically, even if the project fails for these non-technical reasons, it still shows up on the technical folk’s desk. Ultimately, some manager or business sponsor hammers the developers with “Why couldn’t you build this?” Granted, a star technical team has a much better chance to handle the rapidly changing requirements, do more work with less time, or build their own tools and infrastructure “under the radar”.
The point is to be a star dev, you must push through successful projects. A dev who only does “moderate” technology on a profitable project will be viewed as far more successful than a dev who does “cool” technology on a failed project. These days, because most projects fail for non-technical (i.e. “soft”) reasons, developers who want to be stars should invest something in their soft skills.
No comments:
Post a Comment