Re: Good programming practices and changes in requirements: how to maintain good code

[eyepopslikeamosquito]

How do you manage this situations, what are your experiences about?

The Boy Scouts have a rule: "Always leave the campground cleaner than you found it"

What if we followed a similar rule in our code: "Always check a module in cleaner than when you checked it out"

-- The Boy Scout Rule (O'Reilly)

At work, we try to follow The Boy Scout Rule. Unfortunately, due to time pressure and deadlines, the code is often only a teensy bit better. Still, if you're swimming day after day in a foul-smelling swamp of legacy code, you need something to keep you going, to keep your head above water. Having the feeling every day that you've made the code better, rather than worse, does make it easier to cope.

This is a really hard problem and there are no silver bullets. And it is not just commercial time pressure and deadlines that leads to horrendous legacy code. After all, even Perl itself and the blessed PerlMonks code base have not been spared, as described at Nobody Expects the Agile Imposition (Part VI): Architecture.

[sundialsvc4]

(Cautiously sticking my head out a little bit [farther ...?] here), I actually don’t agree with that “rule.”   No, not at all.

I want to look at the revision logs in the version control system and see that every commit is clearly tagged to an open-and- approved-for-action ticket in the issue tracking system.   Then, I want to see that every revision corresponds only, and very exactly, with the specific issue that was described authorized in the approved ticket.   I never want to see a change being made that is not directly related to the ticket, no matter how badly someone felt that the “legacy” code smelled.

If you want to “clean up your campsite,” then ... open a ticket which describes exactly how you intend to do that and exactly what the business impact of the change will be.   If that change is approved, then you may proceed, as you would with any other software change and with an equal amount of probity.   Otherwise, and until then, the answer is “no.”   Even though you might be supremely confident that your “new and improved” code will be exactly equivalent to the code that it replaces, not to mention “–er,” you’re still making changes to source-code that is working now.   Even though you were not asked to do it, nor authorized to do it.   You’ve subjected the enterprise to the unplanned-for and unrecognized risk that you might screw-up, and you did it unannounced and on your own (non-)authority.   So what if you’re good; so what if the change is small.   That’s not the point.

“Change,” to software source-code, “is risky.”   There must be no exceptions to that rule.   Even if a carpenter thinks that a wall sux where it is, and would be so much –er if it had a nice window in it ... that does not authorize the carpenter to take it upon himself to install one.

Yeah, I know that this notion or this position won’t “sit well” with a lot of folks ... but I’ll stick to it, nonetheless.   This sort of discipline would be de rigueur in any other form of engineering undertaking, and I submit that Software Engineering should be no exception.   I didn’t start out with that point-of-view.   I came to it by decades of cleaning-up after the consequences of it not being done.

[marinersk]

Many businesses follow the process model.

Established businesses see the benefit regularly, but their margins are slimmer.

Few start-ups succeed with it.

I suspect the reason is because the start-up often is doing something new and exciting, attracts quality people who make a sufficient number of good decisions that the end result is passable, was built at low cost, and can reap the kinds of margin needed by investors.

I have now seen three companies attempt to migrate from the start-up mentality into the more mature process model; two are still flailing with it after years and years, and one is actually grinding through it with a fair bit of success.

I used to favor the open and artsy approach, but that was effective because most software developers were engineers, and evaluated the whole problem as best they could. With the passing of time, I see the software development environment has become less about engineering and more about having a job. The need for process has increased to compensate for the absence of engineering discipline in the marketplace.

I begrudgingly admit that for most businesses, you have it right. The fixed process, cumbersome though it be, allows risk-averse delivery. Software is so commonplace now, this is needed far more than I could have ever wanted to admit.

I believe there are places where trusting your developers to make the right choices, and artsy/freelance approaches like the Boy Scout Rule, have a benefit. But the number of places where such things work well for a business are shrinking rapidly. And it would not suprise me that you don't see it. On that, we are likely to simply disagree, and I'm okay with that.

Process is great until it gets in the way. Someone once shared their managerial philosophy: If you can't measure it, you can't manage it. Most process-oriented people see this as an absolute, but the reason is simple: A single failure is unacceptable in their world.

Without risk, profit margins are reduced. Do you go with safety, or margin?

I have come to the conclusion that the answer to this is not as cut and dried as most people with an opinion on the matter would have us believe. There is a time and a place for each. But where software development tends to take place in business these days, the vast majority, unfortunately, must favor safety.

And the sun still comes up tomorrow.