The software industry is sinking. Software projects fail at a ridiculously high rate. Software developers are miserable in their cubicles . Companies are applying more and more duct tape in vain. Something’s gotta give.
In a 2009 industry study of software projects, 44% were challenged which are late, over budget, and/or with less than the required features and functions and 24% failed which are canceled prior to completion or delivered and never used. 24% of software projects, which represents billions of dollars and thousands of hours of time, were scrapped completely.
If the recent financial crises have taught us anything, it’s that the software industry is neither too big nor too important to fail.
Business are putting more pressure on ill-equipped development teams to deliver software full steam ahead. Meanwhile, developers are being weighed down by company-imposed anchors.
Development gets delayed by endless meetings where people drone on and on. Then there are more meetings where we all discuss why development is delayed. And no one is really interested in building good, useful software. Is this what you signed up for?
Does fun development really need to only happen on the side? On open source projects, or moonlighting projects?
With so very many smart people on the job, how did we let this gloom and doom scenario happen?
Our first mistake was to ever let non-technical people manage software projects.
Our second mistake was to let non-technical people manage the hiring of technical people.
We need a coder revolution. A grassroots movement to put smart technical people at the head of software projects and to fill up the team with other smart technical people.
This is a call to arms to all of my skilled and productive developers. Developers who have passion for their craft and are willing to fight to make it better.
We’ve waited a long time for the big companies to come to their senses, but it’s not going to happen. Those bloated corporations are too large to see their own feet, much less walk around. And the smaller companies who should know better are just angling to be a big bloated corporation.
We have to make this happen ourselves.
- Business jargon and marketing speak only impede successful software building. Let’s cut it out.
- Clueless non-technical managers have no idea what it takes to build great software. Let’s do it ourselves.
- Buzzword-riddled resumes are a preposterous way to identify skilled developers. Let’s find a better way.
- Recruiters don’t add any value to the hiring process for computer programmers. Let’s go direct.
- Talking about building software does not indicate any technical ability. Let’s show what we can do.
Great post. Definitely agree and enjoyed. While I agree on the non-tech manager point, there definitely need to be non-tech people involved in at least the design of the UI/UX. If that were purely done by techies, we’d have a lot more software products with the look and feel of 4chan. Though, it’s also dangerous to have someone design a front end if they don’t understand the technology on a basic level. What do you suppose would be the appropriate balance there?
That’s a good point and I agree that having non-programmers work on a software product is essential – like designers and good business people. The issue comes in when non-technical people (particularly ones with no relevant skillset, not design, programming, anything) are put in charge of programmers and the development of software. They tend to have no idea what it would take to actually get quality software and their attempts to do so generally kill any creativity or morale in developers.
If you’ve read `Psychology of Programming’, you know that this foolishness has been going on for easily half a century on our field. Call me a pessimist, but I wouldn’t be massively surprised if there wouldn’t be significant change in the following half a century.
Hopefully I will be pleasantly surprised. I’ll do what I can.
On the other hand, if you’re committed to making great programs, there’s only so much anyone can do to stop you.
Yep I agree with a lot of what has been posted, I sort of left actual software development and branched into other areas , but then again the same nonsense happened all over what we’re now calling “IT”.
But then again and I’m not saying this is true of all software developers/programmers but there has to be a change there too, and where its wrong we need to change the perception.
1. Stop getting into “software religion” wars at the workplace, there is a time and place for pushing for your favorite compiler/IDE/methodology. But tech types can incessantly continue to whine and complain and try to re-invent wheels that don’t need to be re-invented.
2. There is a view that there are too many “Cowboy” programmers, who shoot from the hip, unwilling to work as a team (and there is a long tradition of programmers as individualists) and won’t document their work. Here I feel is a lot of mis-perception but these types are still out there. Now sometimes they’re needed, “Joel On Software” had some good articles about “Rock Star” developers.
3. While “the suits” do sometimes get in the way as said above, they still control the purse strings. We have find ways of showing productivity and ROI in software staff to management that show the great software we can build is cost effective and on time. Doesn’t matter how great the software is if it was budgeted to be done for $100k and our greatness costs $200k, still not going to fly. Conversely we need to get the non-tech types to understand software doesn’t happen instantaneously for free.
So basically if we want to get the non-tech types to quit managing us we do have to take the plunge and understand the economics and business side of the component well and include those issues in our decision and have a rational and balanced view point from both sides of the equation to present up the chain.
Social comments and analytics for this post…
This post was mentioned on Reddit by xpensv: I just tried to post this cause I love the article
…
Another part of the solution is the “self-organizing teams” aspect of Agile development. Whether it’s in programming or some other useful field, people who are really good at doing stuff tend to have a pretty good idea of how to get it done. And they (we) don’t need a lot of layers of management to dictate the details.
You do need executive management, because without them there’s no actual product or project. There’s just a hobby or a big idea. There has to be someone who wants the project done and is willing to pay for it. And their needs are going to dictate what the finished product is for, even if they’re not involved in how it happens.
Guess what the hard part is? Connecting the “goal donor” with that self-organizing team.
Agreed with you Amber(@codeanthem).
This is also discussed in the latest post on my blog as well.
Cheers!!!
I think my comment in the other thread about ISO9000 programmer personnel units applies here too.
There are two equal and opposite problems.
The first is sometimes the rocket scientists make things that blow up (Myron Scholes of LTCM comes to mind). Smart isn’t enough, it has to be grounded in the real world, not the model.
The second is that programmers are interchangeable and that it is not an art with creativity (there is an aesthetic to programming – bad code is not merely wrong or unmaintainable but truly ugly). India or China can provide production line programming. Some are smart, but inexperienced or don’t know the problem space. Others can program but are not adept. Others require long explanation (I could have written it myself faster). Occasionally you find a rockstar, but I wonder why they are still in the haystack.
But the art is communication with understanding. Before I can write something, I need to understand what you want to accomplish. What you want to do, but also how you want to do it, and the context.
The reduction to the requirements or specification is the really hard part. Coding is trivial in comparison since it is just translating the spec.
You can use a lot of words but say nothing – great ambiguous gaps, contradictions, confusions and uncertainties, and send that out for bid. It can’t be honestly bid, but that is how it works. The low bidder wins. And everyone loses.
I’ve been accurate in my estimates. This has been less than appreciated.
But to get back to the parallel there was a lot of money in liar loans and derivatives and such. The incentives were backwards. The next quarter, the next round of financing is what mattered because the businesses are structured that way.
Mattel wants the toys from the lowest bidder in China even if they use toxic paint. The dot-bombs were intentionally pending bankruptcies created only to push out the IPOs. The next version of your OS is there to squeeze more money in a forced upgrade – does the current version do anything really better than Office ‘95. Businesses pay for slightly less crappy software, especially with a site license upgrade program.
I’ve mentioned security in another thread – snake oil and something of substance appear the same and you might not be hacked. Or like the car where the airbag has been replaced with trash – it appears OK unless you are in an accident.
1. No one is willing to pay for good software when junk that mostly works seems to be enough. If it doesn’t crash during the demo.
2. It is too hard for a business to determine if the programmer or team is good or bad ahead of time. Maybe you can help here, but…
3. If you don’t know if what is inside the box is jewelry or trash, it is better to pay for trash instead of jewelry, and you really
can’t see inside the box and you might get jewelry to your benefit.
4. There still will be personality conflicts. Some prefer frequent detail, others like to be let alone. Some are gregarious, others are wall flowers. Even if you have someone who is a super programmer, they might not get along or fit in well. If you can’t communicate it doesn’t matter how skilled.
5. The best teams take time to form and learn to work together. In the military it is called Unit Cohesion. Usually the projects assemble people and then disperse them. There is a reason rockstars keep the same musicians in the band.
The third reason I add is: The moment we, as developers realize the above fact, it’s then the time to be promoted to a team leader/Project manager. And when this happens, we unconsciously apply the same methodology that we disliked when we were developers
I agree with your last point: we do need to make this happen ourselves. I think we should start a website about rebuilding the software industry from the ground up. We could call it “Coding Revolution” or “Programming Rebirth”. Something catchy and rebellious. I would sign up for it…