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.

"Good Enough" Might Actually Mean "Good Enough"

Ryan Tomayko claims that IBM Poopheads saying that LAMP Users Need to "grow up" are trying to foist an over-complexified approach onto database-oriented applications.

After wasting years of our lives trying to implement physical three tier architectures that "scale" and failing miserably time after time, we're going with something that actually works.

His general point is that complex architectures designed from Day One for a "million users and requir[ing] five 9's from the first day of development" "sacrificed simplicity and the ability to scale low".

This principle of simplicity has been gaining significant traction with me over the last several years. I've been a software architect and gone the whole UML/Rational route. But then I've seen so much crud getting accreted onto it that my level of skepticism regarding that technological approach continues to rise. The more I see of it, the more I see of architecture being handed down "from above", the less effective and responsive (i.e., agile) I'm finding the resulting system or application to be.

Beyond NASA, Beyond Mars

I have barely posted to this blog started by my dear friend Marc. I seek to turn that around in the coming days. However, I'd like to propose a few topics to cross-pollinate. I am an enterprise architect, a systems engineer, a systems architect, and a software engineer. I am interested in the far reaching elements of design and pushing state-of-the-art in many disciplines simultaneously. As such, I'd like to propose for starters what might be perceived as a vast array of disparate topics to discuss and then start blending them together.

My career has taken me from EPA superfund projects, to Trident nuclear submarine software, to engineering the math model compiler for the B2 Stealth Bomber air crew training device, to designing the vision for smart weapons that can see and autonomously shoot tanks, to developing field artillery tactical data systems, to developing military intelligence workstations, to developing international communications satellite ground stations, to becoming the U.S. Bureau of Land Management's national technology architect, to developing visions for 2020 intelligence community service oriented architectures, to my current role as a systems engineer working for NASA's IV&V facility in Fairmont, West Virginia. This has been a wonderful and beautiful ride from one ground breaking project to another. As such, I have seen and done much in my 25+ year career, but my dear friends this is just the beginning as something wonderful is about to happen.

Here are some of the topics I will be touching on in the coming weeks: architecture, design, systems engineer, software design, software development, NASA space craft, UML, SysML, building architecture, automotive design, UFO's, UFO footage, human culture, alien cultures, human exploration of space, God Almighty and his only begotten son Jesus, and many other topics. This might seem like the ravings of a madman, but in truth, they are the explorations of a humble man who has seen much, done much, and seeks even more adventure.

So, there is my introductory statement. I look forward to our on-going discourse and discussion.