Ethics of software development deadlines

[Octavo]

Consider the following hypothetical situation:

A publicly traded company decides to offer service X to the public. It takes the internal decision to have this service available to the public by the end of the next year. The deadline is decided by taking into account when it would be most profitable to implement service X. The CEO announces service X to the public and states that it will be available at the end of next year

A software development team is assembled, informed of the deadline and told to get under way. The team works extremely hard to get service X ready in time, but the deadline is just too tight. Nearing the deadline, management tells the team that they expect the team to pull out all the stops to get this done on time. If the CEO cannot announce service X at the shareholder meeting next month, the share price will take a hit.

----

This situation and similar situations play out every day across the software development industry. I believe this to be unethical for the following reasons:

The team had no input into the setting of the deadline.
The team did their best and in many cases will put in significant unpaid overtime.
If it looks like the team will miss the deadline, pressure is brought to bear by management to encourage more (usually unpaid) overtime.

If the team fails to deliver, the share price will fall, but everyone still gets paid, including the CEO. If the team does deliver, the CEO will inevitably be compensated handsomely for his stewardship of the company. The team will be lucky to see any sort of bonus.

----

Have you seen situations like this play out before?
Do you believe it's as common as I seem to think it is?
Do you believe it is unethical? Why?

What can we do about it?

 

[Brian-M]

Serious question... why exactly would it matter to the company if the share price took a hit?

It's not as if their share price has any bearing on their profits.

 

[abaddon]

I don't recall who originated this, but to paraphrase:

You can have whatever product you wish developed fast, you can have it developed cheaply and you can have it developed correctly. The catch is you can only have two of these attributes for any given project.

Sure, you can have whatever project developed fast and cheaply, IF you forgo functionality and accept the plethora of bugs.

Sure, you can aim for no bugs at all, but then you must accept that you will incur much more time expended and cost accrued.

And so forth.

This is why Microsoft releases versions of windows and then spends it's life releasing updates to fix the things they never thought of.

By and large, it is not unethical. But I have seen examples up to and including outright fraud.

 

[epepke]

I'm not sure why ethics are the most important thing here. It's rude and crude and manipulative, but it seems to be accepted ethically, and that's really the only thing that can be said about ethics.

It's stupid, manipulative, and cruel. But this doesn't seem to matter much. This is the software industry we're talking about.

The big question to me is why there are no longer companies that buck the trend and drive these scummy companies out of business. The only thing I can think of as a hypothesis is that companies have gotten together and decided that things must be done this way. There is a lot of evidence for this, a lot involving collusion that is quite clearly against the law.

Of course, one can also wonder why the laws aren't being enforced. That's a thing, but it's still in some sort of nebulous moral/ethical realm and is not entirely realistic.

What is realistic is that companies who behave this way spend more by getting new employees, don't actually produce functioning software, and just toddle along producing crap that everybody hates. Yet people seem to put up with this.

It is always, always cheaper to keep employees by treating them well than hiring new ones. More profits at lower cost always, always come from doing the right things and treating employees humanely, unless it's a really low-margin enterprise like growing bananas. Any technology company who is seriously into making money would naturally do this.

Yet they don't, preferring to whack off to management porn. Well, in a competitive market, that's OK, because another company can just eat your lunch by doing the right thing. But there appears to be this overwhelming force for companies to destroy themselves.

Part of this, I think, is the CEO phenomenon. The people running the companies don't care about them. They care, for reasons of the cleanest most enlightened self-interest, about siphoning off as much as they can and jumping away from the burning wreck with their golden parachutes. I don't blame them, but I really do wonder why so many worship their panties.

 

[DarthFishy]

You which kind of software deadlines I hate the most? The kind I set myself when I promise a client something will be ready by date X. I struggle to find a balance between giving myself enough time and not making the deadline unreasonably far in the future.

I have one for tomorrow. So I'm procrastinating on ISF instead of working on it. Which doesn't really help my situation.

 

[DarthFishy]

Actually typing the above reply made me think of something specifically concerning software deadlines.

