Monday, January 21, 2008

Software Development in the Mines of Moria

The majority of the projects I've worked on during my nearly 25 year long career have a lot in common with the Mines of Moria. That is, they're vast edifices of architecture and detailed design; great effort, valor, and skill were expended to bring them into being; and much wealth was extracted during their lifetime of construction and operation.


Sometimes the projects are still active, with a small group of developers fixing bugs, improving performance, or adding new features. And sometimes they're pretty moribund, with me being the only active developer in the midst of a very large code base. I'm "cursed with competence" in this aspect, in that I've got a track record of being able to be dropped onto a project that needs something fixed or added, and learning enough of it quickly enough to make the needed changes or additions. (Now I've also handled some clean-sheet projects from the beginning, so that breadth of architectural and design experience has given me the experience I leverage when diving into another project's code base.)

The one characteristic all these "Moria" projects have in common is that at the time of their development, they were always developed using the 'hot technologies' of their day. And these go back awhile, so I dealt with a variety of technologies on these projects: Pascal, Ada, Windows NT, C++, Java, CORBA, UML 1.x, Coad/Yourdon, Rumbaugh's OMT, DEC Alphas, and others.

And while these were on the cutting edge back in their day, they're not now.

So it doesn't take a Gartner Group study to foresee that the projects being developed today with the latest and greatest technologies are also going to eventually turn into Moria projects, at least those that aren't discarded at some point. And be aware, something that's old, but still works and brings in revenue, is going to be kept around, no matter how crusty its implementation and how obsolete its technology.

This realization eventually leads one to becoming rather skeptical of whatever latest and greatest technology is being touted at any given time.You can understand why senior developers don't get excited over most new technologies, because time and time again whatever was hot and manages to achieve widespread success passes though the phases of becoming mainstream, then pervasive, then over-encumbered, disdained, and finally dismissed.

It's not necessarily a fear of change or the unknown, or a lessening ability to learn, that nudges software developers towards sticking with what they know as they get older, i.e. more experienced. Seeing one killer technology/language/methodology after another fall by the wayside of their career path, year after year, tends to encourage senior developers to stick with what they've seen to be proven approaches to successful software development.

It's certainly important to remain aware of the progress that is being made in the software development field, because genuine advancements in the practice do occur. In fact, those established, proven software technologies of the experienced developer were at one time themselves experimental, state of the art hot technologies.

Some developers do always want to be on the cutting edge of software technology, they find learning and experimenting and pushing the envelope interesting and challenging. And that's great, it's these developers that do the initial shakeout of the technologies, do the initial cut to identify the candidates for eventual mainstream use. Other developers like to wait for that shakeout to occur before buying in, they're the ones who are going to put in the big commitments to do the big projects, knowing full well that new programming languages, methodologies, and tools are going to eventually supersede what they've done and how they did it. Doing something big, and doing it well, is what they're looking to accomplish, and that requires relying on proven tools and techniques that can handle the load.

In time of course the big project is done, deployed, maintained, and sometimes gradually, sometimes precipitously, evolves into a Moria project. The budget is reduced, the releases become fewer and more infrequent, and the magnitude of new functionality in each new release declines. The project still has value to its users and customers, and so keeping some lights on in the Mines is justified. And for those of us who find "software spelunking" and "software archeology" interesting, and have the experience with these technologies that used to be famous, it's not a bad way to make a living.

3 comments:

Chris Austin-Lane said...

Now that's a job title I could relish: software archeologist. As someone whose favorite languages are C and lisp, but who's been using python when something had to get done quickly for a number of years now, I've lost whatever purity I once aspired to.

On the other hand, some mines are not only dark they are inhabited by Balrogs. I've turned down a project or two to fix memory leaks in giant old messes. If after a few days I can't even be sure how many memory management layers the C++ app (with all of its dynamic loading of rigid product-specific modules) has, I don't care to venture in.

--Chris

Nancy said...

Hi,

Excellent article - I really appreciate your knowledge about software development in Mines of Moria and I have bookmarked it for later viewing and forwarded it on.

Cheers.

Kent Colvell said...
This comment has been removed by a blog administrator.