Treat Development as Maintenance
Published on AgileConnection (https://www.agileconnection.com)

[article]
Lifecycle Best Practices

Treat Development as Maintenance

Summary:

Development is treated as being different from maintenance, somehow more special and elite. Maintenance programmers, however, have solved problems that developers tend to keep reinventing.

If your team uses modern development processes, consider that each module gets created only once, but will be reviewed, and then maintained until its development release. If your team uses XP or a spiral lifecycle method, this is even more evident: you keep maintaining and promoting modules continuously. Unless you are a miraculous coder, I think you'll edit each module after its initial creation. I usually like to< em> create my modules incrementally with stubbed-out member functions and later fill-in the blanks.

Once you accept that development is maintenance, its easier to justify the team working within a source control manager [SCM] from the start. You use SCM to safeguard your checkpoints as you go to minimize the risk of loss or regression.

Computers do routine work accurately, repeatably and quickly.
Humans do creative, judgmental work slowly but well.

Use computers where possible to avoid repetitive, error-prone tasks in humans.
Use humans to create and to judge reasonability and clarity.
Use the compiler to weed-out misspelled names, mismatched braces, omitted header files etc.
This supports incremental unit testing to build incremental confidence.

Prefer prevention to debugging.

Code reviews should answer:
"Did I solve the problem? The right problem? Is it clear?",

 Code reviews should not spend resources answering:
"Will that compile?"

 The situation today is much better than it was in the 1980's.

We mainframers lacked automatic SCM versioning. Does anyone remember Panvalet™?

It remembered changes one version deep. We lacked a good file difference utility.

IEBCOMPR would tell you "not equal" and display the remainder of the files.

Lacking incremental SCM, all we could manage was promotion from development to quality-assurance to production by copy procedures. We automated as much of the promotion process as we could, but it was always a variable script to manage.

I was a mainframer doing Database Administration maintenance for multiple project teams spanning both development and maintenance. Until we tumbled onto the Development Is Maintenance idea, we tried to defer establishing a system's the life cycle tooling until its first production release.

We mainframers then had a big envy for the proverbial "two guys in a garage" that didn't need lifecycle processes.

If your team use the daily build and smoke-test, you notice the pattern of maintenance. In this pattern, a developer acquires a [somewhat] stable version of some code products from the shared repository, destabilizes them to make a change, restabilizes them and delivers them back into the shared repository. Any change has to break correctness until it is completed or is backed-out.

A classic problem for a team of developers is that one person needs to change the modules that another person needs stable. Even worse: the second person may also want to change some of the same modules. [Have you ever tried to share the Resource files for a single VC++ executable? or the base class object of a polymorphic set of classes?] A decent SCM should make visible "that's checked-out to Fred", so dynamic work balancing can be done by members of the team without begging the team lead to intervene. This is the price we pay be able to divide the work between the multiple developers working concurrently. Without this parallelism, large projects would be impossible.

A second problem appears in maintenance whenever the initial release has been promoted: what components in the messy test environment need to be promoted with the next release? This gets even chancier if there is ongoing work in the development stage that is not intended for promotion until the next release cycle. It's all too easy to lose and revert a change to a supporting source module, especially if you weren't sure it changed. Your refactoring may change the directory locations of files in the build so now the project .MAK has changed since last release and thus needs to be promoted. What if a trial refactoring that didn't work out? Your team deserves all the change bookkeeping assistance that your SCM tools can give you.

My experience is that the current tools and integrated development environments do support these situations pretty well, but only if you take the time to configure them for these maintenance cycle processes before you start cutting code. Retrofitting SCM and compiler options across all the teams' PCs is not fun, and is just plain disruptive.

About the author