I think that software developers are easier to con into work long hours over time because of the nature of the job. I'm a pretty lazy person, but once I get debugging or coding I can get into a zone where I will work for long periods without a break. And I'm only a part-time programmer (which I do as part of some part-time work I occasionally do). I suspect proper developers are even worse when it comes to this.

Any thoughts?

 

[SezMe]

Serious question... why exactly would it matter to the company if the share price took a hit?

It's not as if their share price has any bearing on their profits.

Because upper management gets bonuses based on share price. If a CEO, for example, has been paid in a gazillion shares that (s)he cannot dump for five years, stock price matters a LOT.

 

[SezMe]

I think that software developers are easier to con into work long hours over time because of the nature of the job. I'm a pretty lazy person, but once I get debugging or coding I can get into a zone where I will work for long periods without a break. And I'm only a part-time programmer (which I do as part of some part-time work I occasionally do). I suspect proper developers are even worse when it comes to this.

I'm that way. If I get deeply into a problem I can't let it go. Doesn't matter if I'm at the office or home. Playing with the kids or schlepping the wife. I have that problem in the back of my mind all the time.

That said, Octavo, I don't think this behavior is limited to software. It happens to all kinds of people whether they're in private industry or working for a governmental agency. Or what kind of job they have except for the most menial ones.

 

[Brian-M]

Because upper management gets bonuses based on share price. If a CEO, for example, has been paid in a gazillion shares that (s)he cannot dump for five years, stock price matters a LOT.

Ah, so the real question is whether or not it's ethical for the CEO to damage the company's long-term profit and reputation by producing a substandard product on deadline for the sake of his own financial benefit instead of having the company produce a good quality product behind schedule.

Although, if they can't dump the shares for five years, then a short-term price-drop for being behind schedule wouldn't really be an issue.

 

[Octavo]

Serious question... why exactly would it matter to the company if the share price took a hit?

It's not as if their share price has any bearing on their profits.

SezMe already answered this, but from the point of view of the hypothetical, it is a ploy to get the development team to commit to yet more overtime in order to prevent a financial hit for the whole company. It feels like subtle psychological coercion to me. Maybe I'm just over-sensitive?

I'm not sure why ethics are the most important thing here. It's rude and crude and manipulative, but it seems to be accepted ethically, and that's really the only thing that can be said about ethics.

It's stupid, manipulative, and cruel. But this doesn't seem to matter much. This is the software industry we're talking about.

unethical synonyms: immoral, amoral, unprincipled, unscrupulous, dishonourable, wrong, dishonest, deceitful, disreputable, unconscionable, fraudulent, dirty, unfair, underhand, devious, slippery, bad, wicked, evil, sinful, iniquitous, corrupt, depraved, villainous

I would submit that this practice is unethical - you say it's accepted ethically and that's all that can be said. I disagree. Yes, it's accepted. That doesn't mean it's ethical by fiat.

Part of this, I think, is the CEO phenomenon. The people running the companies don't care about them. They care, for reasons of the cleanest most enlightened self-interest, about siphoning off as much as they can and jumping away from the burning wreck with their golden parachutes. I don't blame them, but I really do wonder why so many worship their panties.

I agree with the above 100%

You which kind of software deadlines I hate the most? The kind I set myself when I promise a client something will be ready by date X. I struggle to find a balance between giving myself enough time and not making the deadline unreasonably far in the future.

Accurate estimation has long been an issue in development. When considering your own ability to finish something, people tend to underestimate significantly. It is also a fact that no matter how well defined the problem is, there will always be "gotchas" that the developer didn't consider and these inevitably cause things to take longer than estimated.

In my experience the only reasonably accurate method of estimation for software development is story and magic estimation under SCRUM with an established team.

Actually typing the above reply made me think of something specifically concerning software deadlines.

I think that software developers are easier to con into work long hours over time because of the nature of the job. I'm a pretty lazy person, but once I get debugging or coding I can get into a zone where I will work for long periods without a break. And I'm only a part-time programmer (which I do as part of some part-time work I occasionally do). I suspect proper developers are even worse when it comes to this.

