Fog Creek Software
Discussion Board

why take shortcuts in Software Development?

it all seems that we take short cuts in Software Development. From no requirements, to poor project planning, all the way to lack of testing. We try to save time/money.

We know we are doing it. But, why do we continue to do it?
I believe that most professionals KNOW the right way to develop software. It just never seems to happen.

i'm feeling disappointed in the industry...

Wednesday, July 28, 2004

Well, in my case, there's no business case for doing development "just right".  Testing?  My users want the software now.  If there are no catastrophic bugs, and they can derive value from it, then they get it.  Basically, my users want "good enough, right now" as opposed to "perfect, later".

When there's a business reason to need more, then we go back and refactor.  If we did all of the work up front, we would incur a high opportunity cost, because we were so busy focusing on this one piece of software that would make/save us $10,000 that we completely missed the other one that would make/save us $100,000.

I do sympathize though.  I can't count the number of times I've had to release software that wasn't done yet so I could move on to other projects that were more pressing.

On a slightly related note, my wife asks "Are all programmers anal retentive bastards?"  I always tell her that only the good ones are.

Steve Barbour
Wednesday, July 28, 2004


I believe demand often outstrips the resources required  to meet the damand and the result is that people take shortcuts.  It's certainly short-term thinking; when you take shortcuts it's often more costly in the long-run, but sometimes compromises have to be made to get things done.

Ewan's Dad
Wednesday, July 28, 2004

i'm not saying that we should do all the features perfect and right the first time out. i do understand that there is a business and they are willing to assume a certain amount of risk.

if there weren't bugs, then we wouldn't have jobs! I know that sounds terrible. i just think there is a proper way to handle bugs, etc.

whatever happened to developing software the "right way"?

Wednesday, July 28, 2004

"Are all programmers anal retentive bastards?"  I always tell her that only the good ones are.

Good one Steve & how true it is.

In programming many things require black and white (right & wrong) thinking:

if then
syntax errors - code won't compile
run time errors
DLL Hell (versioning, deploying)
variable names
server names
etc etc

When programmers enter the "real" world they tend to think in the same manner.

Therefore we get labeled this way by individuals from other disciplines that don't understand.

Wednesday, July 28, 2004

Pat, it is because we are good little soldiers who follow the orders of our commanding PHB. If the boss wants it done in half the time it should normally take, we still try to please the guy and get it done. If the boss claims we lack the time for all the things that developers have known should be done for the last 30+ years, well, then we take the shortcuts commanded of us. I call this the nuremburg defence.

Wednesday, July 28, 2004

Maybe you should define what "the right way" is?

Even If we as an industry could come up with a common definition of what that might entail it wouldn't mean didly squat without government regulation. Without rules that everyone must follow most business owners and the managers working for corporations will do whatever they want to do no matter how stupid their decisions might seem to you and I.

Wednesday, July 28, 2004

i do feel that there are several different methodoligies that can be used. And you need these different methodologies for different types of projects. But, my point is to use the methodology. Don't just take short-cuts that will hurt in the long-run.

Wednesday, July 28, 2004

I agree that it is the lack of a commonly accepted, workable software process which is predictable and repeatable that leads to this stuff.

As others have said, what IS the process?  How long SHOULD it take? 

Management's reaction to this uncertainty is to try to cut the schedule as short as possible, so at least the software creators are highly motivated and busy all the time.  They won't have time to indulge in perfect code, perfectly tested.

If they didn't, they fear that the schedule will stretch to infinity, with perfectionsim and added features meaning the code will NEVER be delivered.

The problem is that currently creating software is more a craft than an engineering discipline.  It is conceivable that software will NEVER have predictable schedule, it may just be the nature of the beast.  Every project is different, the tools keep evolving, even ideas of what makes a good design (OOD?  DFD?  Lock down requirements?  Let them float? ) keep changing.

Personally, I believe there can exist a software development approach which can have predictable schedule, good milestones to give management accurate reports of progress, and a verifiable model early in the process to drive the milestones and give some assurance of accuracy.

When this exists, you can use the model to tell management "Really, this is really how long it is going to take."  And then you can execute, and really-really take that long to do it, and the product has good quality and the features promised and is delivered on-time.  And you can do this for project after project.

Once this condition becomes true, MAYBE then we can have some credibility when we push back against a too short schedule.  It is still going to be human nature to want the product sooner than later.

The recent history of software engineering still shows the ideal has not happened yet.  Projects are routinely delivered late, over budget, with less functionality than projected at the beginning.  Thus the urge to short the schedule.  Thus the urge to take shortcuts.

Wednesday, July 28, 2004

wow! good post. You sound like the Mythical Man Month or Rapid Development.

i'm just professionally struggling with that we know the right ways to do things and we don't do them.

thanks! btw - what part of the country do you work?

Wednesday, July 28, 2004

to get to the real question: are you a manager hiring?

Wednesday, July 28, 2004

I'm in the Washington D.C. area, where if you don't have a security clearance, times are tough, but if you do, can you say Homeland Security?

