 |
|
 |
 |
|||
|
 
John Reynolds's Blog
«Austin (as in Texas) Java Users Group meeting |
Main
| Straining the bath water (in search of lost babies) »
Longing for an Integrated Maintenance EnvironmentPosted by johnreynolds on August 02, 2005 at 06:24 AM | Comments (7)
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. From my "dream" IME, I want to "attach" a debugger to a running application and "catch" all of the code that is executed when I exercise the user interface. For example, if I click on the "Submit" button of a web-based form, I want my debugger to show me all the code that is executed (client-side JavaScript, server-side Java, SQL and stored-procedures). I want metrics to guide me to the methods that consume the most clock cycles. I want to be able to view the source code, edit it if necessary, and redeploy the application without breaking a sweat. 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. With client-side technologies such as AJaX and Flash becoming more common, missing the client-side of the call graph is becoming a bigger liability. Mozilla has the Venkman JavaScript Debugger, but we need something that can be integrated into a comprehensive trace of activities across the client-server boundary. Imagine yourself maintaining an Ajaxian-JSF application that has subtle field validation problems... Is the problem in the client-side JavaScript, or is the problem in the server-side Java? A good tool could help you find out quickly. 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.
Bookmark blog post:  del.icio.us  Digg  DZone  Furl  Reddit
CommentsComments are listed in date ascending order (oldest first) | Post Comment
| |||
 java.net RSS Feeds
|
