New Code, New Job or New Opportunity…
Over my career, I have had to adapt to and adopt new technologies and technologies, while I was conversant in them, were deployed in very unique ways. Technological change is inevitable and if you want to remain viable, you have to roll with the punches. Time can morph the FINEST architected system to the point of instability. These are my thoughts on spinning up at a new opportunity or being presented with a new system and reaching a knowledgeable state within 90 days (120 if there are outstanding “other” tasks to be done).
Reverse engineering a system can take one of two paths depending on the availability of information.
Why start right off with reverse engineering? Few of us have the opportunity to work in a Greenfield environment.
You can go down the path that the documentation is “golden” and the foundation is sound and focus all your energy on the methods, properties and attributes of all the classes. I know this sounds like OOP but a sound understanding of objects and the states they occupy is critical. The second way is to talk to stake holders, use the application and get to know the operational intent of the application. With that approach, the documentation becomes a reference but not a guide.
Note, not all "documentation" has an informational value.
If you have access to the code, that enhances the power of the "documentation".
So, the first set of skills needed is to be able to develop a plan to reverse engineer the code. How does one come on board and "spin up" to be a master? This is a second set of skills and helps to master the code base. This being said, the last skillset needed is a "QA" mindset.
Code to test, test to code. According to Yoda:”Write Code? Test, you will…”
Reverse engineering code:
Access to the source code! More than once, I’ve gone into a project and have access to the source code and think I have it made. Ten minutes later I’m looking for the bus that just hit me. Why? Having access to the source code is great but that doesn’t necessarily mean you’ll understand the code in any time in the near future (six mos.) but it is useful. Beyond the obvious (this is the code you have to maintain) it gives insight to the hands that have touched the code. While in this process, it’s also a good time to think about refactoring. Windows of opportunity are quickly closed by the pressing needs of business. While that window will open up again and again, it is open widest at the start. For example, the code is well structured and for the most part, maintainable. You run across a section that is hanging off another module. At first, it looks like a valid piece of code reuse but after delving in a bit more, you find that it’s not related to its location. You may learn that it was put there because that’s where the “screen” appears in the application. Now the code is being maintained in two places. Complexity has crept in along with an increase in the potential for breakage.
In addition to the source, hopefully the code was documented in-line while being developed. Now tools can help. They still can even if the code is not internally documented. Grab a documentor that can parse through the source code (like the .Net documentor on CodePlex or Resharper). Hers a pretty good list of available documentation tools. Depending on the previous developer, you can inspect the compiled code to see what methods, properties and attributes are exposed by the classes. From there, it’s time to move on to the next step and become a master.
Mastering the code base:
This is where the diplomat comes in and works with the stakeholders to determine two areas. First, what works well and does not need enhancement. The second is everything else. What? Just two? Really, there can be only one. Once a line or two is written, all bets are off and modifications will follow. That’s a good thing right? What does diplomacy have to do with this? I’m SUPER DEV/DATA GUY/ETC. <<announcer voice>> and nothings stands in my way <<queue reverb, a little echo and fade off>> Wicked skills right? Guess what, you were hired for those so you don’t need to go down that road. What you have to do is…
listen.
I know this architect who really has a handle on code. Granted, maintainability lacked because the code was complex but over all it was a complete application.
The problem:
The stakeholders never were consulted and the solution eventually died on the vine.
In another situation, I wrote an application for a set of users. It was simple and straight forward from the use point. Almost an “easy button”. I spent a lot of time on the data parsing dll. The applications sole purpose was to read a text file, allow the user to “map” the data to field designations and then generate a load file.
The problem:
After I left the company, a decision was made to “upgrade” the vb 6 application to .Net. What should have been an easy refactor was complicated by the decisions to completely re-engineer the tool and give it a whole bunch of new features. Well, the application was built and the team asked to use it. Herein lies the problem. The new application did do what the original one did and it did a whole bunch of other things. However, nobody talked to the stakeholders and while it was installed on their systems, they never used it. A few years later, I was talking with a friend who still works there and my old VB6 application is back doing it’s job. I’m sure it’s retired by now.
The moral here:
Just because you can add a whole lot more, doesn’t mean you should. If you do, make sure the stakeholders are on board.
Back to spinning up. Now armed with documentation from talking to the stakeholders and working through the application it’s to get a handle on the current state. Determine the backlog of fixes, enhancements and new features. Once you’ve got your initial list, it’s time to go back to the stakeholders and get a clear understanding of priorities. You go into this knowing full well that there will be conflicting priorities and this is where being a diplomat plays a critical role. How does this enable you to become a master of the environment and code base? This gives you a blueprint to follow to start building/getting knowledge of the resources required and the burn rate needed to clear the backlog. This all plays into the next and last part of the initial push to get on board and get up to speed.
QA the product and code:
You have to run through the application to build test cases and determine expected results. Applications exist in their own space. What may have seemed logical to one makes no sense to another. So, how do you get a handle on the code? Work with the backlog. Simple yes? You just put on your agile hat and go for it.
Well, if you can do that, my hats off to you. Me, I have to take a much more gradual approach. I could call the approach I take the “Onion” but at times, it feels more like a great Red Wood
Getting a handle on how the code actually works versus how you expect it to work is critical. This also starts to build your library of test cases you will need to make changes. Without know how a piece of code runs, you will not know if your change has had unintended consequences.
Summary:
While there are details and additional steps to take, this is the viewpoint from 60,000 feet. This process gets constantly refined depending on the need at the time and how much critical focus is needed.
.
Technical Musings, Opinions and Articles 