Background - What are we trying to fix? Programming sucks

Introduction

As an introduction to the sorts of problems that exist on projects, this article below in blue struck a chord. If you've come up through the ranks of software development as a coder/programmer we can all relate to the article below. It smacks of severe frustration, lack of control of your own destiny and the inherent knowledge that there has got to be a better way of doing things. This article is written from a very personal perspective, but probably reflects many peoples opinions at the project level.

As more and more projects fail and more money is lost, software projects are also now seriously looking at the causes, to improve the chance of success.

Found on : http://www.sdmagazine.com/sdforums/thread.jsp?forum=47&thread=9467 Posted: Feb 15, 2002 11:37 AM

Entitled In Search Of The Peopleware Workplace

So I’ve been around the block a little bit. For 9 years, I have worked in software development. Software for in-house use, for speculative purposes, for existing products with established market bases, for shrink-wrapped products, for customized products and for products that fall someplace in between. I have worked on contract, as a W2 employee and on my own. Currently I split my time between managing coders and actually coding. And in those 9 years I have learned something:

Working as a software developer sucks.

Don’t get me wrong. Development work has good points as well as bad. But development work virtually guarantees one or more of the following:

1) You will be involved with “death march” projects on a regular basis (in fact, some damn good programmers spend entire careers in this mode).
2) You will be set up for failure due to your employer’s lack of institutional courage regarding commitment to unrealistic deadlines, bids and feature sets.
3) You will NOT receive sufficient training in the job functions that are expected of you, nor will you be given the best tools available to perform those functions. Sadly, this means you will have to spend 8 hours at the office attempting to do work, and another 8 hours on your own time learning how to do work.
4) You will be made responsible (and accountable!) for things that are, by design, completely outside your span of control.

In my book, this is more than enough to outweigh the moments when you feel the rush of creation and the satisfaction of a job well done. Let’s face it, in software development there is rarely a time when you can honestly feel the satisfaction of a job well done. Your employer’s very operational behaviour hampers your ability to produce. Is this intentional? Of course not. But it happens all the same.

Just between you and me, I’m sick of this. Hence, I have decided that I must do one of four things:

1) Get the hell out of the software industry entirely,
2) Become a merciless change agent here at my work,
3) Start my own firm,
4) Try to move into management, or
5) Seek work elsewhere – preferably someplace that adheres to the values espoused in Peopleware.

What to do, what to do?

Let’s look at these.

Get the hell out of the software industry entirely.
This is far too extreme, although I have considered it. Nobody wants to become low man on the totem pole overnight, and I am no exception.

First there are the basic economics to consider – in what industry other than software development can you be sniffing at 6 figures regardless of how little work you’re able to get done? The pay/performance ratio in this industry is preposterous, but I have a wife a child to feed, and I am more productive than most (which isn’t saying much in this industry).

Become a merciless change agent here at my work.
Not to put too fine a point on it, I doubt there’s a snowball’s chance in hell that my employer is going to change just because I say so. I’ve been here almost three years (minus a brief absence) and while the methodology has changed somewhat, the institutional courage to keep us out of situations we know to be troublesome has not appeared.

Really, what keeps me here is the fact that everyone is so damned cool. It’s somewhat like going to school as a kid – school itself is only going to get so good no matter where you go, so you may as well attend with friends.

Besides, change scare people. It scares them. Trying to make people's lives better just might get me fired. Can you imagine?

Start my own firm.
In truth, I do work for private clients’ on weekends from time to time. But I’m not sure I’m prepared for the leap to full-time self employment. I’m already in a state of high frustration and burnout; self-employment takes dedication that I simply can’t muster at the moment.

Try to move into management.
This would not help or satisfy me for the same reasons outlined in above for “Become a merciless change agent here at my work”.

Besides, technically my job right now is supposed to be 80/20 management/coding. But due to the aforementioned over commitments, I always get ordered to code full-time. Augh.

