First Law Of Programming
First Law Of ProgrammingLowering quality lengthens development time.
Quality software takes the least amount of time to develop. If you have code that is simple as possible, tests that are complete and a design that fits just right, additions and changes happen in the fastest possible way because the impact is lowest. Consequently, if you hack something out, the more you hack the slower you go because the cost of addition or change grows with each line of code.
Suggested rephrasing: Attempting to rescue a poor schedule by reducing quality actually lengthens development time.
Suggested re-rephrasing: Attempting to rescue a poor schedule by reducing internal quality actually lengthens development time. -- WM (The rationale for this rewording is to make it clear that we are not talking about renegotiating usability with the customer, rather we are talking about our own development process -- the internal view.)
Not always true. Read below.
Another rephrasing: Development velocity (dependent variable) is directly proportional to development quality (independent variable) Or something along those lines anyway. How about increasing development quality increases development velocity and decreasing development quality decreases development velocity.
I think what this author means is that developing a product of lower quality than what will be accepted by the customer lengthens development time because it takes more time to do it over than it takes to do it right. Generalizing a bit, whenever the quality of intermediate results is out of whack with the expected quality of the product, it will waste time. This is also true when you try to build it better than it needs to be. -- WaldenMathews
I'd like to suggest that there's more to it than that. We all know that in the interest of time, we often let quality slide. The impact of that, however, slows even the delivery of the lower-quality software. The code is harder to read, therefore harder to evolve. It is almost certain that quality will slip below even the lower level we might accept. The code we write that should work, doesn't, because of defects lurking elsewhere, and we are slowed down in rooting them out. The simple fact is, it takes longer to produce code once it falls below some level of quality measured in clarity, freedom from duplication, and correctness -- even if we accept that low quality as being somehow OK. -- RonJeffries
I think we should differentiate between "quality" and "integrity." I would categorize knowingly and intentionally developing a less than satisfactory product is an integrity problem not a quality problem. I agree that I could greatly reduce my development time if I was content to declare development done after typing in virtually anything. If we assume a conscientious development team, however, I believe they will be most efficient when producing well crafted code. I find it hard to envision a developer who would choose to develop code that in that developer's mind was done more poorly than necessary. I would also anecdotally note that I find that poor code seems to concentrated in the areas where developers struggled with the code; places where the final code took much longer than expected. Part of the issue is that "quality" and "development time" are not particularly well defined, and by using different definitions, different conclusions arise. --WayneMack
Corollary: shortening the schedule lengthens development time.
The less time you have to do it, the more time you ultimately spend re-doing it to make it work. In my experience PointyHairedBosses have a real hard time understanding this.
The only solution to this is to refuse to accept a time frame that is less than you are comfortable with. Period. The time you have to complete a project may be created by someone else but the power to accept or reject it is yours. If you accept an estimate you know is wrong you have professionally validated it and the fault is no longer your boss's -- it is yours. If you are not comfortable with an estimate do not accept it. Afraid of the negative consequences this might have on your career? Think instead of the positive consequences it will have on every hour of every day you work. -- RodneyRyan?
Your discomfort may come from project definitions that are too large or vague. Ask, "what part of this would you like to see next week?" You may also be concerned that only Joe knows some crucial part of the assignment. Then ask, "How about Joe and I working on this together?"
My experience building products in startups--making lots of mistakes along the way and hopefully learning from them--says that both this law and the corollary are off the mark as stated.
Lowering quality lengthens development time in the long run, but can shorten development time in the short run if you're starting from a good place. It's a trick that you get to pull once, or maybe twice, before TechnicalDebt builds to the point of slowing down development. I've been part of pulling this trick a couple of times, when "making the numbers this quarter" at a startup had particularly high stakes.
The corollary sounds reasonable on the surface, but the fact is that most developers are lousy estimators. Some developers who have been burned a few times will err on the conservative side. Sometimes a team doesn't know what it can do until it gets challenged. Some challenges introduce a focus that's lacking while a team is carefully laying out a grand plan. Sometimes a team doesn't gel until the stakes get raised. In some situations the solution isn't to refuse schedules you aren't comfortable with, it's to be up front with your discomfort and be open to the possibility that you may learn and grow through the experience. -- DaveSmith
I no longer believe that you can use TechnicalDebt to speed up, even in the short run, though I must have believed it for a long time, since I've done it often enough. Today, instead of lowering quality, I'd reduce scope and use simple solutions. I feel confident that there's no problem that I could solve with a "low quality" solution that I couldn't solve just as quickly, or more quickly, with a simple solution that didn't compromise quality. A big part of the trick is ContinuousIntegration, so that the product is always ready to ship. -- RonJeffries
TechnicalDebt accumulates when you reduce scope and use simple solutions. The quality that is so important in the context of this page is the code quality that lets you pay back that debt without surcharge. For Ron this is instinctual so he doesn't even think of it as debt. However, I view the strict avoidance of technical debt as equivalent to BigDesignUpFront, which can be made to work, but is rarely, if ever, faster. -- WardCunningham
TechnicalDebt, at least as I understand it, doesn't accumulate when you reduce scope and continue to refactor. Rather, when you decide to make a near-term decision to keep scope constant but reduce internal quality for forgoing refactoring, the pent-up need to refactor gets scored under TechnicalDebt. And if you decide to forgo rigorous test cases and rely instead on lightweight smoke testing by developers, TechnicalDebt accumulates, as does immediate risk. -- DaveSmith
This law is partly aimed at people who say "we do not have the 6 months you estimated so you will have to hack it out in 3". A perfectly reasonable request - a sloppy job takes less time, right? Right - a single, small and isolated job can be hacked quickly out. However, since software builds on itself and you have to use what you wrote then to write what you need now, that growing sloppy code will slow you down the further you go on hacking.
I all too commonly see programmers cave in to outside pressure for various reasons and say "sure I can try to hack it out in 3" and then fail in a flurry of bad code, taking 12 months to do what they would have done within the estimated 6 months if they had taken it slow and careful. This mistake of just hacking it out in 3 is commonly promised and rarely fulfilled, and if so always in a storm of unreadable source code that is discarded in the next release.
What usually provokes an estimate that is a lie is this. The manager is talking to the big boss and is offered a project. The big boss asks "when can you have it done?" The manager blurts out "I can have it for you in 6 months!". He then goes to his programmer and asks for an estimate, hoping that it is less than the 6 months he promised the big boss. When the programmer says it will take at least 9 months, the manager panics. He cannot go back to the big boss and revise his estimate, so he says to the programmer "I hate to tell you this but we only have 6 months -- can you just hack it out?" The programmer thinks for a minute and says "well, I can try..."
18 months later the project is a mess of unreadable source code, the programmer is exhausted and the manager frustrated. The problem is not that the programmer started with a time frame that is a lie -- why would he have said he could hack it out in 6 if he knew he could not (the manager never even heard the word try)? The problem is that the programmer sucks! (thinks the manager) So, the project is canceled, the source code discarded and the programmer fired.
This could have been prevented if the programmer had said when confronted with the managers demand for 6 months "I really want to give it to you in the time frame that you are suggesting, but that is impossible and hacking it out will just take longer." Then, other options for meeting the deadline, such as reducing scope that Ron suggested, could be explored. Once the manager is taught that hacking takes longer he will certainly not pressure anyone to do it!
If the manager does not accept the programmer's estimate and does not entertain other options for meeting the deadline then the manager is not asking the programmer for an estimate. He is forcing the programmer to accept a time frame because of some other agenda unrelated to programming. The programmer can then decide if he wants to accept that agenda or not, but that is a different story.
In the industry sector that I work this mistake of promising to hack it out is literally responsible for hundreds of millions of dollars wasted on garbage source, tens of thousands of miserable programmer hours and projects that were estimated at a sensible 1 year, attempted to be hacked out in 6 months, and 2 years later being restarted yet a 3rd time.
The majority of this could be prevented if when confronted with a demand to just hack it out the programmer explains that lowering quality lengthens development time.
-- RodneyRyan?
No disagreement here, though this suggests a rephrasing of the law:
Attempting to rescue a poor schedule by reducing quality actually lengthens development time.
-- DaveSmith
Rodney and Ron, I agree with the bulk of the positions you are stating. In particular I appreciate your insight into how early the quality issue becomes a real factor. Part of that picture is the skills and preferences of the developers involved. I am particularly intolerant of Big Balls of Mud, while I cannot help but observe that others are much more tolerant and capable of working with such products. The decision on how messy to allow the work to become ought to take into account the people involved as well as the short term and long term constraints. This is a hair that can be split and split to infinity, and knowing that I will never be comfortable with any single rule on how to make judgments about it. I may be repeating some of Dave Smith's points above.
When I posted my original response at the top of this page, my principal intent was to make sure we discriminated between internal quality and external quality in this discussion. My initial reading of the opening statement at first perplexed me because it seemed counter-intuitive. If the customer will settle for very low quality, then that's a smaller project and should take less time. (This may lead to a debate over the meaning of the word "quality". If so, fine.) To reduce to absurdity: if the customer wants zero quality, I can deliver in zero time. But this was not the intended topic.
The one thing I will add to Rodney's discussion above is my discomfort with the "either or" tone of some of it, which may underly a desire to control an aspect of these situations which cannot be controlled. It is often unreasonable to expect to educate a manager on the complex dynamics of quality within the scope of a single project. Therefore, giving a manager an ultimatum is not a win-win strategy. I'll bet Ron would be quick to point out that when there is doubt among programmers and lower management about what can be delivered in the proposed time frame, the most practical and cooperative posture to take is to be honest about the perceived risk and to offer a risk reduced alternative which would also be attractive to upper management. This is undoubtedly going to be in the form of an evolutionary development plan. In the course of that evolution, the developers can honor their own needs with respect to how much internal quality is needed to meet the ultimate goals. If the experience teaches upper management something, celebrate.
A very real, very common situation in which the customer will accept selective low quality is when a buy decision is based in part on a feature checklist, and where the actual end user isn't the the one making the buy decision and writing the check. Once I understood this, some management motivation that I'd previously written off as being evidence of pointy-haired stupidity made a lot more sense. -- DaveSmith
Note that the customer has some minimal concept of quality. Consider the following dialog:
Customer: I need a program to do foobar, and I need it now. I don't care about quality.
Me: In that case, I'm already done. Just run "foobar.exe" on your machine. That'll be $100,000.
Customer: When I type "foobar.exe", I get "File Not Found".
Me: Well, obviously I had to leave a few errors in to meet your aggressive schedule. I'll be happy to fix them, for a price.
You couldn't actually get away with this, because the customer has some minimum concept of quality. This may be as low as actually receiving an executable that the operating system can actually load (even if it dumps core later on), but there are standards. I used to work on Web browsers, where the standards weren't that much higher, though. -- JohnBrewer
Q: Should this really be a LAW? Shouldn't we reserve words like "law" for something fairly provable, as they do in science? I'm skeptical that anything in software engineering is understood well enough to be a law just yet... (See ThereAreNoLawsOfProgramming.) Also, why "programming"? I'd like to think that our industry has grown beyond thinking of what we do as just programming. How about Theorems or Observations of Software Development?
A: Law is short for surprisingly fundamental and important observation. Programming is the activity of reasoning about the future behaviour of a computer and expressing decisions from that reasoning in a formalism translatable to machine instruction. On this site it is considered to include activities often attributed to specialties elsewhere. See JustaProgrammer.
Yours appears to be a rather loose, personal definition of "law". My dictionary (Webster's New World, 2nd ed. 1978) has 13 definitions under law, but none of them even come close to yours. Excluding all the definitions related to legal/judicial, religious, and sports, we have these: "8. a) a sequence of events in nature or in human activities that has been observed to occur with unvarying uniformity under the same conditions: often law of nature; b) the formulation in words of such a sequence [the law of gravitation, the law of diminishing returns]; 9) any rule or principle expected to be observed [the laws of health, the law of grammar]; 10) inherent tendency; instinct [the law of self-preservation]; 12) Math., Logic, etc. a general principle to which all applicable cases must conform [the laws of exponents]."
Now, I'm sure we can find plenty of counterexamples to the statement "Lowering quality lengthens development time." This blows most of the definitions cited above, because they require "unvarying uniformity" or "all applicable cases must conform." The only one you could stretch might be "10) inherent tendency; instinct" -- but even this one is stretching it thin to call a law.
So why not couch the statement with the appropriate caveats, and say something like "Lowering quality can end up lengthening development time, especially when done in an ill-considered attempt to reduce development time." And call it "<your-name-here>'s Warning on Software Project Management."
All you have to do is find a counterexample and present it here. No complaints about how some people have chosen to name or not to name a Wiki page -- just a counterexample, or counterexamples, please.
By a counterexample, I mean a situation in which you can cut corners and significantly speed up the delivery of something with business value.
There is no mention of "business value" in the statement "Lowering quality lengthens development time." If we're going to have a "law," I suggest it include all assumptions, definitions, and qualifications.
On that, see the argument in StandardDefinitions. Any theory of software development (which is what the First Law hints at) will come with its own operational definitions, which are part and parcel of the theory. Sure, but they need to be stated; they can't just be left implied, or anybody could defend any ridiculous theory by saying "My theory is right because of other considerations I haven't mentioned yet..." It is possible but seldom useful to argue against a theory on the basis of its definitions. Internal consistency and fit to known fact are better targets.
The First Law can be seen as a corollary to Weinberg's Law of Requirements: if a program doesn't have to be correct, it can fulfill any other requirement you care to state, including timeliness. By "correct" we can't mean "correct according to a specification" because that would be begging some important questions -- so I'd rather use "delivers the requisite business value".
I've worked on many projects (far more than I care to admit) where poor managers forced developers to cut corners -- on requirements, design, coding (no refactoring, forced reuse of inappropriate code, no reviews), and especially testing. In some cases, we actually finished "early" (and delivered crap); on most cases, we met our formal schedule (again, with crap); and yes, in some cases, it backfired dramatically and caused us to overshoot our schedule by a wide margin (in the worst case, we lived in an endless AcceptanceTest). Happy?
Were you asked for crap? If you don't deliver what you were asked for, can you say that you "finished early"?
Of course not. Very few users will ever actually say "I need something quick and dirty, and I need it in two months. Six weeks would be better. But I don't want you to pull any resources off of Big Project X. So feel free to cut corners as necessary; it doesn't have to be pretty..." But sometimes that is what the total requirements (the stated, functional requirements PLUS the schedule and budget constraints) end up doing. What will a software manager do in that kind of situation? Some will try to carefully explain exactly what trade-offs the user is making. Some will promise the moon and fail miserably. And some will push their developers to cut corners and get something quick and dirty out the door on time. As someone said above, "Fast, Cheap, or Good: Pick Any Two."
I don't understand how you can NOT see that sometimes, if you cut corners, you can still finish on time or early (and deliver crap). In no way am I saying this is a good thing; it is a thing to avoid at all costs. There are plenty of reasons to avoid sacrificing quality. I'll even say that the potential for causing a schedule slip is a very good reason for not cutting corners. (And that is what I say to managers who suggest it.) But you can't tell me that every time a project reduces quality, it will lengthen development time.
This deserves clarification : by "development time", do you mean the time elapsed until you ship what is required? Or just the time elapsed to ship something, no matter what? (See the little story above.)
These "crappy" applications that were delivered - nobody ever worked on them again? Nobody ever fixed the bugs that were in there - and nobody ever will? Otherwise... you obviously need to add that rework, repair or maintenance to the "development schedule".
Again, a mixed bag. In some cases, yes, the unfortunate souls who had to maintain the apps had struggle to fix major flaws. (In a couple of those cases, our managers had to negotiate for hours to devote to fixing "recurring problems;" I'm pretty sure that the users realized that they were paying for the corners we cut earlier.) And in some cases, no, the users just lived with "crappy" apps as-is: they still got some critical functionality they needed, and they made a conscious decision to have us work on other things (sometimes more new fuctionality) rather than fix the problems in the "crappy" apps. So obviously they got enough business value.
I think that last situation gets closer to the mark. However, I would still challenge it. We only need to prove that in all such cases a high-quality system with business value roughly equivalent to the crappy system (e.g. one with less functionality but more reliable) could be delivered in less time.
You're off in theory land, man.
Yes. But then, calling something a "law" is a matter of theory...
In the real world, you often have to work within constraints imposed by your manager and users. It doesn't matter whether you think it is counterproductive to cut corners; sometimes you're still forced to do it.
I believe you are incorrect on both counts, at least if I interpret your "you" literally. I (personally) do not have to accept unreasonable technical constraints, and nobody can force me to do so. I believe the same goes for every programmer.
Pennywise, pound foolish. Most programmers put into that situation will do their best anyway, and manage to cobble together a passable application that they aren't entirely ashamed of. Stupid? You bet! But it happens all the time in the real world. If you're lucky enough to have avoided these situations, I'm truely happy for you. But don't extrapolate your theory to the rest of us.
I don't count myself particularly lucky. It is (again) a matter of theory whether the statement "nobody can force to to do low-quality work" is true. Philosophical theory this time rather than software theory. Regardless, you can't appeal to "what usually happens in the real world" as an argument against the Law as stated on this page. We only have to prove that in principle delivering quality work would take less time.
Maybe the creator of this page should have called it SoAndSosFirstLawOfProgramming?, or better yet SoAndSosLawOfSoftwareProjectManagement?. It's certainly not widely considered the single most important issue in programming.
If lowering quality implies increased development time, then the converse (logically) should also hold. As logically, if A -> B then �B -> �A. That is, the proposition is effectively stating that decreasing the development time will increase the quality, in its strictest form (that is, ignoring the equality case, where nothing actually changes).
To me, this seems somewhat absurd regardless of your DefinitionOfQuality?, as it means that arbitrarily small time project time scale (e.g. 1 second) would lead to inversely proportionally high quality. In the limit, this leads to the logical conclusion that not doing a project gives the highest possible quality solution, which I'm not sure many customers seeking a high quality solution would accept.
I would suggest here that sadly, the scenario is multi-variate and quality along with development time are simply two of these factors. Variables such as the scope of the work also come into play, as people above have already indicated.
-- "Not increasing" does not mean "decreasing" and vice versa.
And anyway, that's the contrapositive. Converse is a -> b <-> b -> a, which is not true in the general case.
Law #1: Know what you want to acomplish before you start writing anything.
Law #2: Know what they who pay want to receive before you start writing anything.
Law #3: The goal will change AT LEAST once.
See BugFreeDoesntSell, CommitmentToQuality, DoNotWantItGoodWantItTuesday
EditText of this page
(last edited December 8, 2014)
or FindPage with title or text search