3

I have observed a correlation between a customer ordering software of "good enough" quality and the same customer not willing to pay for good engineering practices (unit testing, code reviews and the like) that many times that I would call it causality. Still, I am having hard time coming up with any logical reasoning behind such thinking so I would appreciate some insights from the community here.

As I see it, the engineering practices mentioned above have effect on only two quality attributes: maintainability and, to a lesser degree, reliability. Except for throw-away prototypes, I can hardly imagine a customer in their right mind who would want to get software that

  • crashes every now and then (although I realize that MTBF expectations vary depending on the cost of error), and/or
  • incurs considerable maintenance costs down the road.

On the other hand, other quality attributes such as scalability or performance are not directly affected by the engineering practices (if we don't count architecture reviews which are kind of from another league). What's more interesting, relaxing one or more of these could lead to way more considerable cost reductions, while not following proper engineering practices might as well lead to increasing project costs due to so called "endless debugging / stabilization cycle"

I should be missing something important since the preference to "save" on not doing software development properly is so prevalent among customers.

Please enlighten me :)

gnat
  • 21,442
  • 29
  • 112
  • 288
DmytroL
  • 141
  • 4
  • 3
    Maybe because the costs of non-optimal software development are actually lower then the costs of doing it the "proper" way. – Pieter B Jan 20 '15 at 13:09
  • see also: [Dealing with management that does not see value in improvements that are not immediately visible to the user](http://programmers.stackexchange.com/questions/132852/dealing-with-management-that-does-not-see-value-in-improvements-that-are-not-imm) and [Why can't the IT industry deliver large, faultless projects quickly as in other industries?](http://programmers.stackexchange.com/questions/158640/why-cant-the-it-industry-deliver-large-faultless-projects-quickly-as-in-other) – gnat Jan 20 '15 at 13:13
  • This is odd. Doing things right isn't any more costly than doing things slapdash... – Telastyn Jan 20 '15 at 14:02
  • 1
    @Telastyn In the long run doing it right is cheaper. But in my experience people tend to look at a prototype -- especially if it includes a lot of "eye candy" -- and think that it's almost "done". And consequently budget a ludicrously insufficient amount of time to "finish" the software. Or they'll insist that the project is a "one-off" or "throwaway" ... and ten years down the road some poor soul is still maintaining it. In these scenarios, doing it "right" is never an option. – David Jan 20 '15 at 16:15
  • @David - poppycock. The old joke about being 90% done with 90% to go is there for a reason. Not just prototypes are outlandishly underestimated. Doing it right is always an option. Always a viable option too. – Telastyn Jan 20 '15 at 16:28
  • 1
    @Telastyn In my experience, IT / development / project managers will tend to side with the customer. They may (privately) admit they know it's not really a one off, but you'll still only be given 2 weeks to do what really should be 2-4 months worth of work. Your choices at that point are (1) throw something together or (2) put in a lot of unpaid overtime on something you've been told isn't that important (and disregard instructions from management to boot). I fail to see how doing it right is a viable or any other kind of option. – David Jan 20 '15 at 17:41
  • @David - or (3) say no. And yes, I've done it. And no, it never resulted in me being fired. – kdgregory Jan 20 '15 at 17:57
  • @david - you're missing my point. "Throwing something together" takes just as long as doing things well **even in the short term**. – Telastyn Jan 20 '15 at 18:10
  • @Telastyne, I might respectfully disagree. I can throw a databound GridView tied directly to a sql implementation into a web project reeealll fast. Compared to a properly encapsulated, testable solution anyway. – Graham Jan 20 '15 at 18:33
  • @kdgregory I *have* seen people fired for saying no. And while that has not happened to me personally, I'm pretty sure that pointing out the risks associated with taking shortcuts has cost me in terms of raises and/or promotions. – David Jan 20 '15 at 19:20

6 Answers6

5

I've never yet seen a customer who asked for poor-quality software. However, what they do want is the cheapest software, and they want it as soon as possible.

The cheapest and quickest way to develop software is to throw something together as quickly as possible, then debug it until it does pretty much what you wanted, and doesn't crash too often.

At that point the developer can ship the software and bill the customer. The seller is happy because they get paid. The purchaser is happy because they got what they ordered very quickly at a low price.

The end-user gets buggy and unreliable software. But the end-user isn't the one who makes purchasing decisions.

Long-term maintenance costs are not a consideration at any point in this cycle.

Simon B
  • 9,167
  • 4
  • 26
  • 33
  • 2
    I don't agree that "the cheapest and quickest way to develop software is to throw something together as quickly as possible". There is some level of tradeoff. If you don't understand what you're supposed to be building (understand the requirements), you could design and build something that works perfectly, but doesn't meet the needs of the customers. There needs to be some level of requirements and design up front to understand the customer's needs and environment. Having to throw everything (or a lot of the implementation and test code, anyway) away and start again would not be cheap or fast – Thomas Owens Jan 20 '15 at 13:23
  • 4
    @ThomasOwens you don't want to know how many "throwaway" prototypes are actually sold as a product. – Pieter B Jan 20 '15 at 14:45
  • 1
    @PieterB I've seen it done. That doesn't mean it's the cheapest and quickest way to develop software, though, because it's not. – Thomas Owens Jan 20 '15 at 14:46
  • 1
    @ThomasOwens that's your opinion. – Pieter B Jan 20 '15 at 14:51
  • 4
    @PieterB It's backed up by facts. Like the cost of defects - you get your requirements wrong, it costs more to fix them post-release than it does in requirements. If you go through and build and ship a system and you have the requirements wrong, that means large portions of your design, your implementation, your unit tests, your integration tests, your acceptance tests are all wrong and need to be redone. It's cheaper to get each part right quicker. That's an advantage of the agile methods - you deliver small slices, so you can get feedback before you have a large system "complete". – Thomas Owens Jan 20 '15 at 14:53
  • 2
    @ThomasOwens While I tend to agree with you, in my experience most clients are only looking at the short-term cost. And if the seller can bill the client for something that was thrown together quickly, then bill them again for bug fixes ... they (the seller) have an incentive to *not* point out the long term costs. – David Jan 20 '15 at 16:21
4

I think your reasoning is flawed because you consider "best practices" as boolean.

However, it's not a question whether you apply them or not. It's "how much" you apply them.

For example testing: you can do a couple of manual tests, cover the basic tests automatically, make an extensive automated suite, test also all your libraries/dependencies, double-check it by third parties...

For example code quality: code as you go, take time for a clean design, refactor often, double check everything, triple check by third parties, formal proofs...

Everything has a cost. Basically, the more you want to ensure that you software is bug free, the more it costs. The testing suites and frequent refactoring can quickly be more than the development itself. Now, what's the cost of a bug? ...every client is somewhere on this price/bug curve.

Some people just want something basic and would prefer to live with a bug once in a while rather than pay the extra bucks. There are plenty of examples for this:

  • people prefering a free tool even if it's known to have several quirks
  • people just wanting a prototype
  • people wanting software quick/cheap because they need quick ROI to stay afloat
  • people who don't want to spend a lot on software

there are also other extremes. Software for aircrafts, aerospace financial and medical application are tested so thoroughly that even tiny changes quickly require millions because a lot of stuff has to be thoroughly verified. And don't even think of updating an open source library ...or even use "normal" hardware! ;)

Here, it is also frequent that the same module is implemented in parallel by independent teams. The modules are then run in parallel. If at some point their output differs, some kind of decision making takes place, like taking a "majority wins" approach if there are three modules available. ...so, are you ready to develop the same software by three different teams just to ensure it is reliable? ;)

