Consulting Chronicles #2: Fixing a Pile of Rubbish – Part 1

Consulting Chronicles #2: Fixing a Pile of Rubbish – Part 1


A lot of consulting revolves around fixing other peoples code. Sometimes this is pretty straightforward. Sometimes you perceive it as an unfixable disaster. Other times, not only is it a disaster, but you could be put into a situation where you are perceived as taking advantage of the situation when in fact you’re attempting to fix it.

Disaster recovery in consulting is solved by using the 5 P’s: Programming, Prowess, Politics, Positivity, and Patience.

Even if you aren’t a consultant, the tactics below should help you fix the un-fixable.


Let’s give some context.  There are many situations in which you’ll encounter a code base you’ll quickly start to loathe.

The first is staff augmentation.  You’re brought in as additional code muscle; whether you’re actually needed, or just there to ensure “everything goes smoothly all things considered”.  The project has already started, there is probably already a team lead, so you’re architecture input is limited in what you can actually accomplish given the current situation.  You, and the team you are working with, are forced to eat someone else’s architecture decisions, with limited ability to influence those directions because you aren’t officially in charge.  This article assumes a lot of those decisions are bad… or you wouldn’t be there in the first place.  You walk a fine line here between helpful team member, and someone asserting alpha-dominance over the team.

The second is a vendor change.  For whatever reason, you and/or your firm is now responsible for an existing code base.  A lot of times, this existing project hasn’t officially launched, even if it’s “done” after 8 months or more development.  The client may tell you it’s launched, but if you dig, you’ll find no one of consequence uses it.  These are often the most dangerous projects to be on. The expectations are high, massive amounts of the client’s money has already been spent, and most horrible of all, perceptions of the current project & code base could be totally wrong.  A lot of times the horrible reality of the situation hasn’t been realized by the stakeholders, and when it does, the original vendor isn’t there to suffer the wrath; you are.

The third, and most common is disaster recovery.  This could be as benign as “we’re having a memory leak we can’t track down”, to “we have a product demo in 3 weeks and our app doesn’t run”, to “nothing works, it’s been 4 months, zomg help us!”.  The “nothing works, save our project” is often benign sounding over email/phone conversations.  Then you get there, and start to realize full extent of the situation; everyone, including you once you’ve commited, is screwed.

You’ll notice all 3 situations sound dire.  Now watch what happens when you add some positivity.  In the first you become an MVP.  The second and third, you become a benevolent savior.  That’s just 1 of the 5 P’s; Positivity.

Below, I’ll touch on the first part of Programming, since using your skill-set as your main weapon is the most straightforward, and the most extensive to talk about.

Programming: Code Your Way Out of the Situation

In the most dire circumstances, there is only 1 thing you can continually depend on: Yourself.  Using your skills at programming, you can battle back any obstacle thrown at you.  If you’re stuck with a mediocre team, or even one that works against you, your abilities can more than compensate.  Your main weapons in your arsenal are your mouse, keyboard, and your programming ability.  Use them.

When confronted with a monolithic mess that doesn’t compile, doesn’t run correctly, for a product idea you think is pointless, it can be extremely challenging to find out how to fix it, let alone the motivation.  In programming, there are countless things that can set up a developer to fail, hence the high failure rate in software projects.  For the programming section, I’ll focus on those development things you can do.

Programming Tip #1: Ensure You Can Code in a Simple Way

Your first order of business when dealing with the code base is getting it to compile and run on your system.  The #1 thing I’ve seen that has inadvertently made sure most projects slow to a halt, and ensure any new developers take days or weeks to actually contribute anything is complicated build processes. I’m not just talking about verbose & badly written Maven/ANT scripts; I’m talking about requiring a local HTTP Proxy, a modified host file, a local web server, pre-compiled modules, the build itself must be run in a specific order, the project needs to be hosted in a specific file path, requires a custom build of Eclipse, and requires a specific OS.

