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
- to be aware that technology is changing at a phenomenal pace
- to be aware that there are engineering processes which can help the
software development machine
- to commit to an engineering process which runs as a project in parallel to
the development project
- to be committed to making sure all its staff get the correct knowledge
they require to do the job
- to be able to take time out of the development project to ensure the
training happens
"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:
- Commitment to Perform - Senior managements
- Ability to Perform - Budget, Training, Personnel
- Activities performed - Project Team
- Measurement & Analysis - Project Team
- Verifying Implementation - Senior management, Project Management,
Reviews and Audits
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.