Ethics of software development deadlines

[Octavo]

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've heard and used the old, (estimate * 2) + 10 with very mixed results. Story estimation still wins hands down for me.

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.

Indeed. I'm not particularly keen on the notions of unions anyway

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.

Well, the OP did contain an invitation to speculate on how we could fix the situation. I'm afraid it was written mostly as a rant to get some things off my chest. I don't think the situation is going to change any time soon - it's just so damn frustrating that it keeps happening.

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.

That's awesome Modified - I'm glad for you. Part of why this makes me so agitated is not only the unfairness of the situation or that it keeps recurring, but exactly as you stated, in the long-term it's self defeating.

Our hypothetical service X has been developed in such a rush, that the next poor soul who has to maintain it is going to think the dev team were a bunch of incompetent morons.

 

[Octavo]

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.

This is another bugbear of mine that management seem to fail to understand time and again. Throwing more bodies at a coding problem is not helpful most of the time. It takes time for people to understand the problem, understand the existing architecture and code and then finally start actually contributing. Often you end up making the problem worse, as all of a sudden you have 3 or 4 contractors, all with their own ideas tweaking code. The flip side of course, is that while they're happy to spring for more coders, do you think they'll proportionally increase the QA team? Not a chance bud. The testers just have to suck it up.

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!

Under South African law, developers (by dint of the associated salary) very seldom qualify for paid overtime.

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

One can certainly hope so.

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).

I guess I see it differently. Making promises and then relying on someone else to deliver on your promise just strikes me as a ****** thing to do.
I believe that the deadline must be agreed to by the development team before coding starts. Once the team accepts a deadline, there can be no more whining. They agreed they could complete it in that timeframe, so it's their responsibility.

If you never consult the team or get buy-in from them on the timelines, how can you reasonably expect them to stick to them?

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.

Have you ever tried using story estimation?

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.)

Agreed so far - this sounds a lot like agile

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.

6. Guarantee this will result in the list of "nice to have" suddenly becoming the list of "mission critical features" that must be implemented before the deadline.

7. I have tried this on a few occassions to little effect. It seems like a sensible idea, but it never seems to work. Motivating the rest of the team to put in extra hours at the start of the project isn't easy and your biggest problems usually only start cropping up once you hit integration points which is generally only in the middle of the project.

Thank you for the considered response - I appreciate it.

 

[383LQ4SS]

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

You can say that again. I experience this repeatedly in aircraft maintenance

 

[Wowbagger]

Under South African law, developers (by dint of the associated salary) very seldom qualify for paid overtime.

I was lucky to have an hourly contract with that job. I don't know for certain if the permanent employees who worked overtime were paid anything extra for it, or not. But, somehow I doubt it.

One can certainly hope so.

It probably starts with improvements to abstract thinking, by the general public.

...Once the team accepts a deadline, there can be no more whining. They agreed they could complete it in that timeframe, so it's their responsibility.

I do agree, in general. Though, as I said before, sometimes teams can underestimate the time.

Have you ever tried using story estimation?

Never formally, so far. But, in jobs where there is either a lot of R&D or a lot of new things I've never worked with, I might give general estimates in a similar manner.

Agreed so far - this sounds a lot like agile

I guess that's because I happen to be an agile developer.

6. Guarantee this will result in the list of "nice to have" suddenly becoming the list of "mission critical features" that must be implemented before the deadline.

If that happens (and, yes, it might), it would only be because there is now room in the schedule to actually do it!

7. I have tried this on a few occassions to little effect. It seems like a sensible idea, but it never seems to work.

It might depend on the nature of the work. Obviously, in cases where many of the difficult points can be identified in advance.

Motivating the rest of the team to put in extra hours at the start of the project isn't easy

You don't necessarily need to do that. When you get YOUR responsibilities over with, as soon as possible (assuming it's quality work), it might be FUN to see the others' anguish over getting their parts done in time; while you either: sit back waiting, or move on to some other task they couldn't handle, leaving them in the dust.

 

[Kestrel]

Project management software can be used in one of two different ways on software development projects.

1. As a tool for managing resources during the development process.
   
2. As an implement for flogging the development team.

From my experience the second option is far more common. A friend of mine once worked on a high end project management tool. About once a week the tech support guys would get asked the same question. My project has an inflexible deadline and it is not possible to add resources. Can your program make a schedule that looks like it will work?

 

[Paul C. Anagnostopoulos]