Seek work elsewhere – preferably someplace that practices Peopleware-style management
This sounds like we’re getting someplace, but reality keeps rearing it’s ugly head. You see, during my 9 years in this business, I have worked for 5 different regular employers and a dozen clients on contract. I've been exposed to lots of places and lots of people. None of those places practiced the kind of management that allowed their developers maximum productivity. Not one.

And in all those places, I have never met a person who has ever worked for a place that practiced the kind of management that allows developers maximum productivity.

And of all those people, I have never met one who even knew anyone who worked for a place that practiced...well, you get the picture.

So I ask, where are the enlightened software development shops? For that matter, where are the enlightened managers of software developers? If I can just find one I'll certainly find the other.

Hmmm...perhaps finding the Peopleware workplace isn’t so easy after all. But perhaps a prospective employer doesn’t have to be all that enlightened. Perhaps it’s just has to be better than most. So what would I look for? And what should I avoid? Well...

What I DO want:
1) A high degree of responsibility.
2) Involvement in strategy issues pertaining to the business, or at least the product.
3) Responsibility for leading teams.
4) Ownership of my work.
5) A mentoring relationship with a senior person.

What I do NOT want:
1) To be the front-line coding grunt
2) Isolation from the business considerations of my work.
3) Limited or unclear paths of career progression from my current position to other positions I am interested in.

But then the problem becomes, if a prospective employer tells you that they offer the things outlined under “What I DO Want”, how do you know if they are lying to you? I took a job last years that turned out to be a classic bait-and-switch (that accounts for the 6 month absence from my current employer that I alluded to earlier) – all 5 of those criteria were promised but when I reported for work my job had suddenly transformed into scutwork that any junior-level programmer could do (I discovered later that they had been having trouble filling that scutwork position, which probably explains why I was told I’d be doing one thing but then was assigned to do another once I’d hired on. Gotcha!).

At this point in the game, I just don’t have faith left in any company’s claimed management practices.

Now, perhaps I’m too picky. Perhaps this is just the way the industry is and that’s that. Perhaps Microsoft is really the only company with enlightened management of software teams (although I doubt it). Perhaps I just need a vacation (note: in all my 9 years in this business, I have never had a vacation. I find this is common in the software business. Sick days and time off when your kid is born are NOT vacations. The occasional 4-day weekend when the holidays line up properly is NOT a vacation.), or an outright sabbatical (Mmmm...sabbatical...).

Really, it all boils down to this – I feel disillusioned. I feel disenfranchised. I don’t feel valuable. I don’t feel vital. I feel like a cog. An indistinct, interchangeable, easily replaceable, faceless cog – because that’s what software developers are treated like. And I've felt like this for 5 years.

I’m losing hope that the Peopleware workplace really exists.

Maybe it’s just a fairy tale people cling to to make it through the day, like the promise of going to heaven after you die (i.e. “If I’m very good and pay my dues, some day I’ll get to work someplace that runs smoothly!”).

Or maybe it’s just the brainchild of fuzzy-headed liberal academics who only “manage” businesses in their collective imaginations while seated comfortably in brass-riveted red leather armchairs, sipping lattes and admiring the fine office space their university provides for them.

*shrug*

I’m not sure if the Peopleware workplace really exists or not. If it does, I have to find it. I have to. For the sake of my career and my sanity, I have to find out of there are really places that adhere to reasonable schedules, allow developers to own their work, and prevent non-technical managers from dominating and belittling technical workers. Because if there’s one thing I’ve learned over the past 9 years, it’s this:

Working as a software developer sucks.

Author: Norrick

Email: ArsNorrick@hotmail.com

The article above mainly explores the dimension of the human workers perspective or the politics involved in the software development process, as opposed to the Technical reason for projects failing. He alludes to various problems in his list of four:

"You will be involved with “death march” projects on a regular basis"

