Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

Politics-Oriented Software Development

By TheophileEscargot in Technology
Fri Jan 28, 2005 at 11:53:03 AM EST
Tags: Software (all tags)

A brief guide to software development in the real world. Aimed mainly at new developers: experienced programmers already know most of this. This guide is for hands-on programmers, not managers.


Most textbooks and methodology guides start with statistics proving that software projects are disastrously prone to failure. I'll take that for granted.

They then propose complicated rules designed for a fantasy business world where cooperative workers idealistically work towards the common goal of maximizing shareholder value.

A couple of weeks in a typical office should disabuse you of that. Real world companies are made up of individuals working for their own goals: career advancement, more money, or just the chance to slack off. Occasionally it may be in someone's interest to build a successful project. Usually it's more useful to sabotage it.

This leads to the real reason for the perpetual software crisis:

1. Most software fails because it is designed to fail

Why you should want your project to succeed

A developer rarely benefits from the failure of his project. There are exceptions, such improving your resumé by choosing bleeding-edge technology that may also cripple the project. However, few developers escape the consequences: they may be stuck maintaining an inadequate system long after the project manager has moved on to better things.

In addition, since management is a less specialized skill, it is easier for a manager to change jobs than it is for a developer.


There are two kinds of sabotage: deliberate and incidental.

The direct manager of a project has an incentive to see the project succeed. As we will see later, he may also have incentives to make the project fail, but generally he wants to get it working, at least in the short term until he gets promoted.

In most companies, promotion is competitive. This means that the direct manager's competitors have an incentive to make him fail: deliberate sabotage. This tendency is most prevalent in non-software houses that have several teams of in-house developers. It obviously doesn't arise if there is only one software development manager, and in software houses the chance of expansion renders the competition less fierce.

Because everyone has to pay lip service to the good of the company, deliberate sabotage has to be disguised as incidental sabotage. Nevertheless, be aware that it's a good idea to keep sensitive information, such as estimates and necessary purchases away from potential rivals. Beware of casual conversations with the enemy.

2. Loose lips sink projects

Incidental sabotage is more widespread. Anyone who has input into the project will be working for their own ends. Examples: the legal department want to make things safe for them by insisting on huge legal disclaimers at the expense of usability. Designers want to maintain an impressive portfolio by using flash displays at the expense of bandwidth and small footprints.


Some early software methodologies advocated a 40-20-40 model: spend the first 40% of time on analysis and design, 20% of the time building the system, 40% of the time on testing. Modern methodologies tend to focus on incremental development: build a prototype and continuously improve.

Neither of these are acceptable to the business commissioning the project. Accounting want to know the cost of the project when planning the fiscal year. HR want to know how many people to hire or fire. No-one is going to authorise 40% of a project's likely budget to find out what it will cost to build. No-one is going to sell the idea of building a system first then finding out exactly what it will do later.

Therefore, you will continue to develop the traditional way: take a guess based on inadequate analysis and pray that you've padded it with enough contingency.

The project will probably overrun, but see incidental sabotage: that's not the accountants' problem.

3. Don't trust the analysis


As the system is being built, the consequences of the poor analysis will show up: requirements will become more complicated than you thought.

Fortunately, due to incidental sabotage, much of the functionality will be unnecessary. At some point, you will need to descope: reduce the functionality so you can finish the system. There are two aspects to doing this successfully:

4a. Descope early

As soon as possible in the project, try to work out which features will be cancelled. For every requirement, get some explanation of why it's there. From this you can often identify the important bits: build those first, and structure the system so the others can be added if necessary.

4b. Admit descoping late

While you should actually descope as early as possible, you should admit you've descoped as late as possible.

First, the person who identifies a problem is usually blamed for that problem: kill the bearer of bad news is the principle. Second, admit it too early and people have the chance to add more pointless requirements: it's safer to wait until there's panic in the air. Only propose descoping when the project is already behind schedule.

Also remember that someone who points out a problem early is a troublemaker; someone who fixes a problem at the last minute is a hero.


It can be useful to make your architecture reflect organizational lines. If one team is likely to be unreliable, try to make them responsible for an isolated module of the system. If possible, make the rest of the system work independently of it. In any case, make sure a failure there cannot be blamed on something else.

Be aware that architecture charts can give management incorrect ideas about where the workload lies. Consider this diagram:

 +----------+   +-----------+  +-----------+ +------------+  +----------+
 |   GUI    |   |   Docs    |  |  I/O      | |   Data     |  |  Utils   |
 |          |   |           |  |           | |            |  |          |
 |  Alice   |   |   Alice   |  |  Alice    | |    Bob     |  |  Alice   |
 +----------+   +-----------+  +-----------+ +------------+  +----------+

On showing this breakdown to any given manager, it will be clear that Alice has taken on the vast bulk of the project work, while Bob is basically slacking. Bob cannot explain to the manager that designing data structures for this project is the most difficult component, and the rest is trivial. Additionally, any undue progress made by Bob on the data structure can be sabotaged by Alice at any time by changes to project modules under her control

5. Make sure architecture assigns blame clearly

Managing Management

The manager of a project usually wants it to succeed, but not necessarily in the same way as the developers. The project manager only needs it to work in the short term: he doesn't care if it's easy to maintain. However, an unmaintainable project can be a trap for a developer, who might spend years making tiny changes.

There are also circumstances where the project manager benefits from doing things the wrong way. A manager gains status from the size of his team: it may be advantageous to enlarge the project.

It can help to keep an eye on any magazine subscriptions held by the manager. Try to disparage technologies you don't want to work with, encourage useful technologies.

The goal of meetings, as far as the manager is concerned, is to appear in control and abreast of the project. Your goal is to make sure that they think they are in control and abreast of the project, while keeping all details from them. Most managers will happily collude in this, since they have no desire to know what is happening, so long as they are seen to be so aware and are rigorously kept blissfully ignorant of their own ignorance. Remember that managers are essentially secretaries who can fire you.

6. Managers don't want to know the truth: keep it from them.


Documentation is an essential tool in the twin goals of ass-covering and of managing management. It also provides dangerous traps for potential enemies.

The political trick is to strike the correct tone of opaque vagueness and unshakeable authority. The true use of documentation is to bridge the inevitable gap between what the project is supposed to do and what it actually does. Politically written documentation bridges this gap by appearing to claim the former without actually denying the latter. On close examination, it will be found to say nothing at all.

This is the true origin of the fallacy that code is its own best documentation: The code itself is the only document which may be relied upon in any way in order to find out how the software might actually behave under this or that set of circumstances. However, anyone actually saying so only reveals themselves as a troublemaker.

There is also a three-way conflict between the interested parties:

1. The people specifying the documentation want it to be as detailed as possible, in as much volume as possible. The more documentation, the better, as this increases their importance.

2. The people writing the documentation want it as effortless as possible

3. The people eventually using the documentation want it as accurate as possible.

The usual compromise between 1 and 2 is to create vast amounts of inaccurate, out-of-date documentation. Since it's never updated, it's usually useless to 3.

The best way to sneak useful documentation past the system is to create a brief "Overview" document, small enough to be kept up-to-date. This will at least give maintenance programmers an idea of what the system is supposed to do.

7. Keep documentation brief enough to be kept up-to-date

If possible, try to get accurate documentation created: otherwise you will find yourself doing endless maintenance and support on a system that only you understand.


Document everything. Preserve your old emails. If possible, keep them in a personal archive so that you can use them, but they cannot be used against you.

Especially if you're busy, keep a record of what you've done every day: either in your official timesheets or in private notes. Especially when under pressure it can be tempting to leave them to later: but this leaves you dangerously vulnerable when the blamestorming begins.

When asked incredulously "how on earth did it take you so long to do this", you need to be able to say first: "Because I had to do X, Y and Z and then undo them", and point to your record as evidence. When asked "why on earth did you do that?" you need to be able to say "because you told me to in this email sent on this date."

In turn, the emails you sent will be used in evidence against you. Keep a professional tone: before sending any sensitive email take a moment to think how it would look at an industrial tribunal.

The chief difficulty is reaching a satisfactory compromise between ass-covering and not appearing too negative. If you know something is going to fail, make sure you point it out and have a record, but try to present it in a positive way. Say that it is a "major risk", rather than a certain failure. Try to request additional resources or time even when you know they will be denied.

8. Preserve records privately

Error messages and logfiles

As well as being later than you expect, the system will be less reliable than you expect. Make sure your debug and logfiles give you plenty of information. As with architecture, make sure that your error messages assign blame appropriately.


