Longing for an Integrated Maintenance Environment
|alt="John Reynolds' wrench">||We are blessed with many great IDE choices for developing our code... and now we're beginning to see glimpses environments that will help us maintain deployed applications|
When the dot.com boom went bust, I was fortunate enough to land a job as an enterprise architect in the development and production support group of a mid-sized corporation. After a career in R&D, I found myself in a more typical IT environment where keeping things running was way more important than implementing new features.
This change in perspective from R&D to IT was a very good thing for me. After years of delivering solutions to customers and moving on to the next challenge, I was now the producer, consumer and supporter of my own team's creations. I now had to "eat my own dog food" in a production environment (24x7x365).
When you really have to live with (and support) your own products, your perspective on what is important changes.
For the most part, business applications are conceptually simple. You present a form to a user, validate the responses, and process the request. It's hard to conceive what could go wrong after deploying such Simple Business ApplicationsTM, but inevitably Murphy's Law kicks in at 2 a.m. during peak processing season.
Another common factor of Simple Business ApplicationsTM is perpetual change. SBA's are living and breathing entities that evolve over time: Fields get added, fields get deleted, validation rules change. Edicts from governing agencies impose new constraints. Changing business partnerships impact workflow. Nothing is truly static.
Add to the nature of SBA's the inevitability of staff rollover (developer's tend to change jobs frequently), and you start to place a premium on code that is robust, easy to fix and easy to learn.
The biggest difference between developing applications and maintaining applications is your own memory.
When you are developing an application, all the myriad details are fresh in your mind. If a bug crops up, your intimacy with the code will quickly lead you to the cause (folks may think this is intuition, but it's really not).
When you are maintaining an application, it's pretty much like inheriting code from someone else. Eitan Suez once blogged that code rots if you don't visit it frequently... I fear that it's our memories that have expiration dates. Go back and read any snippet of code that you wrote two years ago and you'll probably understand what I am getting at.
An IME (Integrated Maintenance Environment) must help you remember the code (or learn it in the first place).
My preference would be for an environment that lets me run the application, and navigate from the running application to the underlying code.
My "dream environment" isn't all that far fetched.
Tools that provide detailed run-time-call-graphs are available today (like Quest Software's Performasure and NetBean's Profiler). These tools cover the server-side of the call stack, but I have yet to see anything comparable for tracing the client-side code.
Maintenance tools are definitely getting better, and open source is making them much more widely available, but no matter how good the tools get, code still has to be written with maintenance in mind to be truly maintainable.
Maintainability may force you to follow rigid coding conventions. It may limit your choice of frameworks and libraries. You might have to settle for the status quo instead of experimenting with the bleeding edge. But in the real world maintainable code is better code. Losing your coding freedom hurts, but sometimes you just do what you gotta do to keep things running smoothly.