Many project fail. Obviously company's do not want to air their dirty washing and failure is always seen as a negative thing or a sign of weakness, rather than a situation to learn and grow from. The statement above could be a project failing as a result of either Technical or Political/Human factors (or most probably both).

Current software processes such as RUP really only address the Technical issues. Probably rightfully so, if the technical aspects of the project aren't right then no matter how well the people interact, the software still isn't going to work. Having said that, if the people are communicating properly, then the chances of the technical stuff being resolved stands a far greater chance. There is definitely scope for extending RUP to encompass the Human aspects in a discipline called say "Communication". (watch this space)


"You will be set up for failure due to your employer’s lack of institutional courage regarding commitment to unrealistic deadlines, bids and feature sets."

The statement above falls both into the Technical and Human space. Technically this is addressed by the Business Modeling, Requirements and Configuration & Change Management disciplines in RUP. From the human perspective, it appears that management at an organisational level need to realise that a process to address these technical issues is seriously important.

While management are ultimately responsible for the project as a whole, and should do all in their power to incorporate the correct software processes, it is also up to the Technical members of the team to make sure they demand more of an professional engineering approach to the project. Management always claim that they rely on the Architects and Techies to do the technical stuff and seem to wash their hands of any involvement in that aspect of the process.

While it is right that management do not get directly involved in the mechanics of the engineering process, they must realise that if they do not have an engineering approach that can deliver the goods, budget should be found to implement a software development process that give the technical members a fighting chance of delivering the project software. Its rather like a chicken and egg problem! However the technical members of the team as as much to blame as the management if they do not use some form of engineering approach.


"You will NOT receive sufficient training in the job functions that are expected of you, nor will you be given the best tools available to perform those functions."

This also smacks of problems both the Technical and Human dimensions. Technical in that without the correct knowledge in any sphere, a team has already shot itself in the foot, before it has even got off the starting blocks.

Human in that it forms part of the same problem alluded to in the section about institutional commitment above. The organisation has

"You will be made responsible (and accountable!) for things that are, by design, completely outside your span of control."

This assertion stems from this chicken and egg concept that senior management think the Architects and Project managers are controlling the technical aspects of the project and that the project will just happen, while the Project managers and Architects actually need to sell to and have commitment from senior management regarding finance to obtain training, implement processes, obtain software development tools for the project in the small (or organisation in the large) as well as implement engineering disciplines, in order to have a chance of succeeding. See the diagram model below which illustrates this.

The senior management is in turn dependant upon knowledge of the project (or organisation) requirements of the Managers/Architects in order to understand, appreciate and buy into the enhancement of the engineering process in order to liberate enough financial resources to implement the 'Ability to perform'.

The Project Managers and Architects, rely on senior managements commitment to perform in order to give themselves a chance of being able to fund the planning and implementation of processes and engineering disciplines and plan and schedule training of staff on all areas of the process and the development languages and tools.

CMM level 2 addresses the issues discussed above in its common features which form a cycle:

See more about this in the essay on Software Process requirements

Conclusion

So in answer to the question, "What are we trying to fix?", the there are many things, but it breaks down into Technical aspects where there are numerous reasons and problems we are trying to avoid, for which many engineering disciplines can fix. See for example reference to the six best practices that RUP addresses.

It also breaks down into the Human and political aspects, some which can be resolved with better communication and training.

And finally, for goodness sake Norrick - Take a holiday! How anyone can survive 9 years of high stress and long hours like what the computer industry demands, without proper time to relax and recharge the batteries will ultimately be your downfall. Even if it means resigning and getting another job later.

Home

References

DeMarco, Tom & Lister, Timothy. Peopleware - productive Projects & Teams (2nd Edition) 1999. ISBN 0-932633-43-9

Norrick at ArsNorrick@hotmail.com, 2002.

Kruchten, Philippe. What Is the Rational Unified Process? 2000.

Edwards, Charles. Processwave. 2002.