Yes, I’ve seen projects that require all that.  Simply importing the project itself from SVN into Flex Builder won’t work.

I’ve seen some amazing things done with build systems that are setup specifically to further the goal of good Continuous Integration practices.  Being a consultant, I see them cause more harm then good to developer productivity.

When thrust into a wild programming situation, you need to reduce the complexity as much as you can to ensure success.  Success is very important when starting a project because it builds trust.  You need to earn the trust of your client since you’ll potentially be in some very trying times together, and for larger re-factoring efforts, asking for a lot of blind faith in you.  Giving them confidence you can get things done and working in bad situations goes a long way to earning that trust.  When it takes you 1 week to commit something positive to SVN… that’s totally fine for the first week, but not 4 weeks into the project.

In order to earn the trust of your client, you need to ensure you can actually succeed.  To ensure you can succeed, you need to ensure you can compile & run the code base.  Before you fix any Service layer, GUI, or performance issues, your first order of business should be getting the build process under control.  Success is when it’s easy for you, and others, to compile and run the project.  This includes getting new team members up to speed in 2 to 4 hours or less, not 3 days.

If a build requires a specific version of Eclipse, fix it.  Make it so anyone can use a standard version or even Flex Builder.  If it requires Maven, get Maven running on your machine in a clean environment, and slowly bring in the code base to ensure you’re not only compiling correctly, but you understand the how/why of the setup.  If you can compile the app, but it doesn’t run because of security errors or missing servers, fix 1 service at a time.  If the whole application won’t run without an existing session, make it as easy as possible for you and others to get this session, even if it means using separate Firefox/Safari/IE tabs.

One thing at a time.  Fix it, and fix it right.  If you can’t fix it right, fix it so it’s easier for you to fix other things.  Don’t add complexity, remove it.

Programming Tip #2: Give Yourself a Timetable, Keep Your Client Abreast of the Situation

Whatever you decide to do first to ensure the build process is as easy as possible, you need to do 2 very important things.  First, set a timetable with a Plan B and C.  Second, inform your client.

You need to treat handling of disaster code bases as emergency surgery.  In such a situation, the surgeon may not immediately know the extent of the damage to the patient, and needs to operate quickly.  To make matters more complicated, the patients family is freaking out in the waiting room, so the surgeon has to find appropriate times when she can take a break, and make an informed update to keep the family in the loop; what the status is, and what the plan is with a perceived outcome.  This isn’t just for good bedside manner; it’s for legal reasons as well.

Programming is more complicated.  By informing your client, a lot of things can arise, both good and bad, from this communication.  Make no mistake; more communication is better than less.

First thing that will occur is the client will be put at ease that you have a plan. Things are eff’d, yet you are confidently moving forward.

Second, the client may offer insight.  This could be in the form of explaining how something came to be, helping you understand the why.

Third, the client’s boss may prefer you immediately spend your time on something else they perceive as important.  While you in your gut know the most important thing you can do is to ensure you and your team can actually get work done, you still need to respect your client’s whims somewhat.  The longer term goal of earning trust starts obeying orders, and helping them get insight into the problems of the project.

Fourth, you keep your boss in the loop.  As you either make progress, or hit walls, they’ll have a clear picture of what is going on; also known as “transparency on the project”.  The timetable is key here.  “If I can’t get Maven working by this evening and compiling the project, I’m waxing it for the time being, and just trying to get the code to compile in a simple Flex Builder project.  Even if it doesn’t run, it’ll be a milestone that we can actually start contributing code and validating that code did or did not work.”

Without a time table, you create a couple bad precedents.  First, you give the client insecurity in knowing “when” things will be fixed.  Without a confident time table from you with a clear plan of attack, you’re asking them for a lot of upfront trust you may not have earned yet.  Second, you give the potential for you to have a lack of progress.  You and I both know spending 2 weeks getting a build system under control is totally reasonable.  The problem is, when the client asks, “What have you done this week?”, you’ll only be able to respond, “I’m still working on it.”  That’s pathetic, and sets a bad precedent.  Trust me, even if they smile and trust you when you have nothing to show for your work in 3 months, people higher than them will eventually start asking questions, and there will be hell to pay.  (…unless you have large financial clients… they don’t really care).  10 little wins are better than your 1 large perceived one.  Also, it helps ensure you don’t go down a black hole of fixing, and keeps you on track overall.