As the deadlines whoosh past, the pressure will grow to do unpaid overtime. Reduced concentration and the unavailability of other people mean that generally an hour of overtime achieves much less than an hour of normal time, so it's not very effective.

The thing to remember is that your line manager wants you to do overtime because he's being pressured by his managers. In many cases he doesn't want you to do overtime, since he knows that the extra bugs aren't worth it, but to be seen to be doing overtime. The key rule is:

9. Overtime only counts when people see it

It's usually better to do overtime in the evening than the morning, if there are more people around to see it. Weekend overtime is usually pointless since there are rarely witnesses.

Remember that you're not just being visible to your boss, but the office as a whole. Your overtime is useless to him unless it's visible to his boss, or else other people who contribute to your team's reputation.

Keep to the minimum possible. Remember that the earliest part is most valuable since there are more witnesses: better to do half an hour Monday to Thursday than two hours on Wednesday. It also sounds better to say: "I've worked late four nights this week." No-one will be keeping track that closely anyway.

Finally, remember that with deadlines pressing, the last thing your line manager wants is to fire you. Threats are likely to be empty in the short term, and quickly forgotten when the project is over. As part of his empire, you are contributing to his status: he doesn't want to get rid of you even if you're useless. You're only likely to be fired if the company as a whole is reducing numbers, and in that case no amount of work guarantees safety.

This article was created as a collaboration on ko4ting the K5 wiki by clover kicker, motty, R Mutt, Scrymarch and TheophileEscargot.


Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure


Most important rule?
o 1. Most software fails because it is designed to fail 10%
o 2. Loose lips sink projects 1%
o 3. Don't trust the analysis 4%
o 4a. Descope early. 4b. Admit descoping late 19%
o 5. Make sure architecture assigns blame clearly 7%
o 6. Managers don't want to know the truth: keep it from them. 10%
o 7. Keep documentation brief enough to be kept up-to-date 13%
o 8. Preserve records privately 14%
o 9. Overtime only counts when people see it 18%

Votes: 83
Results | Other Polls

Related Links
o created
o collaborat ion
o ko4ting
o Also by TheophileEscargot