And no, I'm not a manager.  I appreciate what manager's need in order to manage effectively, though, as well as what engineers need in order to produce quality solutions.  I'm still trying to build tools and processes that serve both purposes.

Wednesday, July 28, 2004

I would recommend the book Death March if you are trying to get your arms around the issues of overly tight planning and why things haven't improved much in the last ~30 years.

Wednesday, July 28, 2004

i read it last summer on vacation. i came back and started interviewing! i finally landed a new job and started 3 mos ago. It's definately better! But, i'm still amazed at the shortcuts.

this summer is the "Pragmatic Programmer" and "Coder To Developer"

Wednesday, July 28, 2004

As someone said earlier, everyone wants the software NOW, not later.  However, taking shortcuts is often a false savings, but we we *know* if we do things "The Right Way", it'll take longer than the allotted time.  So we take a shot in the dark to see if we can bypass The Right Way and get it done on time.  Of course, this hardly ever works for any non-trivial project.

Wednesday, July 28, 2004

t0: we deal with uncertainty which makes impossible to know it all.
t1: we don't know it all, then we don't really know what we are doing
t2: we put ourselves in a corner by not knowing what we are doing
t3: we take shortcuts because in the corner we've put ourselves in there's no other choice.

... few years later ...

t4: we become clinically cynical because we cut too many corners forced by no-win contexts we create due to our acknowledged ignorance, ignorance that is intrinsic to the uncertainties we deal with on a daily basis.

Wednesday, July 28, 2004

I have no data to back this up, but I think that in some degree it is due to the fact that software "entrepreneurs" are far too often programmers with a good product idea who found a company and 1) don't believe that software can be anything but buggy and unreliable, 2) don't understand what running a mature, long-term business as opposed to a startup entails, and 3) don't know the limitations of their own knowledge because they have no experience from elsewhere.

Jeff Kotula
Wednesday, July 28, 2004

One of my favorite saysings is "The price of perfection is bankruptcy". That's kind of what AllanL5 said, you can take infinitely long to develop perfect software without a process, or you can take infinitely long to build the perfect (repeatable) process, or you can ship the product and make money. Pick one.

And regarding Steve's wife's question, "Are all programmers anal retentive bastards?", my parents were married.

Tom H
Wednesday, July 28, 2004

These problems actually happen in all professions.

Ask some who had a house built if the contractor got it done on time.  Or look out your window when you’re driving down the street at the road construction project where they had to tear up new concrete to put down pipes.

It just happens more in software.  Why?  Because it is easier to hide problems in software.  Most problems with projects in all professions are found by humans doing physical inspections, and while we can look at source code, it isn't possible to actually look at a running executable (just the side effects).  This means it’s hard to find the leaky pipe until the foundation is eroded away.  Some we try to develop processes to follow that no one can prove are 100% good.  So we argue about what is best and everyone does what they want.

In other professions, users can watch the workers, or inspect the final product and tell if someone is an idiot, so doing stuff well is a business incentive, but they cannot easily look at the 1's and 0's that they are paying for in their software, so stupidity plays a lesser role in determining success in the computer industry.  (After all if someone tells you it takes 30 miles of pipe to hook up your house from the street, your going to know something’s wrong, but what about 10000 lines of code?)

Thursday, July 29, 2004

Shortcuts result from way projects are budgeted and costs recorded.  Generally the cost of a project is seen as just the money spent from initiation to release, with perhaps a short support period afterwards -- instead of costing it for a 5 or 10 year period.  Issues that make maintenance more difficult or even directly affect the business have a cost that isn't allocated to the project.

When a software bug results in a multimillion dollar product recall, or software maintenance problems delay a product release by several months, if those costs were allocated to the project and managers were held accountable there would be far fewer shortcuts taken.  Only then would they see the benefit of letting the project take 2 more months in order to avoid increased costs over the next few years.

Management at the highest levels may indeed care about the long-term costs of software problems. But, as long as project managers and developers are judged primarily on their ability to deliver by a given date they will optimize for that date and pay little attention to the long-term implications.

Thursday, July 29, 2004

Many threads ago… I started a conversation about development methodologies:

I asked people if they used or not formal methodologies. The replies are relevant to the OP’s question.  My contribution to Patrick is based on that conversation and my experience…

Basically, I agree with “there is no single methodology to solve all problems”, “there is no single methodology designed to fit every single situation…”.
It is my opinion that software development is a social process, and as that, it is complex, unpredictable and sometimes messy (why? Because we are humans not machines).  I don’t think that we all could accommodate ourselves to follow to-the-line one methodology in every situation that we come across.  There will always be exceptions to the rule, new situations for which no rules have been written… etc.

What I believe is in developers as intelligent and adaptable people.  I think good developers must know when to follow methodologies and when to move away and improvise.  If you are assigned a big project to be delivered in very little time, well, you should know that maybe the waterfall life cycle will not be useful.  Perhaps XP or prototyping + improvisation will work better. In that situation that would be the “right way”.

Cecilia Loureiro
Friday, July 30, 2004

*  Recent Topics

*  Fog Creek Home