Finally, the Plan B and C’s are huge.  They imply that you “know” how to fix it, but are at least giving the original programmer/vendor the benefit of the doubt.  You aren’t going in there saying, “the former creator is a moron, and I’m doing it my way”.  Yes, you can say that in 6 months if you have the gall (probably shouldn’t, it’s unprofessional, but we all get frustrated), but if you haven’t yet earned trust, you’ll come off as arrogant, and possibly opportunistic; i.e. be perceived as taking advantage of the situation.

They also give the client options.  While you may in your head perceive B as the true goal, and C is something you loathe, but at least you can work with them… your client may offer their own option you hadn’t considered, greatly simplifying your job.  You don’t like ANT, they don’t like ANT, problem solved; good thing you didn’t spend a day fixing something you hate.  That, or they may change the priority order of your plan of attack.  It’s their project, it’s their right.  By giving the options, and empowering them, you’ve done a great thing.  If they choose poorly, obviously you can attempt to steer them in the right direction, but at least the blood is on their hands; just make sure your document that decision.

Create options, put a drop dead date on them, and let your client know.

Programming Tip #3: Low Hanging Fruit

When you get your build under control, and start digging into the code to learn what else is wrong with the code base that you & your client might not know about, you may start to find really bad things.  Your gut reaction will probably to start listing those things to a “to fix” list.  Some large things include not using a scaleable framework on a large code base, no way to debug, or badly re-inventing the wheel when there are plenty of existing, proven code libraries.

Before you start implementing your framework du jour under the pretense of making the application more equipped for the future, you shouldn’t.  First off, you have no guarantee the app HAS a future.  Second, you’re assuming you’ll be on the project much longer to help see it through.  Third, the app clearly doesn’t work, hence you being hired to fix it.  Again, I agree a firm code foundation ensures you can build atop it with confidence, allows your team to forge ahead independently, and thus giving an existing code base one with none to begin with is a great first step.  Yet, it isn’t, and not just for the aforementioned 3 issues.  The two bigger items in play are client trust, and code trust.

While you may not have earned much trust from your client modifying the application to so you can actually compile, your client will have at least probably picked up on your increased confidence now that you can build it confidently.  If you can’t even reach this point, you won’t be able to even fix low hanging fruit problems.  If a client won’t let you succeed, and you’ve done your best to articulate what you need to succeed, you best end the relationship there.  Having a client dictate to you, the expert, on how to do your job is not how you win.  Some clients will do everything they can to sabotage themselves.  Save yourself the hurt, and the tarnished reputation, and abort early.  Trust me on this, even if it costs you your contract with the consulting firm you are with.  It’s about cutting your losses.  I didn’t cut my losses, and I lost tens of thousands of dollars on one deal, and double that on another years later.  Trust your instincts, listen to them, and act on them.

If you have made it this far, this is your first chance to score your first win with the client.  Making the app compile with a fresh build of Mate might make you feel better, but it has very little visible results… unless the client is impressed by this (which isn’t often the case).  Unlike designers, we developers have to do a lot of work to do a visible change.  Thus, finding low hanging fruit; something that’s a quick and easy win, ensures a first victory.  You only get one chance to make a first impression, and if your first impression is a quick and easy win on the code base, especially something that’s irked the client for months, that’s a damn good way to start off.

