Joel Hainley : San Francisco Bay Area Software Consultant

One of the things that you notice if you are around development/engineering teams enough is that there is normally the existing solution, and the “next iteration”. Much has been written about the “second system” phenomenon and all of the pitfalls and failures that have resulted by second system thinking. Today I just want to talk about the importance of maintenance work to the growth of a developer towards understanding the hard problems within their chosen problem domain.

It seems like maintenance programming is, according to some developers, the lowest form of development on the planet. If you’ve ever been on a team in the role of maintenance programmer you have probably noticed that it’s not considered “sexy” by most of the team. Everyone is glad that you’re the designated maintenance programmer because that means that they AREN’T. Everyone wants to be working on the second system where “things are cleaner”, “we’re using better technology”, etc.

I’ve never agreed with this mentality, and here’s a dirty little secret, I LIKE maintenance work. There are few things as challenging as debugging a problem in a system you haven’t designed and fixing the problem in such a way that you leave the code better than it was when you got there. Here’s another amazing benefit of maintenance development, you learn the system and you learn how other people think and approach problems. In a similar way that Rorschach and Perceptive Aptitude Tests work, code is a projective tests for the thought processes of the developer who wrote the code. The other amazing benefit of supporting an existing application is that within a VERY SHORT amount of time supporting an existing application, a new developer is going to learn the system backwards and forwards. The developer will end up having a very deep understanding of the problems inherent in the existing design from a very realistic standpoint.

See new development is easy, you’re just trying to hit the 80% mark. If you’re in development you know what I’m referring to. “80% of the functionality is solved by 20% of the work.”. I’m willing to argue that the real work involved in a new application is done after the application is in production, that’s when you start to work on the last 20% of the application.

Maintenance work ( debugging production problems, adding new features, etc ) is when you start to solve the really hard problems that were not seen, or deferred, by the team creating the application. You often have to be creative in how you quantify the problems you are seeing, and you have to be a bit of an artist in terms of how best to quickly and easily ascertain what the hell is going on. The great part though is that you start to see how the choices made during the implementation of the system impact your ability to respond to certain things. This is the reason that I think solution architects should be in the trenches writing code with everyone else. They need to understand the results of their decisions at a very fundamental level, and the only way to do that is to keep their head in the game.

The other great thing about doing maintenance development is how easy it is to measure your contributions to the team. It normally goes like this, Tuesday morning the big client calls, he has found a bug that needs to be resolved by Friday or else they are going to have to leave the team. Tuesday, just before lunch, a meeting is called, and bad pizza is ordered. You are brought into the meeting and asked how in the world this can be fixed before Friday. If you just built the application but haven’t spent time doing maintenance since it’s release, you’re going to have to look into the application and reacquaint yourself with how it works, and see what new things have been added since you last saw the code. However, if you’ve been doing the maintenance work you can speak with authority right there in that meeting about what it is going to take to deal with that issue, and with any luck it’s already something that you have thought needed to be dealt with and have an idea about the best approach to take. So you grab two extra cokes and the last box of pizza and go back to your desk and solve the problem, test it, get it through qa and into production. A specific measurable result for your efforts, and something that others will remember.

Obviously I love to do maintenance work, I am VERY often called by clients to deal with legacy situations. I can’t count the number of times that I have had a client call up and tell me that the only person who knows anything about the application has left and “they have a huge bug and he’s trying to charge them $400 / hr to deal with it”, or they “have fired their consultant and are now left with a huge mess on their hands and could you help us”. I love this work, it’s real, it’s necessary and it’s often challenging and interesting. If you need maintenance work done feel free to contact me, I’m always looking for chances to sharpen my debugging, and code-reading skills.

Last time I talked about setting up logging for your Flex applications using the debug version of the flash player and configuring it to write to a text file. This is can be useful for debugging, but it’s not always the most efficient route for quickly getting to the bottom of a problem within Flex. Thankfully there are a few other useful tools that we can utilize to help us in our debugging. One of these tools is a project put out by Google called ReflexUtil.

For this article I’m gonna be using Adobe Flex Builder 2 to describe the process for  setting up ReflexUtil in your project. It should be relatively obvious how to add this to your project if you’re building everything using the flex sdk for development, if not let me know and I’ll post a note here about setting it up.

The process for setting this up is really well documented on the ReflexUtil website but if you haven’t used third party libraries in your Flex projects before you might spin your wheels for a few minutes. So here’s a step by step for getting things setup :

1. Download the appropriate version of ReflexUtil library from google code - there are versions for Flex 2 and Flex 3 so make sure you get the latest version for whichever version of Flex you are running .
2. Unzip the file and place it in your libraries folder - I have a master directory for all of my libraries, 3rd party and custom libraries, and I drop them into subfolders of this folder so that I have everything in one place.
3. Open up your project in Flex Builder and add the library to your project. If you’ve not done this before you just go to Project->Properties in Flex Builder then click on “Flex Build Path” on the left, once there you click on the Library Path tab on the right hand side. Then click “Add SWC” then browse to the location of the file for version I have installed in the project it is called ReflexUtil2.swc . Once you select the project a bunch of options will be availble for how to link the library to your project etc. You can get more details on things over at the Adobe documentation page that describes how to use SWC files in your Flex project
4. Now open up the application’s MXML file
5. Add <reflexutil:ReflexUtil /> tag within the application tags. ( in XML speak : make it a child node of the application element )
6. Add the ReflexUtil namespace to the application tag by adding the following : xmlns:reflexutil=”net.kandov.reflexutil.*”
7. When you run your application right click on a control and you will see some new options in the pop-up menu. Links to the ReflexUtil homepage, Open Reflex util and an option to inspect the control that has focus, and perhaps options to inspect a few more controls.
8. Click on one of the Inspect options. This will bring up a dialog bog that allows you to drill down through what could be thought of as the Flex DOM and actually modify things at runtime, layouts, values, etc. It’s pretty impressive.

That’s about it, there’s a lot of things you can probably think of that this might be useful for in your own projects. The ability to get in and muck with the UI in this way is really convenient, instead of constantly incrementing layout parameters, then recompiling, checking, then tweaking again. You can now  just pop up your ui and make adjustments until you have it the way you like, then just make a note of your settings.  It might be kinda useful to modify ReflexUtil to have the ability to write out all parameters to the debug file so that you wouldn’t have to write things down, perhaps the developers will do this.

The only other thing that really comes to mind at the moment is that you probably would want to remove ReflexUtil from your project when you put your Flex application into production. The ability of users to muck with things could be catastrophic