This is another bugbear of mine that management seem to fail to understand time and again. Throwing more bodies at a coding problem is not helpful most of the time. It takes time for people to understand the problem, understand the existing architecture and code and then finally start actually contributing. Often you end up making the problem worse, as all of a sudden you have 3 or 4 contractors, all with their own ideas tweaking code. The flip side of course, is that while they're happy to spring for more coders, do you think they'll proportionally increase the QA team? Not a chance bud. The testers just have to suck it up.

I haven't developed software under a project manager since I left Digital in 1988. Have they really still not gotten to their homework assignment to read The Mythical Man-Month?

~~ Paul

 

[Fizil]

The crappiest thing that has ever happened to me as a developer was an instantaneous deadline. I was giving a presentation to a potential client company. It was me, our company's primary client liaison, and our company's president, in a room with a ton of people very knowledgeable in their business field.

So midway through the demo, the potential clients ask if our product has Feature X. Rather than letting me respond, our client liaison jumps in and says "Yes, our system does that", and our president agrees, describing how the system implements X. Everyone turns toward me to demonstrate it..... Now these guy will often ask for the near impossible of us developers, but I'd never been asked to instantly implement and deploy a new feature before

The position this put me in was quite stressful. You don't say to your boss "No, you are wrong, our system doesn't do that" in front of potential clients. I don't know how I was able to think so fast in that moment, somehow I found myself saying this is a newer feature, and unfortunately the demo system is running an earlier version of the software. I still don't know what the hell they were thinking, claiming our system did something it didn't do, during a freakin demo, where they could be proven wrong on the spot.

 

[Gord_in_Toronto]

The crappiest thing that has ever happened to me as a developer was an instantaneous deadline. I was giving a presentation to a potential client company. It was me, our company's primary client liaison, and our company's president, in a room with a ton of people very knowledgeable in their business field.

So midway through the demo, the potential clients ask if our product has Feature X. Rather than letting me respond, our client liaison jumps in and says "Yes, our system does that", and our president agrees, describing how the system implements X. Everyone turns toward me to demonstrate it..... Now these guy will often ask for the near impossible of us developers, but I'd never been asked to instantly implement and deploy a new feature before

The position this put me in was quite stressful. You don't say to your boss "No, you are wrong, our system doesn't do that" in front of potential clients. I don't know how I was able to think so fast in that moment, somehow I found myself saying this is a newer feature, and unfortunately the demo system is running an earlier version of the software. I still don't know what the hell they were thinking, claiming our system did something it didn't do, during a freakin demo, where they could be proven wrong on the spot.

When I was in the development business, I would call this the "You said that we could do WHAT!?" phenomenon. Salesmen will promise anything to get the sale. It was up to us poor slobs in the back office to perform the miracle.

 

[Octavo]

<very respectful snip>

Thanks Wowbagger. I really appreciate the responses. You've given me a few things to think about.

From my experience the second option is far more common. A friend of mine once worked on a high end project management tool. About once a week the tech support guys would get asked the same question. My project has an inflexible deadline and it is not possible to add resources. Can your program make a schedule that looks like it will work?

Lol, I know that feels

I haven't developed software under a project manager since I left Digital in 1988. Have they really still not gotten to their homework assignment to read The Mythical Man-Month?

~~ Paul

There's a whole new generation of PHB's out there Paul. It's war I tell you. War.

The crappiest thing that has ever happened to me as a developer was an instantaneous deadline. I was giving a presentation to a potential client company. It was me, our company's primary client liaison, and our company's president, in a room with a ton of people very knowledgeable in their business field.

So midway through the demo, the potential clients ask if our product has Feature X. Rather than letting me respond, our client liaison jumps in and says "Yes, our system does that", and our president agrees, describing how the system implements X. Everyone turns toward me to demonstrate it..... Now these guy will often ask for the near impossible of us developers, but I'd never been asked to instantly implement and deploy a new feature before

The position this put me in was quite stressful. You don't say to your boss "No, you are wrong, our system doesn't do that" in front of potential clients. I don't know how I was able to think so fast in that moment, somehow I found myself saying this is a newer feature, and unfortunately the demo system is running an earlier version of the software. I still don't know what the hell they were thinking, claiming our system did something it didn't do, during a freakin demo, where they could be proven wrong on the spot.

I love that story Good thinking on your feet haha!

When I was in the development business, I would call this the "You said that we could do WHAT!?" phenomenon. Salesmen will promise anything to get the sale. It was up to us poor slobs in the back office to perform the miracle.

Always beware a salesman in a slump, for some reason the recourse always seems to be "promise more", rather than "let's try and figure out why I haven't made a sale in a while".

 