It’s also important that this quick & easy fix has low risk.  This is the 2nd point, code trust; specifically, how much trust the code base has earned with you.  Remember, when dealing with spaghetti code, you have no idea how changing one thing in one area will negatively affect something else.  You need to lower your expectations till you have a better lay of the land.  Even changing 1 line of code to fix a bug could cause 3 other things to break.  If it takes you 1 day to make the login screen look better, the client will be really impressed when it takes you half a day to stop the application from crashing.

One thing to keep in mind is that a project could of been in sleep mode until you/your firm arrived on the project.  Suddenly, as you are working, “new bugs” will be found.  If you’ve been furiously checking into SVN, and deploying new builds, you run the risk of becoming the cause.  By only fixing 1, small thing, you can say, “Amidst the chaos, I fixed this one thing”.  You can then repeat this over the course if your second week, and suddenly have a great track record in only 2 to 3 weeks on the project.  It’s easier to defend yourself against, “The login suddenly not working” when all you did was make it blue.  In negative situations, clients CAN and WILL make that illogical jump; “You were in the code, and it worked before you were in there, thus… you broke it by changing it to the correct color blue.”  That’s easy to defend and explain away.  Gutting the app, shoving PureMVC in there, and things starting to suddenly break isn’t so easy to defend.

Pick something easy, fix it, show it, and repeat a few times.  Once you’ve earned trust, you can start tackling larger problems.  While you may have a list that’s prioritized based on your perceived architecture issues, simply reversing it, or sorting by “easiest to fix” is the best plan of action in the beginning.  It’s also a low risk way to learn an already fragile code base in a tenuous political situation.

Programming Tip #4: Document Your Changes