Any thoughts?

I'd say you're right. Once in the zone, the entire day can whiz past seemingly inside 5 minutes. However, one cannot do this indefinitely and I find my tolerance for required overtime to meet deadlines I didn't agree to has dwindled dramatically the older and more experienced I've become.

 

[Spindrift]

This problem is not unique to software development.

Accurate estimation takes some work defining parts of the system. When the estimate is done, double it, then you have an estimation that is probably somewhat realistic. Every time a vice president or director opens their mouth to contribute add another day.

 

[Beelzebuddy]

It's not a matter of poorly estimating the time. It's a matter of correctly estimating the time, including how much their employees can be driven to work above and beyond the clock.

While the problem is not unique to software development, software development shows the worst of it. The lowest man on this particular totem pole are game testers, who are paid minimum wage to pull repeated hundred-hour-week death marches, considered less then incompetent when it comes to their input, and in fact have negative job security: they are nearly guaranteed to be fired at the end of every development cycle, because management is well aware they can be easily replaced.

The historical solution to terrible working conditions and hours has been to form a union. Which considering the independent nature of many geeks, will be like herding cats. Good luck.

 

[Trebuchet]

This problem is not unique to software development.

You can say that again. I experienced this repeatedly in aerospace.

Accurate estimation takes some work defining parts of the system. When the estimate is done, double it, then you have an estimation that is probably somewhat realistic. Every time a vice president or director opens their mouth to contribute add another day.

Don't forget the tendency of management to ask the engineers for budget and schedule estimates, then cut both by 1/3 and blame the engineers for going overbudget and past schedule.

 

[SezMe]

This problem is not unique to software development.

Accurate estimation takes some work defining parts of the system. When the estimate is done, double it, then you have an estimation that is probably somewhat realistic. Every time a vice president or director opens their mouth to contribute add another day.

I worked with an old mossback engineer who had hundreds of construction projects under his belt. He said the first thing the winning bidder does is move the project office trailer onto the site and staff it with bean counters and sharks whose only assignment is to basically rewrite the contract adding every contingency known to mankind.

 

[dudalb]

I don't recall who originated this, but to paraphrase:

You can have whatever product you wish developed fast, you can have it developed cheaply and you can have it developed correctly. The catch is you can only have two of these attributes for any given project.

Sure, you can have whatever project developed fast and cheaply, IF you forgo functionality and accept the plethora of bugs.

Sure, you can aim for no bugs at all, but then you must accept that you will incur much more time expended and cost accrued.

And so forth.

This is why Microsoft releases versions of windows and then spends it's life releasing updates to fix the things they never thought of.

By and large, it is not unethical. But I have seen examples up to and including outright fraud.

"Do You Want It Fast Or Do You Want It Good" is a problem in many areas of business.
And there is no single easy answer. There are situations in which a mediocre program that works OK if not all that great now is better then a great program later on.

 

[mijopaalmc]

Actually it's about ethics in...

 

[epepke]

I would submit that this practice is unethical - you say it's accepted ethically and that's all that can be said. I disagree. Yes, it's accepted. That doesn't mean it's ethical by fiat.

Good thing I'm not saying that. What I am saying is that one cannot declare it unethical on the basis of what one personally finds reprehensible. Well, you can, but it won't do anything, and there is a time after early adulthood when the ego boo from futile exercises loses its idealistic appeal.

Ethics is a code of behavior.

Now, if you have some sort of plan to change the ethics that are practiced, then I'm all ears. Without that, it's just a fart in a hurricane to say it's unethical. I don't have a plan apart from 1) voting against Republicans, and 2) finding ways to put these schmucks out of business. The trouble is that 1 is extremely difficult, given A) redistricting, B) big money, and C) the tendency of progressives to boycott elections so that they can stay home and smell their own farts.

 

[fuelair]

Good thing I'm not saying that. What I am saying is that one cannot declare it unethical on the basis of what one personally finds reprehensible. Well, you can, but it won't do anything, and there is a time after early adulthood when the ego boo from futile exercises loses its idealistic appeal.

