Re: de-inventing the wheel (discussion)

I agree with dep, and will go a step further. I believe that doing constant upgrades is valuable because it forces the re-evaluation and refactoring of old code. (I'm going out on a limb here, but I think that this raises some interesting points, so I'll just keep sawing at the branch...)

Good, alterable code is living code. Any code that a company is afraid to change is dead code. If programmers refuse to upgrade because they fear breaking code, then think of how hard it will be to change that code to add a feature when a customer needs it. On the other hand, if the code is strong enough to withstand a few upgrades, it's a good sign that it's pretty robust code.

If code has a good set of regression tests behind it, then upgrading is easy-- just do the upgrade and run the tests, and you can have confidence that you haven't broken anything major. Most companies don't encourage writing automated regression tests, just as most companies don't encourage writing living, flexible code.

On the other hand, companies will argue that they're in the business of making money, that they don't pay programmers to introduce bugs into already-running code but to add new features instead. There is some justice to this position, and one must make reasoned choices as to how much time and effort one is willing to expend to keep code high-quality. However, I feel that such reasoning is overapplied. In the long term, good, robust, upgradeable code saves a company far more time and money than any number of short-term cost savings.

The sad truth is, though, that many companies right now are going for short-term gains because they don't expect to be around long enough to HAVE a long term. So I have some sympathy for the devil in this case, although I'm not quite his/her advocate.

stephen

Comment on Re: de-inventing the wheel (discussion)

Replies are listed 'Best First'.

Re: Re: de-inventing the wheel (discussion)
by dragonchild (Archbishop) on Jun 21, 2001 at 21:16 UTC

However, that position is only defensible if the programmers have the following characteristics:

Intimately understand every business requirement, including how they might change
Are involved in the project from the initial design phase through retirement, especially in timelines
No new programmers join the project
No one else is involved in any way with the project

Ever.

So, testing, especially regression suites, become extremely important. However, to write a solid regression suite is a project in and of itself. By its very nature, you cannot have the programmer(s) write it. They don't know enough about the requirements and they know too much about the implementation.

You should never have the programmer(s) sign off on the testing, anyways. They know too much about the code. Testing, imho, should be (primarily) black-box testing. Programmers, by their nature, do white-box testing, which is good, but isn't stringent enough for release sign-off.

That said, upgrading should be easy if the programmers were able to write the application in a modular enough fashion. Upgrades very rarely affect more than two or three logical sections of an application. The problem with upgrades is that those logical sections have historically never been separated out. Not even with OO code. (I worked on a project which had objects, but encapsulation was violated left and right.)

There needs to be better design and requirements. If that is done, better coding will necessarily follow. Bad requirements => Bad design => Bad code => No upgrading.

[reply]


We don't bite newbies here... much
	PerlMonks