You need to document what you changed.  Having a clear “paper trail” of what you’ve modified ensures you’ve covered your ass; aka CYA.  It also makes you more secure.  When someone body checks you on the application no longer being able to talk to the back-end, you can state with confidence that you’ve not touched 1 line of back-end code.  Doing a quick search/grep of the code base for “[jwarden", in this case "[first initial, last name date] what you changed”, you can get an entire document of everything you changed quickly to prove the client what you did and haven’t done.  This is a ton better than SVN logs because it’s clear, permanent, and IN the code itself.  Remember, sometimes it wasn’t just the previous/existing client side vendor/developers that screwed up the project; sometimes the problems lie not just on the front end, but the back-end.  When they suck, they love to blame the front end gals and guys for their incompetence.  All you have to do is slip up once, and they have you.  Don’t make it easy for them.  Most of what we build runs on their infrastructure; the truth will come out in time; just survive till then.

This is war.  You’ll get your chance to create a defensible position, and eventually go on the offensive, but first, you need to establish a beach head.  Having a clear record of what you’ve done, even on the first day, ensures no one can paint you in a negative light.  Imagine if you came in the first day, and broke the app… you can see how that would cause a horrible first impression (Yes, you and I know it’s already “broken” but remember, previous expectations of the app may not perceive it as such).  As a consultant, you need to assume people hate you, want (and may even try to ensure) you to screw up, and even something as simple as documenting what you change in 1 line will help keep you safe.

The second type of documentation is a document covering the broader architectural changes.  As you start making things fundamentally better, it’s sometimes hard to justify those things in 1 sentence.  Writing a 4 page document is usually enough to make people trust you, even if the document is bs.  If the client has an existing place they put documentation, such as a project wiki or a special place in their source control, you should use this.  It shows the client you respect their process, and want to work with them.  Granted, you shouldn’t write a document full of bs.  If it is bs, you should at least believe it.  Remember, if yet another consultant is brought on board to body check YOU or your firm, you better hope what you wrote the rest of the industry agree’s with.  Citations help here, as do other debate techniques.  “You’re attempting to argue with the collective knowledge of the Flex community?”  Things like that.  Other times, your client really is smart, and these can help empower them when talking/justifying your work to upper management or other stakeholders.

Programming Tip #5: Breathe, 1 Thing at a Time

When faced with a mess, and the pressure to fix it, it can be overwhelming.  You may perceive it as un-fixable.  The only time that a complete re-write is justifiable is on Flash projects.  Those typically are shorter, and a lot of times it is faster to just re-write it.  You can also ensure you’ll hit a deadline because you’ll be able to fix your code when something breaks because you know it.  For Flex projects which typically take 4 months or more, ditching 4 months worth of work is not often what a client will ever allow.  If they do, you probably aren’t reading this article… or a future one where I’ll cover this.

The first thing to do is breathe.  Even if the project is unfixable, there could be political undertones at play here, and you are merely a pawn.  A lot of consulting involves allowing projects to completely tank so the firm can come in and “save the client”.  You get on board early, establish relationships, warn the client, document the “I told you so’s” and “if you don’t listen to me, these bad things will happen”… and let the bomb drop on it’s own.  When the dust settles, your firm comes in, picks up the client and pieces, and starts from scratch.  Other times, your firm thinks that will happen (but it won’t), yet tells you to survive till then.  Still other times, it is fixable, it’ll just take 3 to 4 months (which coincidentally is the amount of time it takes to do the project from scratch *ahem*).  You need to visualize success, and make that visualization a reality.

You can survive 4 months.  You need to think of the positives.  First, it’ll be fixed.   Second, the client will be happy you came on board to fix it.  Third, you’ll learn a lot.  Fourth, you’ll have great ammo against those who say best practices are dumb.  Fifth, you’ll have great inner resolve to actually employ best practices in the future since you know the ramifications for not doing so.  If you choose to not employ them, you’ll know the risks, and can make better informed decisions when coding under a deadline.  The list goes on.

You can’t fix a bag of problems.  You can, however, identify what they are, put in a list, and go down the list; take 1 problem out of the bag at a time.  A long journey starts with the first step.  If you make that first step an easy win, this helps with your confidence, and the client’s.  It builds momentum.  You can use that momentum.  Once you’ve got a long list of fixed problems under your belt, and documented, you can start on the larger ones.  Once you’ve fixed 1 or 2 of those, you can step back and clearly see progress. Nothing wrong with reminding the client of this.

Again, don’t focus on the mess, the blood, or the destruction.  Just focus on fixing 1 thing at a time.  It’s been done by many others, some way less talented than you who just used willpower.  Breathe, it’ll get better.  You’re making it better.

Programming Tip #6: You Need to Log, You Need to Debug, and You Need Luck


There are 3 ways of solving problems in code.  Logging, debugging, and luck.

The best way to solve problems in code that is large and isn’t yours is via logging (tracing).  In some TDD circles, this is called “soundings”, in reference to sonar; using messages in a vast darkness to help you identify where you are.  Large code bases are like that.  It’s sometimes so vast it seems too challenging to “learn” how it all works in a reasonable amount of time.  That’s an honest assumption; a lot of large code bases I’ve seen takes 2 to 4 weeks for a decent commit from a developer, and 2 months for them to feel “confident” in navigating it.

The best way to figure it out is to place logging statements in strategic points.  The goal here is to learn how the app starts up, what parts are accessed when, and what parts aren’t.  You can only do this if you have a decent logging system in place.  Whether you use trace, DeMonster, Thunderbolt, the Flex SDK’s built-in one, or your own home grown one, you need to use it consistently.  In larger teams, it’s helpful to collectively add logging statements to help saturate the system in the beginning; you don’t need to do all the work yourself.  Additionally, if you’re logger helps promote filtering, you can get finer grained information.

Badly written code doesn’t tell you what’s wrong.  Even code that never works, but at least tells you why, is great because you can then attempt to either fix it, code around the error, and at least tell your client why things aren’t working.  If it doesn’t, it’s not helping you fix the problem.  Code is complex, and the more code you have, the more complexity you have.  While View/GUI code typically doesn’t have a great need for logging unless it’s doing custom drawing, data, networking, and domain logic code certainly does.

This goes in line with my don’t create grenades theory of ActionScript, but taken a step farther.  It’s one thing to wrap URLLoader’s load method with a try, have event listeners for both his SecurityError and IOError events, all to suppress the exception dialogue.  It’s another to actually log them.  If a class captures all synchronous and asynchronous, but doesn’t tell anyone, that’s worse than throwing the Exception dialogue.

Proper logging ensures a few good things.  First, you can suppress all errors, yet still be notified that they occurred without disrupting the user and without aborting the current stack (your app doesn’t just “stop”).  Second, you can provide helpful messages that expound on the default Flash Player errors which aren’t always verbose enough to indicate what went wrong (“null pointer” vs. “Dude, you gave me a null User”).  Third, you can provide context as to why the error occured vs. merely stating it occurred, such as “The server returned no records, meaning our save apparently didn’t work”, or “There is no currently logged in user, so I technically shouldn’t be running this code; // TODO: figure this out”.   Fourth, you can imply importance.  For example, if you attempt to close a NetStream, and one isn’t running, you’ll get an error.  This doesn’t hurt anything, nor is there anything you can do to recover from this error; thus, there is no need to log it as an error.  You can instead just log it as a warning.  That way, the more important errors you need to know about, such as a server returning a null response, aren’t mixed in with unimportant ones.

You want errors to be seen.  The majority of errors that occur in an application that has “shipped” are null pointers since our compiler + language is good enough now we catch most of the bigger ones during development.  These are situations where the code operates in a way it wasn’t expecting, or gets data it thinks is ok, and blows up.  Surpressing null pointers for the sake of suppression is really bad.  For example, code like this is bad:

public function load(url:String):void
   if(url == null) return;

   // TODO: load the URL here

If someone attempts to load a null url, you’ll never hear about it.  This error could exist for some time because no one is acknowledging it’s existence.  When you’re code doesn’t work, you don’t even know exactly where it failed.  This is a waste of time, and a bad practice.  Instead, you should let that one explode so when it occurs, you can clearly see it from the stack trace.  If you’re in a sensitive situation where you’re trying to prevent all null pointers because you have to demo the app, or you’re trying to “make good with the client”, surpressing it is fine, just log it:

public function load(url:String):void
   if(url == null)
       Debug.error("Service::load, url was null, aborting call.");

   // TODO: load URL here

See?  Now not only does the code not blow up, but if it does, you’ll be informed about it, and only if you have your debugger up, thus preventing users/clients from seeing it.

Once you get a bunch of these, you’ll start to see “the flow” of the application (assuming she’s healthy enough to even run… some aren’t).  Learning the flow is a great way to start understanding what is loaded when, how, and what doesn’t seem to be working properly.

If the original developer(s) aren’t there, you need to the code to talk to you.  The way you empower it to do so is via effective, and verbose logging.  If the original developer is, but is full of shit, this is another way to prove/deny… or at least spur more healthy debate to help solve the issues.

As the project goes on, these logs will help inform you of changes, both good and bad.  Communication with your client is paramount.  Communication with your code AND the client is great.

To me, the best diagnostic tools are the ones that run IN the application itself.  My criteria for good tools are simplicity, ease of configuration, and they don’t disturb anything.  If you have a logging window that works in a Flex app itself, you ensure it goes where the Flex app goes.  The easiest way to show/hide it is via a right click menu item.  You can hide this item via a custom build script grep, or a conditional compiler config.

Logging tools that spew out text are useful, but it’s better to have finer grained control on your logs.  As as your application grows, and your developers increase beyond just you, you’ll want to be able to log multiple things, but only see part of them.  For example, distinguishing between an error, and a simple warning.  While it’s good to be reminded that you’re getting a Security error from an image control attempting to smooth an image from a domain that doesn’t have a crossdomain.xml file for you to actually perform bitmap operations on it, it’s better to know that your web services are claiming your current, valid, 30 minute session has in fact expired after 10 seconds.  You do this by using logging tools that allow you to differentiate between different types of messages, and allow filtering.  You can use mine, create your own, or use others.

For development, this is obvious.  While a debugger can let you know exactly what’s wrong on any crash, a Logger gives you more verbose information in real-time.  It can tell you what path the application is taking, what is working, what isn’t, what steps you took as a Plan B.  It also help you debug errors by stating the current state of the app, what the current data you’re curious about is, etc.

What isn’t obvious is how other people having this information can help you.  By empowering your team; not just you and your fellow programmers, but also the testers/QA you are working with, your managers & PM’s, and even the back-end team.  Giving everyone easy insight, in human language, what’s going on inside the application helps facilitate better communication.  “It just crashed when I saved” doesn’t help for shit vs. “It said it got back malformed XML from the register service” helps a ton.  When they have this error, and you don’t, you’ve suddenly increased your productivity by having others do recon/bug testing for you.  Additionally, having the client actually give better, more verbose feedback helps back-end developers confirm/deny whether their changes have any effect.  More importantly, they can corroborate your logs with those of Charles or Wireshark, adding credence to your code in their eyes, and helping them more quickly solve problems.  Finally, anyone using the app is capable of copying and pasting the logs in an email to you if something went wrong on their machine.

Implement a logging tool, get your application talking to you and your team, in a more verbose, proactive language.


You paid $500 to $700 dollars for your mxmlc compiler.  If you didn’t, someone else with vested interest in you did.  Don’t be a dick and toss that fantastic engineering effort out.  Debugging is faster and more precise than logging.  It might not be as verbose as logging can be, but it clearly will identify problem areas more quickly and precisely than logging will.  Combined with logging and flash.debugger.enterDebugger(), you’ll have a winning combination.

If you can’t debug an application, make it your top priority after getting the build process under control.


Contrary to popular belief, you can in fact influence the amount of luck you have.  Scientific studies have shown that by being positive, you can have more luck.  Luck has saved my arse on a lot of projects, and I swear by it.  Obviously it should not be your main staple beyond good logging coverage, and a trusty debugger, but it shouldn’t be discounted either.  Keep your head up.


That’s good enough for part 1.  There are some more programming tricks you can, and should do, but these are the main ones to use when you start a consulting project.  There is also the whole uber-priority list; basically a checklist you should do at every consulting gig specific just to the programming portion.  Since it’s such a large topic, I’ll save that for part 2.

Just remember:

  1. Make it simple for yourself to code and confirm your code worked.  This may be a long haul, might as well make your next 3 to 6 months as easy as possible.
  2. Make a Plan A, B, and C for each task, with a cutoff date/time, and inform your client as such.  This assumes they have no process; even if they do, make your plan + time fit in it.
  3. Hit the low hanging fruit first for the first 3 weeks, or until you’ve garnered significant trust.
  4. Document your changes both in the code consistently so you can easily find them, and write up white papers for any of the larger refactoring efforts.  Send the bigger ones to your boss in an email as an attachment CC’ing yourself; need a paper trail.
  5. Breathe and think positively; this may take months, weeks even to see some sort of progress.  Just know if you keep at it, you’ll get there.  This has been done before.
  6. Get good logging in your app with ability to filter them.  Make the app so you can debug it with mxmlc.  Finally, be positive and luck will come your way.

Yes, you can re-write if you must, but that’s a future post.

3 Responses

  1. Great post..this article is so true..

  2. Stephen

    Regarding debuggers costing money, that’s not true at all. I’m currently developing and debugging a Flex 4 application using nothing but fdb. It isn’t as pretty as what Flex/Flash Builder provides, but there’s nothing it can’t do. The only required thing that costs money for an Actionscript developer is the Flex memory profiler and Flash CSx.

  3. @Stephen I’m aware that the Flex SDK is free and open source. My point wasn’t that you have to pay for the debugger. My point was, if you paid for it, use it. I’ve been on plenty of projects where the use of “trace”, and only trace was considered acceptable when the client had paid for over $3000 worth of Flex Professional licenses.