Is writing good code an asset or a liability? (maintenance contracts)

Question

We all know that writing quality, well-factored code is an asset for code maintenance, ease of bug-fixing, and development of new features, but I would like to approach the subject from a different angle.

If a piece of software is written well enough that it solves the client's problem(s) perfectly for their workflow, what is their incentive to purchase, or continue to purchase, a maintenance plan/contract?

Even if the software doesn't include nice-to-have X and whiz-bang Y, they can still get on with the job with the software as a tool instead of as an obstacle.

I'm not suggesting that bad code should be written intentionally for the sake of profit, because that will almost certainly fail in a number of ways. What I'm getting at is this: can software be written so well that you actually lose extra business? In this context, what is your experience with a really well-written piece of software that you or your company has produced?

Answer 1

Do you have clients whose workflow or requirements never change? I have not worked extensively with clients, but it is my impression that they will continue to evolve their business and come up with new requirements from time to time. If you write good code, then during maintenance, you can focus on supporting these new requirements rather than fixing your old stuff.

Answer 2

I suppose there is a tension there, yes. But my intuition is that:

• Even if you anticipate future directions well, there's always some new feature needed anyway, and
• Any benefits stemming from maintenance of shoddy code will be outweighed by the positive image you create by giving the customer something that they find satisfying (rather than annoying) to use.

Answer 3

The time you don't spend fixing bugs can be just as well spent developing new products: there's no need to "make more business" if you produce quality software.

Answer 4

I consider it an asset. While you may be able to ensure that you spend more time maintaining your code by writing it badly, you can charge more at the beginning if you have a long history of writing solid code.

Also, think of it as a marketing tool.

• Customer A purchases a good product that requires ongoing maintenance that is expensive.

• Company B you charge a little more atthe beginning, but the product requires less maintenance, and the changes are cheaper.

I believe that Company A are probably less likely to purchase new software, update their current software, or recommend your services to others than Company B.

Answer 5

Quality, well-factored code sells itself.

In my opinion, doing a great job lends itself to more work. If you do a poor job, you will not be the choice for maintenance or new work. Maintenance plans do not guarantee more profitable work.

Answer 6

I don't think you can never write something so well that you loose business. There are always new problems and the current problems always change, sometimes day to day. Each day has new opportunities for development time, whether it's fixing bugs or adding new features or developing new systems, regardless of the quality of the existing software. If this wasn't true we wouldn't be writing new software after the 60's.

Answer 7

My first thought is that if you are writing code so good that people don't ever need you again, you'll have all the work you need in the world from now until eternity. The amount of terrible to mediocre code out there would almost ensure that someone who could write code that well would always be employed.

But leaving that aside, I think a lot of companies look at maintenance contracts as a form of insurance. In the same way you buy home insurance and auto insurance, hoping to never need it, it provides peace of mind and financial comfort in the case where you do need it. I would think companies would do the same thing with maintenance contracts, especially larger companies, where the insurance to CYA is almost always at a very high premium.

Answer 8

In my experience, you'll be doing maintenance in any event, and not for bug-fixing reasons.

Why?

Not all requirements are shaken out of the tree at the first time of asking. Some aren't even apparent until a user has seen your working system and asked for a little bit more. Unless the scope of your project is incredibly narrow, you are almost guaranteed some form of maintenance. Knowing this, you should ask yourself whether you want to revisit good code or bad code.

Having said all that, you need to be pragmatic when coding for clients, especially if you're on a fixed price. Under those circumstances, you probably won't have time to finesse something as much as you'd like.

You also need to keep in mind the fact that the next developer to work on your system may not be you. If you have bolted together a load of crap, your client may hear about it when your successor inevitably complains about the state of the codebase.

Personally, I try to write the best code I can within the allowed constraints - and would prefer to get repeat business because someone enjoys my work rather than endures it.

Answer 9

I think that this is the "broken window fallacy" in somewhat hidden form.

Answer 10

Good answers so far, but I feel they don't address the underlying issue. There's an old saying:

You work to eat.

Not terribly catchy, annoyingly fundamental, and rife with meaning. The food here is literal, but also metaphorical.

When you put in your full effort, the code you craft becomes the "food" you consume, from an intellectual perspective. If you constantly create the best code you can, it will continue to improve you. This food will grow your mind the way real food grew your body.

The phrase also implies that effort will always be a part of our existence. Get used to it, make peace with it. You will always work. Even if you could avoid effort, you shouldn't: without the mental food that work creates, your mind would starve.

If you create a product so perfect that no one needs you any more, great. Start on the next perfect product. Anyone so skilled that they deal fatal blows to our daily limitations can start hacking apart the next limitation. Now you feed everyone. We all grow, and so does your reputation. Suddenly everyone wants your services.

A stock boy at the supermarket returns the next day to stock shelves again. A butcher has to cut new meat every morning. A janitor cleans the same halls, scrubs the next layer of scuff marks.

They don't get to work once and profit two or three times. Neither do you.

You can try to frame this is a discussion of corporate screw-jobs, stabbing at the man, not building your own obsolescence, etc.

Stop it.

This is just laziness putting on a fancy new suit.

You work to eat.

Answer 11

Planned obsolescence is common in just about any market. And this is really what you are talking about.

This includes code as well, I think. Adobe, Microsoft, EA etc. They don't build things they know will break down but they do build things they know will need to be upgraded eventually.

But I think that is only useful if you are doing mass-production type things.

You got others that simply admit that to make money they need long term contract and you must buy said contract to use their software. They are selling a service and software and it usually is some massive package that is generic enough to be useful a wide number of individuals within a certain market. But that generic quality along with the complexity lends to the long term contract model.

But then there are niches in the market that the mass-production products cannot satisfy and the big enterprise stuff is to complex/expensive to justify.

It is this area you are talking about I think. And if you can't offer this market quality then what do you offer?

Offering bells and whistles you talk about all comes down to the market you play in. If their are no competitors then don't do them or charge extra for them. Once you have competitors then you might have to do them just to keep up.

So this isn't a development question, this is a business question.

Answer 12

for all but the most basic projects (e.g. a business presence website with 5 basic pages), you will almost certainly have on-going maintenance in the future

this maintenance is not a matter of 'bad coding'. it is a combination of: 1) bugs which will be found post-launch, 2) features the client will think-up post launch

this is why its good to setup some kind of maintenance contract/sla with the client (e.g. Maintenance Blocks' - Managing Change Requests)

-- LM