The things you learn…the hard way

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.

How I challenge problems or troubleshoot challenges…

Some History

As a kid, I love to take things apart to see how they worked.  Ok, so this is a radio, you open it up and see things you can adjust.  What happens when…  Ok, maybe I’m not so far from that kid.  I still open things up and make changes just to see the result.  That’s how I learn…  Now, this short blog is about my approach to problem solving.  I’m sure there are others who have written similar articles on similar methods.

yup, I used a Swiss Army knife too!

Not my concern.

This is my approach and if it bears any resemblance to anyone living or past…  Well there is one who has past on that served as the nucleus to my process.  That one is JRR Tolkien’s own Bilbo Baggins.

What have I got in my pockets?

When you approach a problem, how do go about it?  Do you look at the challenge and immediately see that you have nothing on had that can address the issue?  If that’s the case, then really there are three paths to choose from:

Ok, says you, what happened to the fourth option of “just buy new”?  If you just buy new, there’s no more problem to solve.  That’s always the golden option with it’s own set of issues.  So really the above becomes:

What’s interesting is that the amount of effort to “Do the minimum” and to come up with a solution is about the same.  Many times, coming up with a solution results in many side benefits.  My thoughts on the matter are:

Coming up with the Solution is FUN

Doing the Minimum is Depressing

Speaking of Fun, are Visio diagrams fun?  I digress…

OK, now it’s on to “What have I got in my pockets?”

That phrase was muttered by Bilbo Baggins in the Hobbit when confronted by Gollum in the riddle game.  Bilbo was simply thinking aloud, trying to come up with an appropriate question for the game so Gollum would lead him out.  Gollum jumped to the conclusion that what Bilbo said aloud was the actual question…and the story continued on.  If you want to know what happened, read The Hobbit by JRR Tolkien.

What Have I Got In My Pockets

You have a problem/challenge and you need to find a solution.  The easiest path would be to just buy new but… there’s no budget.  The “do nothing” path isn’t a solution either because what you need to resolve is either failing or has a specific termination date (don’t worry, there are times you can “do nothing”).

Look around – Solution not the problem – Take Stock

A lot of folks try to solve the problem immediately without stepping back to take stock of their situation.  The key is to ask “What do you really need solved?” 

You need a widget to do something.  You are surrounded by tools that can provide you a widget like substance but they all require some resource.  The quick folks (sometimes this is the only choice you really have) use a widget like substance that only takes care of 10-20% of the problem.

10-20%

So you got a 10-20% solution in place and that will tide you over until the next iteration. 

You got past the crisis and it was all good right? 

Just like ol’ Bilbo and the Ring of Power.  He turned invisible, escaped Gollum and had a nifty new invisibility ring.  Neat right? 

Like any quick solution, if the long term results aren’t looked at and the wizard of knowledge not consulted, the solution could turn into disaster. 

This is not to say that quick solutions don’t have a place, they do but unless you are at the 80% mark, there’s still a lot of work to do.

Getting Past 20

Now the diagram looks like:

But that’s not quite it either.  It really should look like:

But wait, there is no end!  Even if you do nothing, the odds are pretty high that if the issue came up once, it will show up again.  So, in my problem solving model, the problems never go away… bummer!

The Stage is set

Up to this point, I really haven’t talked too much about how the problem is solved. I’ve addressed identifying the issue and the possible paths to the solution.  Congrats!  Step one is done.  The whole effort up to this point is to gather information on what the problem is, what is the needed result (immediate and long term) and what can be done now to get the process moving.

When doing nothing is the right answer

I love it when folks get so wrapped up in the idea that there is a “problem” and no one stops to look around and see if it is just groupthink.  In this situation, the solution may be to do nothing because that is the right move.  Sure, that the issue came up may lead to some interesting facts about the whole process and MAY identify a different challenge that needs addressing but doing nothing about the “BIG ISSUE” is ok.

Why is only doing 10-20% ok?

Often, challenges are really composed of many different pieces and are lumped together into a challenge forest.  Maybe all you need is a path through the forest and the rest of the trees can be taken out late when more room is needed.  The key is to make sure that the initial items addressed are the immediate blockers.   Using the forest analogy, just taking out some random trees does very little if the goal is to make it to the other side.

But I don’t have a chainsaw!

You may not have the tools to quickly cut down the trees right in front of you.  But maybe, that’s the wrong action anyway.  If you don’t have the perceived right tool, look and see what tools you do have and how they can be applied to the landscape.  In front of you, you see trees but if you look to the side, you see a river flowing through the forest.  Perhaps instead of an axe or a chainsaw, all you need is a boat and you have a lot of boats sitting around.  The river may not be navigable all the way to the final destination but creating a portage around some falls is a lot less effort that plowing through the forest.  Less destructive too.

Wrapping it up – What have I got in my pockets

Gather

Don’t assume there’s a problem.  Take a breath or ten and clearly define what the challenge is and what roadblocks are in the way.

Choose immediate actions to take

Can you take the pressure off?  The dam is filling with water too quickly, letting out some water now will keep it from overflowing allow time to build a new dam upstream.

Make sure the goal is the right goal

Remember the forest?  Just because a challenge is stated doesn’t mean that the problem to solve is right in front of you.  It may be off to the side from a different  perspective.

Revisit and revisit and revisit

You’re never done.  Job security?  Maybe but if you are always tuning a process to make it better, it certainly helps keeping you around.

Must…Write…Blog…

Upcoming

Just a quick inset to let folks know (there’s at least one that I know of) who follow my rambles that, yes, there’s more to come.  I’ll get back to SharePoint – “Creating The Lab” series soon.  I want to walk through the PowerShell aspect of it all. 

There’s more for SSIS and Visual LightSwitch as well.  T

On LightSwitch

The LightSwitch team has really done a great job pushing out good material on how to use their tool.

See: LightSwitch Developer Center

When I first tried to use it, I took one look, saw that for Simple apps it was a reasonable tool and never looked beyond.  Take the time to go through the examples, build the Vision Clinic app.  Once I did that, I saw much more of the potential for LightSwitch.

On Microsoft Virtual Academy

As time allows, I continue to plug through www.MicrosoftVirtualAcademy.com.  Take a look, try out some of the sections.  Not all apply but many do.  LightSwitch is also featured there. 

More Soon…