[DarthFishy]

In terms of Fizil's story, it's can be nice to have a "buffer" (i.e. client liaison, salesperson) between the developers and the client, but other times (as this story illustrates) that "buffer" just makes things worse.

I have a small (really quite tiny) web development company (myself as developer and my wife as designer) and I have to be both the buffer and the developer in the same meeting.

I can sometimes see as I'm giving informal estimates in a meeting with a client how their eyes will glaze over when I mention their small little website will take 3 months to finish, so I quickly adjust my estimate to 6 weeks or whatever.

I walk out glad to have gotten the contract but pissed off at myself for not really giving myself enough time.

 

[PhantomWolf]

In terms of Fizil's story, it's can be nice to have a "buffer" (i.e. client liaison, salesperson) between the developers and the client, but other times (as this story illustrates) that "buffer" just makes things worse.

I have a small (really quite tiny) web development company (myself as developer and my wife as designer) and I have to be both the buffer and the developer in the same meeting.

I can sometimes see as I'm giving informal estimates in a meeting with a client how their eyes will glaze over when I mention their small little website will take 3 months to finish, so I quickly adjust my estimate to 6 weeks or whatever.

I walk out glad to have gotten the contract but pissed off at myself for not really giving myself enough time.

As CEO and main developer of my own company, I know that exact feeling, and not only that, but quoting prices based on hours under what you know the job will take, but being fully aware that when you tell them that the job they want done is going to cost them $1200 they'll decide that it's way too much, so instead you quote $500 and hope you can actually get it and several other jobs done in the next couple of days to cost costs, all the while knowing you probably can't.

 

[a_unique_person]

When I was in the development business, I would call this the "You said that we could do WHAT!?" phenomenon. Salesmen will promise anything to get the sale. It was up to us poor slobs in the back office to perform the miracle.

Then it's the Salesmen (and Saleswomen) who get the big bonus for doing such an amazing job at promising that you will do what will get them the sale.

 

[Meadmaker]

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



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.

There was a rather large program in my division of Hughes Aircraft at the time I worked for them, late 1980s, that became somewhat legendary. It was behind schedule, and one day the program manager issued a memo in which he insisted that every engineer on the program work 45 hours a week.

The universal response was "fine", and that's what they did. Until the memo came out, they had been working around 50 or more hours per week.


The way to deal with this, as an employee, is to have a spine and know that your work is sufficiently valuable that someone else will pay you for it if the clown you work for now gets out of line. You have to know what is considered normal for your industry, and if that's not good enough for your boss, you can find a new boss. Armed with that level of confidence, it's pretty easy to inform your boss that you have prior commitments this weekend.


As far as ethics go in the OP's question, I would say it is rarely a matter of ethics. Software estimation is hard. People make mistakes. If you promise something to a customer, ethics require you to try and meet those promises, within reason. The only time that I think it becomes a matter of ethics is if the bosses deliberately make an estimate that they know cannot be met with a normal effort level, and demand an extraordinary effort from their employees, but do not provide extraordinary compensation.

 

[Octavo]

As far as ethics go in the OP's question, I would say it is rarely a matter of ethics. Software estimation is hard. People make mistakes. If you promise something to a customer, ethics require you to try and meet those promises, within reason. The only time that I think it becomes a matter of ethics is if the bosses deliberately make an estimate that they know cannot be met with a normal effort level, and demand an extraordinary effort from their employees, but do not provide extraordinary compensation.

The bosses in this purely hypothetical scenario are board-level members who are ignorant of Software Development. There was no consultation with the developers and the deadline chosen was based upon when it would be most profitable for the company to have it done by. Ethical?

 

[Spindrift]

The crappiest thing that has ever happened to me as a developer was an instantaneous deadline. I was giving a presentation to a potential client company. It was me, our company's primary client liaison, and our company's president, in a room with a ton of people very knowledgeable in their business field.

So midway through the demo, the potential clients ask if our product has Feature X. Rather than letting me respond, our client liaison jumps in and says "Yes, our system does that", and our president agrees, describing how the system implements X. Everyone turns toward me to demonstrate it..... Now these guy will often ask for the near impossible of us developers, but I'd never been asked to instantly implement and deploy a new feature before

The position this put me in was quite stressful. You don't say to your boss "No, you are wrong, our system doesn't do that" in front of potential clients. I don't know how I was able to think so fast in that moment, somehow I found myself saying this is a newer feature, and unfortunately the demo system is running an earlier version of the software. I still don't know what the hell they were thinking, claiming our system did something it didn't do, during a freakin demo, where they could be proven wrong on the spot.

