# evolving software

This topic is 4799 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

I have some problems with a piece of software and I'd like to hear your suggestions how I should proceed. The software I am working on is a rather simple tool written in PHP, which can be executed on the web by the web master. I did not write it myself but got the code in order to change/add features. It was very ugly code, everything remained in one file, (~60KB) no functions or over structuring elements. I then tried to create some functions which eliminate redundances, but it remained hardly understandable. From time to time, I'm asked to fix some bugs, add new features or change something. But it's clear, that after every new feature, some bugs show up. This comes mainly from the fact that there are still many redundances. I hand the software to my client, he checks it and nearly always discovers some bugs.. My question is, whether I should go on like this. What are your experiences? If I rewrite the software, I have to pay it myself. (my client wouldn't understand why he should invest money, when the tool does not change its function) The problem is, that I don't know what features should be implemented next. I am not sure, whether I could cope with this in a better way, if the software had been rewritten. What do you think? Does good code pay off?

##### Share on other sites
If the client wants a completely bug free work, then a rework would be in order; redesign it and use the existing code as a reference while building the new one.

It's a rare case that starting over is the right thing to do. Maybe you could budget a little extra time for refactoring and to create regression test the next time something needs to be changed. The truth is, the bugs probably bother you more than your client.

##### Share on other sites
I'm guessing your client is happy as long as the code performs as expected. A re-work of the code would definetly be something for you rather than the client.

You have to do the cost-benefit analysis.

How long does it take to make a maintenance change with the current system?
How long would the change take if the system was structured correctly?
How long would it take to refactor the code?

With some numbers:

Number of changes per year: 20
Avg. cost to client per change: $200 Avg. time per change: 8 hours Rate of Earning =$25/ph

Time to refactor code = 60 hrs
Cost to self = 20 x 25 = $1500 Time to make change in new system: 1 hour So the cost benefit would be something along the lines of. In the old system you earn$500 in 20 hours
In the new system you earn $4000 in 20 hours minus the refactoring cost of$1500

Old system: $500 New system:$2500
For 20 hours of work. Of course there is no benefit if you can't fill the freed up hours with other work ;)

These numbers are purely hypothetical and exagerated to emphasise the case.

##### Share on other sites
This is where my opinion differs very muchly from my boss'.
My boss thinks that any new feature should be implemented as fast as possible in the current software (we're not talking about 60KB of sourcecode here), because it would cost him less in development costs.

However, my opinion is that the shortcuts you take in development, come back to in tenfold during the support of the software (note, this an opinion and not much based on personal experience, as I don't have any personal experience in running a business).
One example: I was asked to implement a new feature (a relative big one), and after a week or two my boss complained it was taking too long, while I was trying to make a neat solution. So I finished it quickly on his request, and over the months I've had to make numerous bugfixes caused by this feature and spent hours on the phone with people with problems with it.

Secondly, apart from support, a properly designed piece of software can easilly be expanded with more features, while adding something new to a piece spaghetti usually takes more time.

So, whether refactoring your code is worth it depends on two things:
1) Given support (maintainability) - bad software might need more support (your time) due to more bugs that can be present.
Even if you have a SLA with your customer where the customer pays periodically for support, it's better to have bug-free software IMO. It will cost you less time in support, and the customer will probably uphold the SLA anyway incase of unexpected problems (they can't affort downtime).

If you don't give any support or guarantees, it doesn't matter how bad your software is. Once you got the money, they depend on your goodwill for fixes (or any law that forces you to deliver a properly working product).

2) Required expandability - implementing new features is easier in properly written software.
In my opinion it doesn't matter much if you're paid by the hour or by feature for new features, proper software has the advantage. The customer wants as many new features as possible for the least money. If adding a "simple feature" takes too much time (ie: costs too much) the customer might leave. If you're paid by feature, any time you can save is in your advantage.

If you don't intend to add new features to your software, make it work as aggreed. Any shortcut taken during development is in your advantage.

So, in short it depends on how you deal with your customer and how many change-requests you receive. I'm a strong believer that good software holds the advantage if you need to provide any of the two (support or upgrades). But don't take my word on it as I have no personal experience in running a business.

Good

Amen

1. 1
2. 2
frob
16
3. 3
4. 4
5. 5

• 15
• 13
• 14
• 75
• 22
• ### Forum Statistics

• Total Topics
632145
• Total Posts
3004345

×