Ethics is a code of behavior.

Now, if you have some sort of plan to change the ethics that are practiced, then I'm all ears. Without that, it's just a fart in a hurricane to say it's unethical. I don't have a plan apart from 1) voting against Republicans, and 2) finding ways to put these schmucks out of business. The trouble is that 1 is extremely difficult, given A) redistricting, B) big money, and C) the tendency of progressives to boycott elections so that they can stay home and smell their own farts.

I've already voted - all Democrat or non-conservative independents with no Democratic competition.

 

[Modified]

In general, driving software engineers to work in this way decreases long-run total productivity because more mistakes are made and poorly structured quick-and-dirty code is developed. Beyond some point, it even decreases total short-term productivity (they work more hours and get less done), but they do it anyway.

I'm in a somewhat unique position in that I've been developing the same software project for almost twenty years, and I hope to continue for many more years. I write code with a very long view, because I know I need to maintain it for a long time. And after all those years, I've learned to give fairly realistic deadlines. When it is useful to push for a deadline, I know that working long hours only helps for a short time.

 

[Wowbagger]

Have you seen situations like this play out before?

Quite often. Ugh.

One of my first consulting jobs was for a project that had already blown past a crucial deadline, and they made the classic mistake of assuming the hiring of more developers (temporary ones, at that) would get everything done faster, for the new one.

In this case we actually pulled it off, but not without several full weeks of working overtime towards the end. The good news, for me, is that I was paid by the hour, so got paid for all of that freakin' overtime!

I thought it was crazy then. But, I am used to that sort of thing, now.

Do you believe it's as common as I seem to think it is?

In my experience, yes. But, that might change as people become more familiar with how software is developed.

ETA: Software is not the only industry that has this issue, but it gets the brunt of it because it is more abstract than most others. It will take time for the brains of more people to adapt, and plan better for those levels of abstraction.

Do you believe it is unethical? Why?

It is mildly unethical to pull release dates out of thin air, like that. But, not necessarily criminally so. Part of the due process of establishing deadlines should be to consult with experts about them.
But, at least no harm was intended (usually).

What can we do about it?

As much as I would love to blame it all on the managers, I think a lot of the fault lies in the overconfidence of developers, themselves. We can conceptualize a lot of the work easily enough, but often underestimate subtle complexities involved in safe and effective implementation.

So, as a general rule, one must always assume it will take twice or three times as long as you first assume it would take. Though, it’s kinda shoddy just to rely on doing things like that.

A bunch of more things we can do:

1. Develop in phases. Promise to have some initial important features ready for the first roll-out, and provide a time-line for introducing more over time.

2. Manage feature-creep. Try to stick to the original specs, and ONLY change them if you discover a REALLY GOOD reason you MUST do so. Not because you suddenly think you thought of a brilliant idea, or because competitors have nifty things you are compelled to duplicate. Save it for later!

As a side-note: Make sure the initial specs are very carefully established in writing. Especially if you find yourself working for people who really know jack-squat about software development (or even the Internet, itself). They think you can just magically "poof" new features into existence, at the drop of a hat.

3. Get into the habit of front-loading timetables with all of the harder tasks, first. We developers are too often tempted to just do all the easier tasks, first.

4. If there is a ton of R&D necessary for the project, DON’T set a hard deadline, at all, until all or most of that R&D yields reliable results.

5. Don’t be afraid to scale-back a couple of times, if you must. Timelines can be re-arranged once or twice without anyone in the public caring all that much. (But, don't do it too often, because then people will start to notice and care.)

6. Developers can pretend the deadline is sooner than the actual one. Work hard to get everything all tied up by your own mental deadline, so you can spend all the remaining scheduled time on extra levels of "spit and polish"; and security. (It never hurts to review everything for security holes, such as possible injection attacks).

7. Perhaps, if possible, work overtime in the first days of development, to make the rest of it coasts along easier. And, you'll less likely work overtime at the end.