I had a similar situation with a client demoing a product that was already a year behind, except the client (President) looked at me and asked if it would do X and would the product be done by the end of the year. I said "No, it doesn't do that and it's not going to be ready until Q2 of the following year." The sales guy at the meeting almost had a coronary until the client said, "Thank you, that's the first time I think you guys have given me an honest answer. I was about to throw you out if I got lied to again."

 

[Meadmaker]

The bosses in this purely hypothetical scenario are board-level members who are ignorant of Software Development. There was no consultation with the developers and the deadline chosen was based upon when it would be most profitable for the company to have it done by. Ethical?

Insufficient data, but I will tentatively say, as presented, the situation is unethical.

The employer has a relationship with his employees in which those employees work 40 hours per week, and the employer gives them a certain quantity of money. Meanwhile, the employer has a relationship with the customer that requires them to provide products at a given price on a given date. If the employer knowingly creates a situation where the employees have to work more than 40 hours, with no increase in compensation, then I think that's unethical.

On the other hand, there may be an out for the board members. If they have no knowledge of software development, they may have sincerely believed it was possible to do everything within all of the established parameters of work weeks and salary and such. In that case, they aren't being unethical, just wrong, and possibly incompetent.

 

[Octavo]

The employer has a relationship with his employees in which those employees work 40 hours per week, and the employer gives them a certain quantity of money. Meanwhile, the employer has a relationship with the customer that requires them to provide products at a given price on a given date. If the employer knowingly creates a situation where the employees have to work more than 40 hours, with no increase in compensation, then I think that's unethical.

On the other hand, there may be an out for the board members. If they have no knowledge of software development, they may have sincerely believed it was possible to do everything within all of the established parameters of work weeks and salary and such. In that case, they aren't being unethical, just wrong, and possibly incompetent.

I do not know the mind of the board-members, but I suspect quite strongly that the board neither knew, nor cared about how long it would take. They decided that in order to maintain their competitive advantage they needed to release service X as soon as possible. Financially, releasing service X just before Christmas made the most sense, so the deadline was set at early November.

 

[Meadmaker]

I do not know the mind of the board-members, but I suspect quite strongly that the board neither knew, nor cared about how long it would take. They decided that in order to maintain their competitive advantage they needed to release service X as soon as possible. Financially, releasing service X just before Christmas made the most sense, so the deadline was set at early November.

If they didn't knowingly create a problem, there's no unethical behavior. The board (and it would usually be the executives, not the board, but that's a nitpick) did their job, badly.

You want to look for some unethical behavior in that situation? I'm going with your colleagues who put in 60 hours of work for 40 hours pay. They are the ones that are undermining the position of honest, competent, workers. Tell your boss that you didn't set the deadlines. They aren't your problem.

And keep your resume polished at all times.

 

[Octavo]

You want to look for some unethical behavior in that situation? I'm going with your colleagues who put in 60 hours of work for 40 hours pay. They are the ones that are undermining the position of honest, competent, workers. Tell your boss that you didn't set the deadlines. They aren't your problem.

And keep your resume polished at all times.

You are right of course - in this situation, the development team is allowing themselves to be exploited, but where does the onus lie?

On the employee (who has very little power) to refuse to be exploited?
Or on the employer (who has all the power) to refuse to exploit their employees?

The employer could just as easily shift the deadline out by a few months.

 

[Meadmaker]

You are right of course - in this situation, the development team is allowing themselves to be exploited, but where does the onus lie?

On the employee (who has very little power) to refuse to be exploited?
Or on the employer (who has all the power) to refuse to exploit their employees?

The employer could just as easily shift the deadline out by a few months.

Who has the real power in cases like this?

If you, the employee, can easily be replaced, then the employer has real power. If not, then he needs you more than you need him.

Trying to implement this can be inconvenient. In my case, two years ago I more or less informed my boss that I did not feel it necessary to work under the conditions he imposed, and he fired me on the spot. And you could tell that he thought he sure showed me who was in charge, and yet, the following Monday, I was back at work, for someone else, making the same money I had made on Friday. The boss, meanwhile, was behind schedule because he had a spot that he had to fill and no worker to fill it. I hadn't worked for him very long, and there was no one else knew what I was doing, so all of my work was effectively lost to him, so he got nothing from my efforts, but I got to keep all the money he had given me.

And if you have the sort of job where there are hordes of people who can pick right up where you left off, so you have no real power, then it's time to unionize so that, collectively, you once again have more power than the boss.