Display: Sort:
Politics-Oriented Software Development | 97 comments (94 topical, 3 editorial, 0 hidden)
Loved it! Move to vote. (1.20 / 5) (#1)
by shinnin on Fri Jan 28, 2005 at 04:19:30 AM EST

seconded (none / 1) (#2)
by ZeroesAndOnes on Fri Jan 28, 2005 at 05:21:28 AM EST

0000 1001 1010 1101
[ Parent ]
Have moved to vote (none / 1) (#3)
by TheophileEscargot on Fri Jan 28, 2005 at 06:32:51 AM EST

Cue inevitable discovery of 37 spelling and grammar errors ;-)
Support the nascent Mad Open Science movement... when we talk about "hundreds of eyeballs," we really mean it. Lagged2Death
[ Parent ]
Ahem (none / 1) (#13)
by toulouse on Fri Jan 28, 2005 at 10:00:09 AM EST

There are exceptions, such as improving your resumé by ...

'My god...it's full of blogs.' - ktakki

[ Parent ]
LOL WHAT? (1.04 / 23) (#4)
by noogie on Fri Jan 28, 2005 at 06:34:16 AM EST

Why is a girl programming???!!

"Alice" is a guy (2.57 / 7) (#18)
by ucblockhead on Fri Jan 28, 2005 at 12:12:08 PM EST

And he really, really hates his parents.
This is k5. We're all tools - duxup
[ Parent ]
Almost as much as Bob hates hers. (2.66 / 9) (#27)
by wiredog on Fri Jan 28, 2005 at 04:31:27 PM EST

Wilford Brimley scares my chickens.
Phil the Canuck

[ Parent ]
They called her Kate. Short for... er... Bob! [nt] (1.50 / 2) (#37)
by gusnz on Fri Jan 28, 2005 at 09:58:45 PM EST

[ JavaScript / DHTML menu, popup tooltip, scrollbar scripts... ]

[ Parent ]
Relax; it will be ok (none / 0) (#89)
by aphasia on Sun Feb 06, 2005 at 03:04:17 AM EST

Notice she's not doing the 'important' data stuff. Indeed, she's writing documentation. She's like a secretary who is... a secretary! No threat to Bob there.

"You have *huge* brass balls. Tex would be jealous." --ti dave
[ Parent ]

And the GUI. (none / 0) (#95)
by DavidTC on Fri Feb 25, 2005 at 03:52:36 PM EST

Which is good, chicks are good at that sort of touchy-feely crap.

...what do you mean, sensitivity training?

-David T. C.
Yes, my email address is real.
[ Parent ]

Managers are Secretaries who can fire you (2.83 / 6) (#6)
by OldCoder on Fri Jan 28, 2005 at 06:38:12 AM EST

This is only true in some organizations. Possibly the majority. Software houses suffer less from this problem. Many organizations which are not software-sophisticated nevertheless need software and need their own development. Financial and manufacturing companies, in particular. In such organizations, the problems described in this article are common. A flour mill or paper factory or an agriculture-related business will fall into the deep part of this pit.

Software-sophisticated organizations have their own set of problems: Management that thinks it knows what it is doing. Managers threatening to "Code it themselves". Reaching too far. Arrogance. Having to compete against Microsoft. Being Microsoft.

Electronics companies that make products with embedded software often have managers who are very techie in the electronics side of things but don't know diddly about developing software. This problem is abating with time.

Some financial and manufacturing organizations have become very good at software and software management, this includes some of the larger banks and insurance companies and also electronics companies like Sun and HP.

By reading this signature, you have agreed.
Copyright © 2004 OldCoder

I tend to prefer (3.00 / 7) (#7)
by TheophileEscargot on Fri Jan 28, 2005 at 06:43:08 AM EST

Non-technical managers to technical managers. They're far less likely to screw things by insisting on obsolete or intensively-marketed technology, or decisions based on partial information.
Support the nascent Mad Open Science movement... when we talk about "hundreds of eyeballs," we really mean it. Lagged2Death
[ Parent ]
Best managers (3.00 / 3) (#20)
by ucblockhead on Fri Jan 28, 2005 at 12:24:41 PM EST

The best managers I've had are non-programmer technophiles. They know enough not to ask you to do stupid things but know little enough about actual coding to defer to you technically.
This is k5. We're all tools - duxup
[ Parent ]
I like managers who value truth highly. (none / 1) (#85)
by Anonymous Hiro on Wed Feb 02, 2005 at 11:42:17 AM EST

e.g. if you tell them the truth as you see it, they value it even if they don't like it or they disagree.. AND they tell you the truth too.

Life is too short to waste on BS.

So far I've been fortunate to have had immediate managers that believe me when I say "this is going to be hard" or "this is not a good idea". Of course - sometimes we have to do some silly stuff for business reasons, but hey that's part of the job.

They can say whatever they want to upper management - that's their job. That said, upper management has not been all bad either in the various companies I've worked.

Maybe it's because there are fewer MBA managers in my country?

Y'know I think top sales people being promoted to managers could have a higher chance of being worse than top tech people being promoted to managers. After years of going easy with the truth you wonder whether they themselves even know whether they are telling the truth or not.

You have better chance of reasoning with a tech guy. Step by step logical and technical arguments actually work. Heck you might even find out you were wrong after all and learn something new.

The top sales guy could perhaps be the President/CEO - the figurehead leader who sells the company/brand/image to the public and shareholders (bullshits them), and maybe even internal staff. Selling on a higher level...

[ Parent ]

IAWTP. (3.00 / 5) (#9)
by porkchop_d_clown on Fri Jan 28, 2005 at 08:24:31 AM EST

The business types promote coders to management, failing to recognize that good engineers make terrible managers. Good coders tend to think management is easy, because it's merely people skills.

End result: The absolute worst managers the world has ever seen.

In my entire career I've only ever had one first rate manager and he was a suit who was just technical enough to realize what I was doing was hard.

Has anybody seen my clue? I know I had one when I came in here...
[ Parent ]

It depends (3.00 / 3) (#19)
by ucblockhead on Fri Jan 28, 2005 at 12:24:36 PM EST

If the team is good, someone promoted within the team can do well at managing the team. The problem is more that he is often ill-equiped to deal with managing his superiors (which is half the job) and company politics.
This is k5. We're all tools - duxup
[ Parent ]
I respectfully disagree.... (3.00 / 3) (#32)
by ckaminski on Fri Jan 28, 2005 at 07:03:00 PM EST

In my experience the BEST engineers made the best managers, because they understand the things that make good managers,   How to make tradeoffs in the best interest of the project, resource management, etc.  It's the learning how to delegate that is the hardest to develop.

Then again, the two best manager engineers I ever had were only credits away from a Masters in Electrical Engineering... :-/

[ Parent ]

Teaching a manager to manage (none / 1) (#90)
by aphasia on Sun Feb 06, 2005 at 03:08:21 AM EST

It seems to me there's a sore lack of training and mentoring available to new managers, or people being suspected of having management aptitude. You can argue the whys all day, but it stands to reason that it doesn't work when you taker a sales guy or an engineer out of his cube and away from his phone one day and tell him, "Guess what? You're in charge! Thou art a manager!" and expect him to master the role.

Maybe it's just my workplaces, but maybe not. When's the last time you saw any evidence of manager training or mentoring?

"You have *huge* brass balls. Tex would be jealous." --ti dave
[ Parent ]

This will probably end up being posted (2.00 / 3) (#8)
by wiredog on Fri Jan 28, 2005 at 08:14:10 AM EST

on Slashdot. Especially if several of us submit it. Good work, and oh, so true.

Wilford Brimley scares my chickens.
Phil the Canuck

Submitted (1.50 / 2) (#26)
by wiredog on Fri Jan 28, 2005 at 04:30:46 PM EST

at 1630 EST

Wilford Brimley scares my chickens.
Phil the Canuck

[ Parent ]
Posted to /. front page (1.33 / 3) (#52)
by dave331 on Sun Jan 30, 2005 at 02:51:54 AM EST

at 11:05pm PST

[ Parent ]
Oh darn. (none / 0) (#60)
by Yet Another Troll on Sun Jan 30, 2005 at 08:04:48 AM EST

This will result in a load of newless cluebies emigrating from Slashdot.  Happens every time /. taks about K5.

Anyone wanna write a Slashbot's guide to being a Kurobot?

[ Parent ]

And how did you find this place? (none / 1) (#77)
by wiredog on Mon Jan 31, 2005 at 08:33:15 AM EST

Wilford Brimley scares my chickens.
Phil the Canuck

[ Parent ]
My other UID is lower (none / 1) (#78)
by Yet Another Troll on Mon Jan 31, 2005 at 08:40:29 AM EST

I was here when this was little more than a slashdot knockoff site (This is a lie).

I came here from Slashdot.  Along with a load of others.  It took a while for the regulars to teach us the way and allow us into the inner circle.

[ Parent ]

I should have thought of this sooner. (2.89 / 19) (#10)
by porkchop_d_clown on Fri Jan 28, 2005 at 08:28:53 AM EST

I have a personal definition of a manager that sounds disparaging but really isn't.

A good manager is a bi-directional bullshit filter. He/she blocks distracting crap from raining down on programmers, allowing only the needed information to pass through. Meanwhile, he prevents the programmers from terrorizing management with gobbledygook and allows only the useful data to pass in that direction.

The problem with most managers is they only possess one or the other of those two skills. Most of them only filter information passing upwards - which makes sense when you realize that the guys above them are the ones handing out pay checks. A few only filter what's coming down from above, which makes them beloved by their team and loathed by the suits.

In my whole career I think I've only ever met one really good manager and he was non-technical.

Personally, I was a terrible manager.

Has anybody seen my clue? I know I had one when I came in here...

IAWTP (3.00 / 7) (#15)
by ksandstr on Fri Jan 28, 2005 at 10:22:17 AM EST

What most programmers don't seem to realize is that non-technical types, including most suits regardless of how technical they think themselves to be, are altogether too easy to scare with honest no-bullshit opinions about whatever technical matter is at hand. A good techies->suits type bullshit filter would therefore include not only filtering, but a limited amount of candy coating and such to draw attention away from the theoretically scary fact that a "95% uptime" figure can also be read as "5% downtime".

The best manager I ever had also possessed the ability to convince necktie people that technical decisions are best left to genuinely technical people instead of suits with an overdose of "computer stuff for idiots!" type magazines.

[ Parent ]

low-pass filter (none / 0) (#83)
by daani on Tue Feb 01, 2005 at 04:50:08 AM EST

Also, a manager should act as a low-pass filter. Don't pass anything up or down until it's been around for a few days and you're sure the issue won't just go away.

[ Parent ]
Absolutely (none / 0) (#93)
by noise on Thu Feb 10, 2005 at 12:17:01 PM EST

Your definition is dead on. I have only encountered one as well... and am working to become one.

[ Parent ]
Unpaid overtime: not worth it, ever (2.72 / 11) (#14)
by ksandstr on Fri Jan 28, 2005 at 10:12:33 AM EST

But if you can be fired for not doing it (or it's illegal but you have no proof or ability to go to court over it), 30 minutes four days a week isn't all that bad. If the people who would be observing you doing the overtime are spineless as usual, they'll be long gone by the time your 30 minutes are up.

Nevertheless, the proper answer to "well, why don't you go ahead and come in on saturday, and sunday too, we can't pay you though" is the emphatic negative. Not only because it's your personal time sacrificed for an expedient appearance for your managers, but because tolerating it makes it that much harder for your coworkers to refuse. I know that workers' solidarity isn't all that hot a thing on the left side of the atlantic right now, but it will pay off in the long run, regardless of how many ill-educated Indian code monkeys[1] they could threaten to replace you with.

[1] this refers to those Indians who are not only ill-educated but also code monkeys. Not to say that all Indial code-monkeys are ill-educated.

It's a moral dilemma really (3.00 / 7) (#21)
by TheophileEscargot on Fri Jan 28, 2005 at 12:29:13 PM EST

As you say, it's better for your coworkers and the world as a whole if you refuse outright.

But it's often personally easier to say "yes", surf K5 for half an hour then fuck off as soon as they're out of the car park...
Support the nascent Mad Open Science movement... when we talk about "hundreds of eyeballs," we really mean it. Lagged2Death
[ Parent ]

Can be worth it (3.00 / 4) (#25)
by cactus on Fri Jan 28, 2005 at 03:32:07 PM EST

I know several millionaires who would disagree with you.

There are certainly circumstances, especially where you own a part of the company or have options, where unpaid overtime is certainly worth it. The payoff might not be guaranteed, but it can be substantial.

My advice is simply to make sure that you own part of what you do, and then commit yourself fully to it. Don't work somewhere where they don't provide preferential treatment for you to acquire some stake in the company, whether it's a discounted stock purchase program, options, or something else.

Life is too short to just be collecting an hourly fee at a glorified McJob.
"Politics are the entertainment branch of Industry"
-- Frank Zappa
[ Parent ]
not quite unpaid (2.50 / 2) (#41)
by cronian on Sat Jan 29, 2005 at 12:32:48 PM EST

If you have significant ownership in the company, or something then working "unpaid" overtime, can actually pay off for your. Although, in most cases it doesn't really work that way.

We perfect it; Congress kills it; They make it; We Import it; It must be anti-Americanism
[ Parent ]
Sounds like you've never had a good manager... (3.00 / 15) (#16)
by Drog on Fri Jan 28, 2005 at 10:36:14 AM EST

...judging by how cynical you are about them. I've been on both sides of the fence, as both a developer and a manager. I was lucky enough to get actual people management training from the best instructor in Ottawa, and I already knew a thing or two about project management. In my opinion, a software development manager's main job is to:

a) Remove all obstacles that stop the developers from working effectively. This usually means making all product managers, dev managers and directors go through you, rather than directly to the developers. Otherwise, get pulled in different directions and get distracted too much.

b) Ensure that the architecture is sound and that what is being built fits in well with the "big picture", i.e. that your team's piece will fit in well with the overall software's architecture and that if at all possible, it will be useful (rather than obsolete) as the company executes its longer term strategy.

c) Ensure that realistic, achievable schedules are in place. That means not agreeing to upper management to simply build something by a certain date that they've decided upon. It's the manager's job to come up with reliable time estimates (with the team's help), take it back to upper management, and say that they must either reduce features or extend the deadline. The manager must always combat feature-creep too--again, for every new feature added, either another feature has to get dropped or the deadline must be extended. Achieving this is not always easy in some companies with draconian management structures. It may even be impossible, which means the dev manager will eventually get fired. So be it--it's the manager's job to look out for his/her team no matter what.

d) Ensure the employees are well-treated and in an environment they enjoy being in.

As for your comment that it's easier for managers to find work elsewhere than it is for developers, I have never found that to be the case. I went back into development mainly because I saw way too many developers who made their way to upper management only to get laid off and discover that nobody wants to hire another company's manager when they have their own peope to promote, and nobody wants to hire a developer that's been a manager for more than 4 years.

Looking for political forums? Check out "The World Forum". News feed available here on K5.

Yah there are good managers. (none / 1) (#86)
by Anonymous Hiro on Wed Feb 02, 2005 at 11:52:03 AM EST

And when they leave, often most (if not all) of the team leaves, because statistically a bad manager is more likely to take over...

It's like "shields down" or "hull breach" as someone I know put it. And you're then exposed to upper management or the bad manager...

People who say managers contribute nothing really don't understand what managers do.

To the programmers: they're the official "module" that the rest of the Org Units are to interface with. A module that filters and deals with exceptions, coordinates the rest of the subunits, and is responsible for that Org Unit as a whole. Sure the entities in the other Org Units can and often do make direct calls, but with the official module in place you can choose to deflect the calls to the "upper layer" who is best positioned to officially tell them to bugger off.

Plus they go for the nontech or erm other meetings so that most devs don't have to. That's definitely useful :).

[ Parent ]

Don't forget Putt's Law (2.87 / 8) (#17)
by SemiMike on Fri Jan 28, 2005 at 12:09:41 PM EST

"Technology-based organizations are dominated by two types of individuals: those who understand what they do not manage, and those who manage what they do not understand."

No implication that technology-competent managers do not exist, but they are the exception to the rule.

"Computers can do that?!" Homer Simpson

Note on overtime (2.88 / 9) (#22)
by ucblockhead on Fri Jan 28, 2005 at 12:30:56 PM EST

One way to "work long hours" is to come in early, take a two hour lunch, and then leave late.
This is k5. We're all tools - duxup
Unfortunately my managers never saw it that way (3.00 / 9) (#33)
by lukme on Fri Jan 28, 2005 at 07:16:06 PM EST

If you came in before them, that was uncounted hours in their eyes - not a plus. Furthermore, if you took a 2 hour lunch everyday, that was 2 hours they were there that you weren't - a minus. Being there after they were gone for the evening was not a minus.

Overall, they would then see it as a minus and you would be dinged as was a collegue of mine.

It's awfully hard to fly with eagles when you're a turkey.
[ Parent ]
Finesse it (2.50 / 2) (#69)
by rajulkabir on Sun Jan 30, 2005 at 03:35:55 PM EST

One way to "work long hours" is to come in early, take a two hour lunch, and then leave late.

Too easy to get busted by someone who comes to your office 5 minutes after you leave for lunch, then desperately comes back every 10 minutes because they need something from you.

Take five or six 45-minute lunches instead.

[ Parent ]
All True (2.50 / 4) (#23)
by conner_bw on Fri Jan 28, 2005 at 01:14:33 PM EST

This is a great article, congrats! However, now that you've so eloquently put into words what i've been living the last decade, i phear for my job security. All the secrets have been revealed, prepare for the next generation's swarm of unproductively.

Management is all about people skills (2.66 / 9) (#24)
by frijolito on Fri Jan 28, 2005 at 01:37:26 PM EST

...like porkchop mentioned somewhere. I'm currently the "IT Manager" of a shipping company (in an undisclosed Central American country); and I put quotation marks around my job title because I'm little more than a lackey for my boss.

He is an engineer (but not a Software Engineer, like myself), and he tends to believe that he's vastly technically proficient. He's not. He mainly considers his job to be: appear to be an ultra-badass to his superiors' eyes. He loves to "project an image of efficiency", and swears by bs like "dress for success" and "cleanliness is next to godliness". He truly is an 80's yuppie... only 20 years too late (hey, maybe he can get away with it because this is Central America after all). The guy has no people skills, and everyone below him in the corporate ladder hates him; but you have to admire his skill at kissing his superiors' asses. Of course, I hate him most, since I have to take more of his shit.

Result: I'm quitting today. Seriously. I was actually working on my resignation letter when I stumbled upon this article... imagine that. I'm thinking of going into the tourism industry, and staying away from corporations for good.

sweet epiphany! su nombre es frijolito! (nt) (none / 1) (#54)
by circletimessquare on Sun Jan 30, 2005 at 03:31:18 AM EST

The tigers of wrath are wiser than the horses of instruction.

[ Parent ]
A little cynical ... (2.50 / 4) (#28)
by cdguru on Fri Jan 28, 2005 at 04:35:43 PM EST

but unfortunately not all that untrue. I do think you have seen the worst in management, however.

I don't think the sort of inter-departmental nonsense that you describe is the rule everywhere. Most places where "software is a cost of doing business" rather than "software is the business" really don't care about disclaimers, foist the documentation off onto a technical writing staff and manage with a little less hostility. The result is that things get done, perhaps with less effectiveness, but things get done.

Your belief in "indirect sabotage" is something that I hope I never really see. No matter where I was in an organization, even if it meant finding a new job, I would make it my duty in life to have anyone doing that fired. In my current situation - owner of a software company - I would toss the sabotager out in the street. Literally.

I feel almost as strongly about people that want to play games covering their ass and seeking their own glorification instead of accomplishing something. Yes, I've seen it. No, nobody reporting to me ever had the courage to get found out doing that kind of stuff.

Well (3.00 / 5) (#29)
by TheophileEscargot on Fri Jan 28, 2005 at 04:55:55 PM EST

If controlling the perceptions of your superiors is the name of the game, by definition they'll never know about the people who play it best...
Support the nascent Mad Open Science movement... when we talk about "hundreds of eyeballs," we really mean it. Lagged2Death
[ Parent ]
It's called wage SLAVERY for a reason. (2.42 / 7) (#30)
by seanhbanks on Fri Jan 28, 2005 at 06:31:19 PM EST

The problem, and it permeates all business, not just software programming, appears to me to be the, IMO flawed, assumption that administration is a necessary component of a functional enterprise. I posit it isn't. Not unlike "civil servants," so-called administrators/managers/project co-ordinators, et. al., usually serve a function of an arguably parasitic/overlord nature, contributing little to nothing to actual productivity. Management could even now (I would say, should) be replaced by currently available software, there is no need to even wait for an AI capable of passing Turing tests, as most managers wouldn't pass one, either. The notion of management seems like an anachronism, and thus, an agent of retardation to me. The same appears to hold true for office politics in general, all these pseudo-human relations hark back to primate tribal domination struggles. Has evolution taught us nothing?

It's reality for now (none / 1) (#39)
by Sen on Sat Jan 29, 2005 at 01:47:31 AM EST

It's human nature, plain and simple. No utopian arrangement will get beyond human nature. So <b>change human nature</b>.

[ Parent ]
Bad management could be replaced... (2.50 / 2) (#59)
by skyknight on Sun Jan 30, 2005 at 08:02:01 AM EST

by good software. Good management, however, is worth its weight in gold and is not readily available from people, and certainly no such thing yet exists in software format.

It's not much fun at the top. I envy the common people, their hearty meals and Bruce Springsteen and voting. --SIGNOR SPAGHETTI
[ Parent ]
management as a focal point for blame (3.00 / 6) (#31)
by cbraga on Fri Jan 28, 2005 at 06:51:51 PM EST

Most corporate directors will probably realise that managers do not create value for the company since the time they spend "managing" isn't productive — which should be pretty obvious. But can a company function without managers?

Probably not, and if someone found a way to make that feasible that person would be very rich.

In an utopia all the programmers would be competent and work all day and meet the deadlines. Of course that's not the case in the real world. If the software teams consisted entirely of programmers — no managers — the executives could fire all programmers if the deadlines were missed or if the project failed. Or he could keep all of them and punish nobody for the project's failure — which would fail 10 times out of 10.

Enter the manager: a focal point for blame. If somebody below the manager isn't doing their job it's the manager's fault. Or if the project is late, or is having technical trouble, it's all the manager's fault. That's why there are plenty of incompetent managers — the company's way better with them than without them.

ESC[78;89;13p ESC[110;121;13p

You need to check out aviation software (3.00 / 5) (#43)
by codejack on Sat Jan 29, 2005 at 01:00:38 PM EST

Due to FAA regulations, software used in aviation (I.E. computers that run and control airplanes, etc.) must be developed by programmers with the following restrictions:
  • They must be certified by the FAA
  • They are not allowed to work overtime, not are they allowed to have a second job
  • They are required to take a minimum of two weeks vacation every year
...And more! Note that if airplanes and air traffic control towers ran software developed by the "normal" process, e.g. windows....

Please read before posting.

[ Parent ]
Heh (2.66 / 6) (#34)
by trhurler on Fri Jan 28, 2005 at 08:05:29 PM EST

I've worked at one or two places like that. Let me assure you that there are other places.

'God dammit, your posts make me hard.' --LilDebbie

ok, so what else is new. (1.42 / 7) (#35)
by recharged95 on Fri Jan 28, 2005 at 08:15:22 PM EST

Good analysis, but unimportant problem--this is a waste of 4 pages (or so).

For one, S/W development is no different than any other business that "solves" customers problems. Look at the legal biz...or the oil biz. It's a complex field, and those who write "utopia process" books exploit that fact--yes a lot of us veterans know already the problems, and the problems are manifested in industry jargon.

Second, the whole article exploits the fact that in any complex business:

work == business == money == you & I get paid.

No work, then no cash. Even if the work is 100% unless, it's justified, caeveat empator. Even if it's 100% for "the good" (e.g. you actually think about the work), it's still just work. Customers don't pay for a free lunch to vendors--well, unless the US gov't is the vendor (i.e. taxes in some cases). Some people do cheat, lie, steal, but that's not the majority and usually subjective when classifying.

A good point is made that everyone has individual agendas, but the common thing among all is you need to be "working" [for a business to operate].

not always true (none / 1) (#40)
by cronian on Sat Jan 29, 2005 at 12:25:08 PM EST

I worked for a company, where our customer gave us free lunch. You are not correct.

We perfect it; Congress kills it; They make it; We Import it; It must be anti-Americanism
[ Parent ]
Marvelously distilled cynicism (2.85 / 7) (#36)
by johnny on Fri Jan 28, 2005 at 09:41:42 PM EST

This is worthy of Ambrose Bierce (or whatever his name was).

The only difficiency that I can see is that it implicitly makes the point that software engineers are any better than the rest of of the lot, for example, the managers, which of course they are not.

Were this piece to point out that you, the codewriter, have a prounounced deficiency in social skills along with an inflated sense of your own analytical and coding abilities, which, together, prevent you from seeing or admitting your own mistakes -- and that your fellow codemonkeys are similarly impaired, why then I think it would be just about perfect!

yr frn,
Get your free download of prizewinning novels Acts of the Apostles and Che

Well, as a marxist... (2.66 / 3) (#42)
by codejack on Sat Jan 29, 2005 at 12:51:16 PM EST

I must point out that the codemonkeys actually prodice something, while the managers produce nothing. Social skills are irrelevant in this context, and analytical and coding abilities are required. Software engineers, well, I.T. workers in general, are also a unique class of corporate serf in that they have skills not easily obtainable by others.

Please read before posting.

[ Parent ]
Well now that's just silly (3.00 / 2) (#61)
by johnny on Sun Jan 30, 2005 at 08:07:29 AM EST

and kind of gets to my point about (humorless?) software engineers overvaluing their own skills. Anyway, like I said, Theo's piece is distilled cynicism, and the implied soft-spot for engineers fucks it up with sentimentalism. It's like a Dawn of the Dead or Invasion of the Body Snatchers or Stepford Wives in which the virtuous ones escape the horrible fate of drab sameness. No, I'm sorry, we're all the same. That's what makes it so horrible and entertaining!

yr frn,
Get your free download of prizewinning novels Acts of the Apostles and Che
[ Parent ]
extra cynicism solicited (3.00 / 3) (#62)
by clover_kicker on Sun Jan 30, 2005 at 10:18:09 AM EST

This document was collaboratively produced here.

If you've got cynical thoughts to add, I for one want to see 'em.

This article is far from perfect, I think the world needs an expanded and improved v2.0.
I am the very model of a K5 personality.
I intersperse obscenity with tedious banality.

[ Parent ]

Re: Well, as a marxist... (none / 0) (#71)
by drsmithy on Sun Jan 30, 2005 at 07:00:28 PM EST

Software engineers, well, I.T. workers in general, are also a unique class of corporate serf in that they have skills not easily obtainable by others.

What makes you say that ?

[ Parent ]

Just an observation (none / 1) (#87)
by codejack on Wed Feb 02, 2005 at 11:13:44 PM EST

Garnered, from years of work in the field. Not to say that IT work is somehow more noble than any other form of work, but that being inherently technical, it tends to scare off people with the kind of education found in the United States; Maybe it's different elsewhere, I couldn't say.

Please read before posting.

[ Parent ]
Heh (none / 1) (#63)
by motty on Sun Jan 30, 2005 at 11:22:59 AM EST

Earlier drafts of the article were more in that kind of vein, owing to a small misunderstanding between myself and everyone else as to whether or not the article was intended more as satire or more as a genuinely practical albeit ubercynical guide. I'd thought the idea was satire and couched my contributions accordingly. The funny thing is how much of what I'd thought was satire remained after the others had edited out some of the more entirely impractical jokes.
[ Parent ]
Well, I took out quite a lot (3.00 / 3) (#66)
by TheophileEscargot on Sun Jan 30, 2005 at 12:16:58 PM EST

But your "managers are essentially secretaries who can fire you" seems to be the most popular line in it.

If people think it's too cynical, I think they ought to carefully consider the old poker saying.

There's always a sucker. If you can't tell who it is: it's you.

Support the nascent Mad Open Science movement... when we talk about "hundreds of eyeballs," we really mean it. Lagged2Death
[ Parent ]

I didn't write that, did I? (none / 1) (#70)
by motty on Sun Jan 30, 2005 at 06:37:31 PM EST

Oh dear.


No I didn't. It was added  in revision 18 by Scrymarch.

The inflammatory line you removed from my draft of that section was the suggestion to actively baffle managers with bullshit; not something I'd ever seriously suggest IRL. Of course.

What was that bit about preserve records?

[ Parent ]

Damn, I thought that was your bit (none / 1) (#75)
by TheophileEscargot on Mon Jan 31, 2005 at 02:16:08 AM EST

Not sure who put in "preserve records privately". I do do that though, so it might have been me.
Support the nascent Mad Open Science movement... when we talk about "hundreds of eyeballs," we really mean it. Lagged2Death
[ Parent ]
Yup (none / 1) (#80)
by ucblockhead on Mon Jan 31, 2005 at 05:47:39 PM EST

There's a name for the sorts who think it's too cynical. It's "victim".
This is k5. We're all tools - duxup
[ Parent ]
Not cynical enough, that was my point (none / 0) (#88)
by johnny on Thu Feb 03, 2005 at 12:09:58 PM EST

yr frn,
Get your free download of prizewinning novels Acts of the Apostles and Che
[ Parent ]
Sounds like any office (2.00 / 3) (#38)
by The Real Lord Kano on Fri Jan 28, 2005 at 10:20:48 PM EST

This type of stuff goes on at just about every company. Regardless of what they produce. It's not called a "rat race" for nothing. Everyone else is trying to do you in while getting ahead. LK

Very good (3.00 / 9) (#44)
by Roman on Sat Jan 29, 2005 at 01:34:08 PM EST

Very good description of the first principles.  The projects don't matter, good design does not matter.

All that matters is what is easily visible and even more importantly - the perception.

I am a contractor, worked as a contractor for the past 4 years.  Prior to contractin I've done 5 years of permanent work.  I live and work in Canada, Toronto.  In the past 4 years I worked at 6 different organizations on a total of 18 contracts.

The goal of any contractor is to find a well-paying contract and to make sure that the job is done satisfactory, so that the contract maybe extended for other projects within the same organization (hopefully for more money.)

My latest contract is quite interesting in that it is with an organization (no names) where the tactics are very close to those described in this submission.  I was hired because a different architect was let-go (the union will not allow contractors to stay for more than 2 years,) and there was an important project to be done (the project is a legal obligation to the government, so it's serios.)

The overal feeling within the department is that the head manager of the department is a micromanaging, self-indulging, brainless moron with a serious attitude problem.  From point of view of this k5 story, this is the only IT department, so there is less competition between the management on the higher levels to compete.  But there are many other problems.  The air within the department is that of complete secrecy.

You probably know the expression: job security?

Well, everything around here is based on that.  The projects' success does not matter.  The effectiveness does not matter.  Maintainability does not matter.  What matters is that you do not do what you are not supposed to do, even if it takes you 5 minutes instead of waiting for the specialized help for a week.  You do not invade into the very narrow spaces of very narrowminded people, who are good at one thing - maintaining their job security.

Documentation to the projects is obviously outdated and has nothing to do with the system that needed to be improved upon.  The system itself is based on technology (from a well known company) that should never have been used, but someone's ancle/aunt/father/brother whatever helped this tech to be pushed into the environment (obviously this tech is so obscure and specialized that noone else in the world uses it, so it's not updated.)  The project is understaffed, the deadline is too damn close and the resources are not there (not enough money)

As a contractor I am interested in the project succeeding and as a developer I am interested to make sure that the design and development are based on some good principles.

So here are the problems (obstacles) to success and the steps I had to take to go around them.

1. The sources of the original system are controled by a special team.  To gain access to the source control system there are too many obstacles.  The advice to me was for our group to use a shared directory as a source control tool.  Obviously this would not have worked - we would have spent all our time synching the sources.  There are very serious barriers to getting a different source controlling tool being installed on a dev server.

solution: install a source controlling tool on your own machine.  Import the sources.  Set up you developers as users.  Don't forget to make sure that the master source gets backed up somewhere every night.

2.  Documentation to the original system is not good at all or non-existant.  Knowledge is power and power is not to be shared with anyone.  The tools for documentation control are out of reach.

solution: install a Wiki server on your machine (I use Tomcat and JSPWiki, it's good enough.)  Start by setting up project space in Wiki, create sections for requirements, design, testing, assumptions, team, migration, issues, resources, standards etc.
Always update Wiki.  Nothing must get past it.  Remember: docs are good only as long as they help you to understand the entire picture of what you need to see.  Wiki does that, it allows you to interlink everything relevant between itself.

All requirements are linked to designs, assumptions and issues.  Design docs including design discussions, sequences, states, components and classes, data models, lists of changes to the current system, all of that when linked is very powerful tool.  Not everything appears there at once, but what is interesting, is that once you start using it and show it to the rest of the team, everyone starts using it.  Obviously there are some training issues, like don't overwrite each other and make sure not to remove content by unlinking it, but at the end it is one of the most important tools.

3.  Design tools: the company does not provide you with design tools, download trial versions, make sure to use these tools to do your designs, link the diagrams from the tool into your documents (wiki,) make sure that when someone asks you for documentation to email a wiki link to them with the design diagrams etc. right there.  Make sure to put the fact that the tool is not bought as an issue, raise it with the managers after a while.

4.  Testing:  as an architect you are responsible to make sure that the code your developers produce is good enough, so insist on as much unit testing as possible.  We work in Java, so JUnit testing.  Setup the frameworks for the first tests by yourself.  Make sure that the unit tests are in physically different source locations but in the same package structures as the code that is being tested.  You do not want to keep the code and the unit tests in the same physical locations though, it's easy to seperate them when necessary if they are in different physical directories.  Make sure to insist on unit testing all DAOs.  Provide examples on how to do it, lead by example, they will follow.  Unit testing will catch most of the bugs and if done properly all of the bugs in your subsystem.  Unit testing is important for regression - if there is a change to the rest of the application, always rerun ALL unit tests to see how the rest of the system is behaving.
Some things are easier to unit test then the others.  DB functions for example are easy to unit test.  Communication with remote systems is harder.
The argument that unit testing takes too much time does not hold water.  Without the unit tests the same bugs will have to be fixed later during entire system tests and it is more difficult to trace and catch bugs when testing is done on the entire system, rather than on subsystem.  So unit testing definitely SAVES time.

--Document all requirements, and make sure to have a history of the requirement changes.
--Have issue logs.
--Have assumption logs.
--Never let the documentation to get out of synch.
--Never work without a source control tool.
--Apply as much unit testing as possible.

and maybe you'll just get through.

excuse me (2.33 / 3) (#45)
by Roman on Sat Jan 29, 2005 at 01:44:34 PM EST

for not running a spellcheck on my post (contracting, serious, etc)

[ Parent ]
a couple of things on the behaviour (3.00 / 6) (#46)
by Roman on Sat Jan 29, 2005 at 01:59:23 PM EST

Also remember this, when someone asks you a quesion, when you hear something and feel you need to say something right there, when you are in a meeting and people are talking and you want to add something, don't do it.  Don't reply right away, don't say anything right away.  Take a moment to think.  Take 10-15 seconds to think.  Keep your mouth shut even for 10-20 seconds.  Just wait for a moment.  This helps.  You may see a point that would have escaped you 10 seconds ago.  You may answer your own question if you just wait for a second.   Basically don't rush.

Another thing: don't over-think.  Don't over-design things.  Don't try to think too much past your current requirements if the deadline is right in front of you.  Think right there, right now with just a little bit ahead.  Do not overgeneralize.  When you overgeneralize you will undoubtedly come to this design: key - value pairs are the most generic form possible.

What is the point of an XML structure if all it is is a hash-map?  What is the point of a function that called 'process(HashMap map)'?  Well, you CAN use a function like this if you are implementing an interface for example, but in most cases there are better ways of doing things that are more explicit in what is going on.  Remember, for maintenance and development purposes it is better to have well defined interfaces.  Work to an interface, interface is good, it is a contract.  When everyone is implementing a contract of some-sort, things tend to fall together effortlessly.

[ Parent ]

cont'd (3.00 / 5) (#47)
by Roman on Sat Jan 29, 2005 at 02:02:37 PM EST

what is the point of having a relational database if all you do with it is store blobs that can be 'anything'? There are circumstances where it could be an ok solution, but most of the time I have seen it done, it was just laziness and shortsightedness.

[ Parent ]
job security? (1.00 / 6) (#58)
by blackflame on Sun Jan 30, 2005 at 07:21:41 AM EST

"You probably know the expression: job security?"

no, i've never seen job security expressed as a question before.
-- Viral Media Exposed
[ Parent ]
what else haven't you seen? (3.00 / 2) (#65)
by Roman on Sun Jan 30, 2005 at 12:05:52 PM EST

a question mark placed appropriately in a question?

[ Parent ]
Try cvstrac (2.50 / 2) (#79)
by xofer d on Mon Jan 31, 2005 at 02:17:21 PM EST

It's pretty awesome for just that kind of thing. It serves itself, it's tiny, and it combines CVS access with a wiki *and* a trouble ticket system. And did I mention it's Free?

Yeah yeah, -1 buy an ad. I'm just trying to help.

[ Parent ]

suggestion (2.50 / 6) (#48)
by Roman on Sat Jan 29, 2005 at 02:10:55 PM EST

Alice - GUI, Docs, I/O, Utils
Bob - Data

Next time you see something like this and you know that Bob is actually doing 90% of work, take your time to write out the following:

Alice - GUI, Docs, I/O, Utils
Bob - Business Data Structures, Communication Protocols for Transferring Data, Persistant Data Layer, Data Transformation, etc.

What I mean is that it was not a manager's problem that you lumped everything into one category: Data.

Easy for you to say ... (3.00 / 4) (#57)
by tilly on Sun Jan 30, 2005 at 06:04:13 AM EST

First of all, the organization chart will probly have been created by somebody else. From the results, one can guess that Alice is the management's favorite to begin with. If you point out the concern, you will be met with the retort: "Nobody's counting squares! Jeez! I cant believe how political you are!"

But the same manager who puts you off this way will likely end up having a conversation with his/her superior that goes along the lines of:

The Big Banana: "Hmmm, I can see from this chart that Alice is a hard-working gal."

The Smaller Banana: "Well, you know, some people just have a higher capacity for work than others ..."

[ Parent ]

Never happens (2.50 / 2) (#64)
by Roman on Sun Jan 30, 2005 at 12:03:31 PM EST

In software at least, it is not the project manager who divides work into these 'squares'.

It is never the project manager.

It can be either the project architect or developers themselves.

The reason why it is not the project manager is simple: project manager has no idea what it takes to complete a specific project or a specific task. In my 9.5 years of work the manager always asks the developers (architect) to estimate the number and types of tasks as well as an estimate time per task. Managers' job is to look at the estimated number of tasks and at the estimated times and come up with a plan - prioritize the tasks (this also is normally done with the help from the team (architect),) come up with resources, allocated tasks to resources, keep track of how the tasks are going in comparison to the estimates, correct time-lines in case of slippage etc.

I have never heard of and have never participated in a project where the project manager comes up with these 'squares'. They cannot and they know they cannot. It is not their job, it is the job of developers (architect.)

[ Parent ]
Weight the Squares (2.75 / 4) (#68)
by czolgosz on Sun Jan 30, 2005 at 02:45:23 PM EST

When I do this (I'm the architect so it usually lands in my lap just like roman said) I like to either put a percentage of the LOE in each box or supplement the org chart with some pie charts to show where the effort and risk are distributed. The nominal reason for doing it is to aid the staffing effort, but the other reason is to head off simplistic box-counting.

When you have "teacher's pet" getting the good jobs even when they're not qualified, the trick is to engineer an early, difficult milestone. If they make it, their reputation is deserved. Otherwise, you can cut them down to size based on their demonstrated failure to perform. Then you can reassign them to some low-visibility effort that you've deliberately underscoped so they have to burn lots of overtime just to salvage their reputation. I'm proud that my projects have been the career graveyards of a number of bullshitters. The flip side is to be sure that your high performers are visible. Sometimes the most successful parts of your project seem to just magically happen, and nobody notices the dog that doesn't bark. This leads to self-promoters taking the credit, which will kill your next project because they'll get moved into positions of responsibility. Do everything you can to recognize the right people.

Oh, and (8) on the list is critical. Design your system for easy construction and debugging, even if the effort to put in the extra code comes out of your management reserve. It'll pay for itself during the crunch time at the end of the project, and even more if you get to do enhancements or maintenance. History is full of instances where simpler protocols and APIs were adopted despite competition from complex rivals that delivered more complete functionality (think SOAP or XML-RPC versus CORBA). The reason is that you can actually get something done using the simpler alternative.

Why should I let the toad work squat on my life? --Larkin
[ Parent ]
haha (2.66 / 3) (#49)
by metalotus on Sat Jan 29, 2005 at 07:18:34 PM EST

- Loose lips sink projects

Are you writing software for U-Boats or something? Seriously, I just spent a week getting "requirements' from like everyone in my company. If someone keeps giving you ideas that suck, just ignore them. Of course they may not be talking to you but your manager, in that case you need to do some talking too.

Fantastic list! (2.75 / 4) (#50)
by fink on Sun Jan 30, 2005 at 01:56:35 AM EST

I'll be asking my coworkers to read it through. Some of the more senior ones should probably pay attention too.

However, I think I'd have to add two (one and a half?) items; they are Be aware of -- and where possible avoid participating in -- schedule chicken and, as the half-item, Note that to some people, their job consists of preventing you from doing any work (which fits in to the idea of incidental sabotage).

Schedule chicken: This game consists of two teams (or individuals; the terms may in this case be used interchangeably), both working toward the "goal" of completing a given software product. The two teams can work independently, but both teams must complete their work in order for the work to be completed. Both might or might not take about the same length of time to be completed. Neither team wants to be on the critical path, and certainly neither team wants to be responsible for any schedule slippage.
There is pressure from above to reduce the delivery time, and there is internal pressure to not be the team on the critical path. Therefore, the schedule ends up being somewhat compressed, knowing full well that it can't be achieved, with the hope that the other team -- which is in the self-same situation -- will acknowledge a slip first, giving you some breathing room (without putting you on the critical path, of course).
It's better to be on the critical path right up front, but with a reasonably achievable schedule (hopefully you added, and kept, enough meat in your schedule!), and wear the daily status requests and demands for better performance from upper management, than to suddenly discover yourself on the critical path, getting the constant demands for better performance, but with no hope at all of meeting the original schedule you set yourself, or the replacement one you hurried through when you found yourself on the critical path. In short, a little bit of bad news (and pain) right up front is much better than being the chicken later.
Of course, the game is almost impossible to avoid completely; the other team will set a schedule that is only slightly less realistic than your own, but which gets them off the critical path. Management will only see that you are on the critical path, and not that your schedule is realistic; this means that you can expect a lot of "feedback" and status requests from your management types.

Work prevention: For a lot of people, especially in accounting and/or legal departments, it's easier to flat-out deny a request than to look at it in any detail. Even more than this, certain individuals will always try to find ways they can put a stop to your work, because doing so gets them attention from management (in the company for whom I work, being the squeaky wheel is a good way to get promoted; management apparently don't see you as a blocker but as a good manager, presumably because once upon a time they were all like that themselves).
Even technologists will tend to do this; if they think you're doing something wrong (e.g. they don't like the coding standard which was selected), they'll organise meeting after meeting, and review after review, to get the matter looked at. If they don't get their way, then within a couple of months they'll have forgotten that the issue was done to death, and start the cycle again. It is absolutely vital any notes and emails were kept on this matter, and can be provided to that person's management as soon as schedule slippage starts becoming apparent. Not that it makes much of a difference, of course.

For what it's worth, all of the rules in this article seem to be exacerbated in companies which engage in fixed-price, fixed-schedule contracts. I've seen a couple such companies now (it's par-for-the-course in my industry, in my part of the world), and while any software development suffers, fixed-price-fixed-schedule suffers from these kinds of politics the most.

It's probably better that you didn't see me licking the desk, judging from the taste, there was more there than whiskey on it. --

Oh, and one more thing (3.00 / 2) (#51)
by fink on Sun Jan 30, 2005 at 02:13:37 AM EST

A strengthening of the overtime rule. Not only is each extra hour of overtime less effective than each hour of normal time, it works to make your normal time less effective and efficient too; tired people don't do as efficient a job as those who've been given a chance to rest. Anecdotal experience over multiple projects in my workplace is that once people have clocked 15 or more extra hours on top of their standard forty, they're less effective than if they'd gone home after doing their forty, even ignoring those who "work overtime" by reading Slashdot. I think, but can't confirm, that this rule is borne out in studies as well.

What's your time worth to you? If your personal time is worth $0 to you, then working overtime is reasonable, excepting the efficiency problem. Chances are your personal time is worth a lot more than your work hours time; I know mine is. And no, I don't work a second job, I just value my me-time.

While hiring more people isn't the answer to schedule problems either (see Brooks' Mythical Man-Month for the canonical essay on this; the correct answer of course is to allow appropriate amounts of time and the proper development lifecycle in the first place), it's a better answer than forcing unpaid overtime.

It's probably better that you didn't see me licking the desk, judging from the taste, there was more there than whiskey on it. --[ Parent ]

Hypercapitalist Answer (3.00 / 2) (#55)
by Peahippo on Sun Jan 30, 2005 at 03:49:33 AM EST

Well, the obvious thing to do from the Hypercapitalistic standpoint is to pay LESS for each hour of overtime. Let's say a corporation has to pay 0.5 times your sub-40-hour rate for overtime. Knowing that, you'll make sure you complete your work within those 40 hours. No more of this "time and a half" bullshit reward for stretching out your 40 hours into 50 or so.

See, it's all part of the grand plan of the Ownership Society. You are responsbile for everything, since you are an owner. Your own your labor time, so it can only stand to reason that you have to be responsible how it is used.

[ Parent ]
That would work well. (3.00 / 2) (#56)
by fink on Sun Jan 30, 2005 at 04:22:53 AM EST

Except for one minor problem: management of some companies all too often forget that they don't Own You, and treat employees as if they do. And, all too often, it is management's unrealistic demands and/or inability to properly manage, not necessarily the employee slacking off, that lead to unpaid overtime being "needed".

There's another "capitalist" reason why refusing to work free overtime is, to my mind, reasonable; companies that can't manage their employees well enough to complete their work within the alloted forty hours (either through lack of efficiency on the management's part, or lack of efficiency on the employees' parts -- with the requisite lack of proactive "management" of said problem) don't deserve to survive.

Unpaid overtime is, in my view, nothing more than charity (No, the company going broke doesn't exactly help me, but I'm going to cheerfully ignore that point for now).

You wouldn't find management down on a street corner, cup in one hand, cardboard sign in the other. Equally, you won't find me handing my spare time or change to someone else without a very good reason.

[ Parent ]

Blasphemer! (2.80 / 5) (#67)
by Peahippo on Sun Jan 30, 2005 at 02:04:35 PM EST

Oh, there you go, blaming the management again.

Sure, I was outsourced recently, and my new management may as well work in yellow ponchos with big red hats just to make it honest ... cuz all they seem to do is "put out fires". My boss is working 60 hour weeks, and his boss is working 7 days a week (if his calling my boss often on Saturday and Sunday is any indication).

Why do they do this? Why, for the bonus plan, of course. And for the more basic reason is that their entire corporate culture is so inept that nothing useful can get done in 40 hours while also correcting the fat flow of errors down the pipeline of workers. I have never seen a company of this size (over 2000 employees) that makes so many basic mistakes.

Why do they still exist? Well, they are well paid from their clients (Proctor & Gamble, Fifth Third Bank, Cincinatti schools, etc.). And that's the beginning and end of the Hypercapitalistic argument.

But we cannot just blame the management. Like many foolish Americans, each has looked at their mortgages, outstanding car loans for expensive gas-guzzling wagons, multiple credit-card bills, empty bank account, etc., and has concluded in some unvoiced way that they must either support all this Fascism or simply join their parents. Joining their parents means shoveling snow instead of having a snowblower (--or more likely, instead of living in a condo and having the snow-cleaning tasks covered by the monthly association fee); it means having one car that you repair yourself; it means having a modest home; it means setting the thermostat to 62 in winter. It means everything that the Fox network has already thoroughly discredited in glorious and living color.

Luckily for a person like myself, America's economy is still so huge and diverse that I can "live like my parents" and still live very well in comparison to 19th Century America. I can leverage my (relatively) low-energy living into a cash cushion that I'll need to survive the major economic pitfalls that I've already endured and must continue to endure as more Fascism rears its ugly head. I'll also need to save wealth for the aged years when that utter farce called Social Security attempts to pay me "benefits" that can only produce a significant shortfall. Living a low-energy life will be good preparation for that era, too.

Corporate management in America is just a terror of lazy selfishness. It is sociopathic and overall psychotic. Once we understand that, we can make adequate plans to shape our lives in response to this assault upon the common prosperity (said assault attempting to reap limited, even falling gains that will simply be concentrated ... not to produce a general prosperity).

As for unpaid overtime ... well, I've never run into it myself. I do know what my answer will be if I ever do encounter it: NO. Even if I'm made a salaried man, at some point the answer will still be NO (probably after 45 hours, or after 50 hours intermittently). Of course, my life now has an unshakeable rule that allows me to survive such an attitude: large savings. It is vastly unfortunate that too many of my fellow men are not in that position, and furthermore tend to hold my position in utter contempt. I do admit to enjoying their suffering when I see it. Those who live by such swords must eventually die by them. A person is not simply the equation of worker+consumer. A person is a person.

[ Parent ]
Time and a HALF? (3.00 / 3) (#72)
by perringaiden on Sun Jan 30, 2005 at 08:31:47 PM EST

As a coworker of fink, I can proudly say that our company in this country (Australia) believes that a worker on salary should do 60 hour weeks 'for the good of the company'. On one project it was only after double-digits of months of overtime that they decided to start paying overtime at the same rate as the normal hourly scale, because people stopped doing the time without it. We had no incentive to work the extra hours as it didn't gain us higher pay rates, but we had no way to get the project back on schedule without working 60-80 hour weeks anyway.

Don't make me come down there...
- God.

[ Parent ]
How terribly unfortunate ... (3.00 / 4) (#73)
by Peahippo on Sun Jan 30, 2005 at 09:25:34 PM EST

... that a standard 60-hour week is not good for the employee. Reduce your liabilities and just quit. There's no need to reward wage slavery, even if you do receive compensation for the extra 20 hours now.

Somebody has to tell your management that the Industrial Revolution has long been over and the need to work your life away is similarly over. The infrastructure that people died to build is still here. If they want to ship a product, it can go over paved roads, by rail, by air, and by boat. Furthermore, the shipping carton won't be full of bullet holes (and won't be missing 10% of the contents at each hand-off) by the time it gets to the customer. Food and fuel are easy to get. So what's the fucking problem?

Of course, your company may stop growing for some time, but that's not a problem either ... that is, unless there's insatiable greed driving it. Then to hell with the company if that's the case.

The workers of the world have to learn that you can't negotiate with the other side if the other side wants everything you have.

[ Parent ]
Ahem. (none / 1) (#76)
by fink on Mon Jan 31, 2005 at 05:32:22 AM EST

"[...] but we had no way to get the project back on schedule without working 60-80 hour weeks anyway."
I think you meant "[...] but we had no way to get the project back on schedule." :-)

If the schedule doesn't, or isn't allowed to, because Realistic Is Bad, match up with the requirements and the architecture, there's no way working 60-80 hour weeks (or doubling the number of employees) can recover it. Even ignoring that Big Design Up Front and other non-iterative lifecycles (and even iterative lifecycles!) don't lead to accurate or realistic estimations in the first place.

[ Parent ]

Time Estimates x 3 (1.75 / 4) (#53)
by circletimessquare on Sun Jan 30, 2005 at 03:10:45 AM EST

as best explained by Scottie from Star Trek:

Mister Scott is explaining to the young engineer how to come across as a miracle worker. He says something like: 'Tell the captain it will take you 3 hours to fix the problem, lad, when you know it will only take about 1. That way, when you leisurely fix it in 2, you'll still come across as a miracle worker!'

So, so true: ALWAYS overestimate your time requirements by a factor of 3 so you can take your sweet time but still look like a hero... this is especially important if you get paid by the hour or are worried about job security

The tigers of wrath are wiser than the horses of instruction.

Yeah (none / 1) (#81)
by ucblockhead on Mon Jan 31, 2005 at 05:50:29 PM EST

More details here.
This is k5. We're all tools - duxup
[ Parent ]
and open source? (none / 0) (#74)
by metagone on Sun Jan 30, 2005 at 10:55:31 PM EST

does this have any application or relation to open source development? or any other type of loosely structured software development model?
totally different (none / 1) (#82)
by QuantumG on Tue Feb 01, 2005 at 02:25:50 AM EST

Developing open source is all about getting as many "new features" into the revision control system as possible. It doesn't matter if you fixed 100 bugs cause no-one looks at the stats in the bug tracker. All that matters is the number of lines you have in the CHANGES file. Open source developers know this, that's why they refuse to give anyone access to the repository. If they make everyone give them patches they get the line in the CHANGES file: integrated patch to do <funky new feature>. What's even better is someone like Theo from the OpenBSD project who will outright reject any patch you send him, tell you you're a jerk and then 2 months later silently implement the same feature in a totally different way, adding his own line to the CHANGES file.

Gun fire is the sound of freedom.
[ Parent ]
politically speaking (none / 0) (#94)
by metagone on Tue Feb 15, 2005 at 04:14:53 PM EST

what then is the CHANGES file in polisci terms. because i do not really understand how getting your name big in the CHANGES file will affect your power-base or your potential to build/increase your power.
[ Parent ]
Of course it does (none / 0) (#84)
by Estanislao Martínez on Wed Feb 02, 2005 at 12:15:31 AM EST

You only read articles about open source software development.  You read this article.  Therefore, this article is about open source software development.

[ Parent ]

Scaring article (3.00 / 2) (#91)
by svampa on Sun Feb 06, 2005 at 08:00:26 PM EST

How the stomach tries to corrode the lungs, while the lungs try to asphyxiate the heart tries to dry the stomach.

The most disturbing paragraph:

As part of his empire, you are contributing to his status: he doesn't want to get rid of you even if you're useless. You're only likely to be fired if the company as a whole is reducing numbers, and in that case no amount of work guarantees safety.

Of course if you are a really lazzy guy you can get fired now. But the disturbing thing is that if you are hardworker your future is decided in a top CEOS commitee, that doesn't think you are good or bad, the don't know you, they don't have any opinion about you.

Your fate is written, and depends on stadistics, macroeconomy, your age, in which department you work, where is your office (country state), how many other employees souround you.

Where has hard work gone? There is no reward, there is no punishment, everything is a macabre lottery.

Conclusion (none / 0) (#92)
by Scrymarch on Mon Feb 07, 2005 at 06:40:53 AM EST

(This came together too late for me to add it and others to cut it out of the wiki ...)

Software is used in a business to capture business processes, and a business process is just a new name for red tape.  For this reason a software professional must not only be a skilled engineer but a skilled bureaucrat.

Software, like politics, is the art of the possible.

i think (none / 0) (#96)
by keleyu on Sat May 14, 2005 at 09:25:55 AM EST

The workers of the world have to learn that you can't negotiate with the other side if the other side wants everything you have.

Haha (none / 0) (#97)
by soart on Mon Jun 20, 2005 at 11:41:10 AM EST

Haha!What a good story!
Politics-Oriented Software Development | 97 comments (94 topical, 3 editorial, 0 hidden)
Display: Sort:


All trademarks and copyrights on this page are owned by their respective companies. The Rest © 2000 - Present Kuro5hin.org Inc.
See our legalese page for copyright policies. Please also read our Privacy Policy.
Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
Need some help? Email help@kuro5hin.org.
My heart's the long stairs.

Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!