dagnelies
  • 5,415
  • 3
  • 20
  • 26
3

From what I have encountered, usually, to build what can be considered as good software, one needs to have a clear set of requirements, maybe not all of them, but at least a set of core rules which will not change. From this, you then choose your architecture, design patterns, languages and frameworks.

The problem with this is that most of the times, the client themselves do not really know what they want. They will usually know what they will want to achieve, but when you start asking questions as to why they want certain functionality as opposed to other functionality, most of them usually blank out. To add insult to injury, some clients could get offended with all your questions since they deem them to be excuses so that you do not do the work and as a waste of time.

Clients usually want solutions fast and they want them cheap (in the short run at least). They do not really care what you did as long as you deliver what they asked for. From my experience, clients will always go for the quick solution even if it will require loads of maintenance. Taking months to properly design a system which is easy to upgrade is something which, from experience at least, does not happen.

npinti
  • 1,654
  • 10
  • 12
3

This really depends on the reaction of the customer when they get software they don't like. Very few will say, "Gee, you were right. We should have had tests." but most will feel like you should have been able to make those "simple" changes anyway.

If you continue to struggle with customers, you need to stop asking them if they want you to create tests. Provide quotes based on your expert opinion for doing quality work. Do you ask them if they want you to use and IDE that is more productive or if you should automate the build?

Customers need to understand they are assuming the risks when they create restrictions on a project. Instead of saying, "I told you so." you should get in the habit of saying, "No."

JeffO
  • 36,816
  • 2
  • 57
  • 124
  • This is something we have eventually come up with. Still, there are customers who are sticking their nose into every person-hour in the estimate and you need a lot of creativity explaining why a simple change takes, say, 10 person-hours, because you just can't admit you have included code reviews and unit tests :) But, oh well, that's a completely different story – DmytroL Jan 22 '15 at 09:37
  • 1
    @DmytroL - Movies, books, and music all have post-productions. Even a rock star can't write a 3 minute song in 3 minutes. – JeffO Jan 30 '15 at 01:08
1

There are already several good answers.
I would add that sometimes time to market is one of the requirements. For example, there are industries where a large fraction of sales are generated at trade shows; that means a hard deadline, and if you miss it, you've lost opportunity and probably market share. In such a case, it's typically necessary to have your product ready for "the big expo" -- even if it has a few bugs or you had to incur some technical debt.

David
  • 450
  • 3
  • 6
0

Delivery Quality can be expressed as a function of cost and time.

Future cost of software for maintenance and enhancements can only be expressed as function of current delivery quality.

"Good enough is fine" --> I can live with the occasional crashes, maintenance cost, increased future feature adding cost..what I need NOW is a good enough software.. not a bad business decision under given circumstances (of cost and time)..in such cases goes out of the window are extra (less) lines of codes, refactoring, unit tests to some degree, and so on..

"Good enough is fine" and "I am also not seeing the increased future cost for maintenance and enhancement" --> I am an idiot and you are an unfortunate soul happen to work for me.

Senthu Sivasambu
  • 83
  • 4