http://www.nytimes.com/2013/10/21/us/insurance-site-seen-needing-weeks-to-fix.html

First, when management says “a few weeks”, what that really means is a few months. Yes, months.

Second, because it’s so big with many of the parts not under the purview of the contractor, they can’t rewrite it. That means, it’ll take 2 times or more longer.

Third, bringing on additional contractors/people will not help fix the problem. There was a book written in the 1970’s called the Mythical Man Month that debunked the claim that adding more programmers will make things get done faster. It causes the opposite. See Slate’s coverage here: http://www.slate.com/blogs/moneybox/2013/10/21/obamacare_and_the_mythical_man_month.html

Fourth, launching a site before it’s fully tested is fine and encouraged. Software, currently, has no fool proof way to detect for all problems. There are certainly languages and programming techniques some mathematicians can use, but that’s not the tools the private sector uses to build web sites.

Fifth, even if fixed, it’s clear the parties they’re responsible for connecting to for customer data are a huge component and huge part of the problem such as the Centers for Medicare and Medicaid Services. Since they are not under the direct control of CGI Federal, the contractor originally responsible to build healthcare.gov, there is only so much you can do to compensate for someone else’ incompetence & lack of communication. Meaning, holding CGI solely responsible unfortunately is not an option. It’d be easy to blame CGI for the failings, but that’s not how software, and our bloated government, work.

Sixth, 8 out of 10 software projects are failures, and 9 out of 10 are perceived as failures. Software is hard. We do it not because it’s a lottery, but because when it works it makes a huge difference despite the huge assurance we’ll fail.

Things will slowly improve. There will continue to be glitches, some of which the press may even talk about, a year from now. Jan 1st deadline is unrealistic.

… and for those who are curious about what just 6 million lines of code can do vs. 500 million, check it: http://arstechnica.com/information-technology/2013/10/the-navys-newest-warship-is-powered-by-linux/

I won’t cover whether money can buy you happiness or not. All I’ll say is that for some people it does, and others it does not.

Many of the financial and tax nomenclature below applies to the USA, but the types of work are the same regardless of country.

Introduction

Early on my consulting career, I found the maximum amount of money I could charge per hour was $100/hr. I had just assumed it was a simple linear graph: the more time that goes, the more experienced & marketable I get, thus the more money I can make per hour. This wasn’t the main metric I used to measure my success, but it’s certainly how a lot of people, at least in America, do. “How much money do you make?”

As time went on, and I actually did get more experienced, I learned it’s not a linear line. A variety of things can happen, or not, to affect it’s elevation. Examples include not working for a couple months, whether intentionally or not. There are a variety of stages you can possibly go through, at least in software development, and I’m still learning all the possible vs. desirable ones.

The basics are starting out in an internship or job, then breaking away to do freelance, and finally starting a company.

Below are the 3 things that don’t work.

W2 – Salaried Employee

Salaried employees are those who work for a company, called a “job”, and that company takes out your State and Federal taxes for you. They pay a salary, a flat amount of money per 1 days worth of work, whether you actually work 1 hour or 12 doesn’t matter. They also offer “compensation packages” such as 401k matching, 20 or more vacation days, and 5 or more sick days. People put their own arbitrary dollar amounts on these which helps companies offset their lowered salaries.

The problem with W2 is that you eventually max out. I’ve yet to see a salaried programmer make more than $175,000, although most are $120,000. That’s gross, not net. That’s still only about $90 an hour if you take out vacation days and holidays. You’re replaceable, and there is only so much code you can produce in a given time on your own. Although there are skill trees for development, getting better doesn’t lead to making more money. You basically have to go into management, leadership, or sales to sometimes fully utilize all those software skills you know. There are SOME options for hybrid roles such as Enterprise Architects, people who dictate how to build things but don’t actually build the things. Sales Engineers are another. You travel with a Sales person and get their back when the clients ask highly technical questions. Sometimes you get to code, but they’re often just simple prototypes, not real projects.

Finally, W2 is perceived as a form of “stability”; something long term, something earned and deserved. Unfortunately, that’s how things were back in the 1940’s, not anymore. Regardless, the prophecy is self-fulfilling for some people, so they believe it to be true, and thus it is true even if it’s not.

Unless you actually want to get out of programming, W2 isn’t an option.

1099 – Freelance

Freelancers usually charge by the hour or project (obviously they like the former). They are synonymous with contractors: someone who works for the company but is their own business. Your own business can just be 1 person: you. You are ultimately responsible for all of your finances and taxes, thus you file a form for the IRS called a 1099. The common rule is when you get a paycheck, you immediately take 33%, round up, and shove into savings so you can pay once a month, 4 times a year, or once if you’re a slacker the taxes you owe the State you live in and the IRS. None of that includes your operating expenses like buying your own computer, contributing to your retirement, and paying your own medical insurance.

The key here, though, is you can pay those first, THEN get taxed on what you have left over using “pre-tax” money whereas in W2, you’re taxed twice: first on your paycheck and then whatever you buy with it, the IRS still assumes you made X per year. For example, lets say you make $100,000 per year. You then buy $50,000 worth of hardware, software, and office space. You then only owe $16,500 in taxes vs. $33,000 like you would as a W2. This desire to spend your pre-tax money, whether on stuff, services, or even contributing to retirement accounts like SEP IRA’s is yet another to balance in your time that has nothing to do with programming. W2’s don’t have to worry about any of this crap.

This amount of work is not to be understated. This is how many companies go out of business. It’s also a lot of work for 1 person to handle just 1 persons business finances, let alone all the time spent hustling to get clients. More importantly, though, companies bear this “burden” when hiring W2’s. This is why a lot more companies are going the 1099 route or hiring contractors for set projects, not providing benefits, nor the “free” tax services like Amazon and others are doing in the UK and in the states.

There are a variety of reasons programmers go freelance. There is no growth potential at their W2 job. They don’t like the clients they’re working with and want to choose their own. They have short attention spans and want smaller projects. They hate the large code base they’re working on that’s messed up and they didn’t create, and want the opportunity to create their own. They want to utilize a completely different technology stack and there is no opportunity to do so at their current job.

Whatever the reason, the POTENTIAL exists for making more money than W2. Sometimes, you’ll make less. The reasons for those are also numerous. While you may get many high paying gigs, you may actually have many weeks or months with no work. While W2 has a steady paycheck, 1099 does not. Additionally, there is a cost of doing business that you now incur. Time spent on the phone, writing emails, going to meetings and conferences, writing books, blog entries, curating relationships with your content and others on social media; all of that takes a lot of time that no one is paying you for. Some of that could lead to getting a client to hire you to build something. Sometimes that client just wants free consulting, or is asking you and 9 other contractors to bid on a project and they just want you to do the quote for them with zero intention of actually hiring you.

The reasons are vast. The theory, though, is that you’re using a technology with either a local market (where you live) that has a need for your skills, a remote market (meaning you telecommute with clients you’ll never meet face to face), or both. Sometimes you’ll get many concurrent projects. While one project has slow communication and is long term, and other is more clear, and shorter. While you’d prefer to have both side by side, the companies hiring you, and their clients, usually dictate the schedule, and they don’t care that you haven’t had any work all June and July, and now 3 companies want to start work immediately in August all at the same time. Sometimes that can work; other times it can sacrifice your code quality so you can only get one.

Bottom line, this is where most programmers get stuck. If they do manage to break the $100/hr barrier, it’s because they got a fixed bid contract and just did it in a shorter time. Meaning you produce the work for this amount of money, no more. If you work 4 hours or 40, you still get paid the lump sum. So, if you can do 40 hours worth of work for less than 40, then great, you just made more than $100/hr. Sadly, this is just 1 week out of the year. It also doesn’t factor in the cost of doing business to actually get that contract signed.

1099 is a mindset. You either like the freedom, the “harder I work, the more I get paid”, or just the lifestyle of having your clients… even if those clients are just like a W2, only with none of the benefits. Worse, many large companies cannot do work directly with 1099’s, and want to do W9. While that’s fine, it’s usually assumed those W9’s are a preferred vendor, or have workman’s comp and a lot of other bs that isn’t needed and doesn’t matter. If you get the W9, great, but if you’re not a preferred vendor and you haven’t convinced the company to go through the process, you’ll simply have some company you’ve never heard of take $10 to $30 an hour off your paycheck. Horrible.

Independent Contractor programmers, someone who owns a company strictly as a tax shelter and is a single person, aren’t usually paid more than $100/hr outside of California, New York, or Boston. So 1099 is usually a no go (exceptions below).

Recruiters

Recruiters are a waste of your time, and theirs.

Many companies lack the resources to “find you”. Even if you make yourself easy to find on the internets, they often won’t look. Swimming through mountains of programmer social media is less savory than paying a fee to someone to “find me someone with these skills”. While smaller companies who recognize the value of good talent DO use Github, LinkedIn, and Google to search for people such as yourself, they aren’t going to dump bling into your lap.

Thus, recruiters are often the gateway to jobs nowadays. Many in large companies like recruiters because it’s not their money being spent, and a litany of resumes arrive in their email with them not having to do anything but ask HR to send a list of requirements of what they need. As such, most job sites nowadays such as Monster, Dice, LinkedIn, etc. are owned by recruiters. I say owned because finding a job posting that ISN’T a recruiter is rare. If it’s not, the likelihood of someone with your skills getting past the often horrible interview web applications or HR wall (“Yes, mam, as I’ve told you, MVP is just like MVC, and Ember and Backbone share many characteristics, so if you know one, you can easily learn the other and be prod… mam? Hello?”)… all for W2 position we’ve already talked about is a no go.

They’ve seen their business explode since the information age started back in the 80’s and 90’s. We have some of the worst unemployment, underemployment, and those giving up and leaving the workforce since 1979. This means a few things.

First, it’s just “normal” nowadays that mid-size and large companies use them. You may not like the game, so you can either get played by it, play it, or make your own rules.

Second, a lot of them are NOT there by choice. We have a swath of college educated youngsters with degrees not in the Art disciplines who just can’t find jobs that their degrees implied. Many went to recruiting because they had no other choice.

Therefore, you shoulder never be rude to them for the above reasons. Yes, I troll them every chance I get, but that’s in good fun. You should never be rude; you never know when you have zero choice but to go through a recruiter for a job. We’re extremely lucky in software, and history shows it will not last.

Keep in mind larger consulting firms like Accenture, Deloitte, IBM, Randstad, etc. are hybrid. They sometimes act like staffing companies, but often have internal divisions that do consulting. Meaning, although they recruit you, can you get above $100/hr rates with them which often includes lots of travel, but is still longer term projects. Still, better to err on the side of caution; bring up money first to save yourself time.

That said, again, recruiters are a waste of your time, and theirs. I made $80,000 at one large company, and another $140,000. We went through the same recruiting firm for the same position. When I once was hiring for my client, the recruiting firm was charging $200/hr and paying him $80/hr. Finally, recruiter rates are beholden to the location in which they are hiring. You won’t get New York city rates in Nashville even if the recruiting firm is national; companies, even for telecommuters, often pay the local rate.

5 Solutions

So if “a job” caps out at or below $100/hr, freelance has no growth potential with maintenance pain, and recruiters are worthless, what to do? You have 5 options that I’ve seen work. I’m sure there are more, I’m just basing the below on what’s worked for me, others I know, and what I’ve seen work from past clients who’ve done it.

1. Build a Personal Brand
2. Score a large client
3. Find a Closer
4. Find a network and form a firm
5. Start a business

Build a Personal Brand

I’ve written about Personal Branding 7 years ago. I even talked in depth about Personal Branding in my video series about becoming a successful freelancer. Make no mistake; the level of effort is inversely proportional to how bad ass you are. This includes either your talent & technical prowess at programming, your charisma, or both. The less awesome you are, the harder you have to work. That’s called life.

Worse, if you cultivate a rock star status, whether on purpose or by accident, fame is fleeting. Trends in software occur just like they do in the music industry. A library you wrote, a blog post that became popular, or an app that scored you money and fame… is only temporary and you can only milk it so long. A personal brand is something that is cultivated often, like a garden. The decisions you make in the beginning help guide it and create expectations amongst those in the industry.

Writing blog posts, contributing to open source, releasing helpful code, speaking at conferences, and writing books are all staples of building a personal brand for yourself. Additionally, networking and PARTICIPATING in the industry, even if it’s just your small niche, are important. You want people to like you, you want them to want to work with you, and most importantly, THEY should be selling the client on you, not you selling the client on you. You don’t have a resume.

Those who have cultivated their epics skills/personality/brand are rife. Martha Stewart, Rachel Ray, Dr. Oz, Oprah, Craig Ferguson, Conan O’Brien, etc. In our industry, Grant Skinner, Bruce Eckel, Linus Torvalds, John Resig, Paul Irish, Joel Hooks, Alex Russell, Joshua Davis, Joa Ebert, and Ricardo Cabello (Mr Doob).

You may not know some of them, which is fine, but also potentially brings up a good point. Some of them spend more time using their talents, and the fame is just a byproduct of that, whilst others get the marketing angle, and help accentuate their work. People like me are 90% big mouth, 10% contribution. Any combination works. The point is, it’s hard work, but less so if you’re talented. And you can’t stop, you have to keep marketing yourself, either through continually producing awesome, or continually producing just enough awesome, and marketing like crazy.

If you’re famous, you can easily charge more than $100/hr for freelance work even for work that’d normally go for $80/hr. Just depends on the clientele.

Con? It’s a lot of work. All the time. Sometimes you have to start at square one if the tech changes. It can be done and repeated and is easier in a objective discipline like programming vs. the entertainment industry.

Score A Large Client

I’ve seen many large agencies and software firms sprout up like this. You’re 1 dudette/dude, 2 friends, or maybe you just know a lot of people you could sub-contract for design and other back-end/front end development if you could only get a large client. What happens is, the contractor gets a large client, can’t handle the size of the project alone, hires people, and voila: a company.

The money comes into play from 2 places. First, the job is obviously larger, thus requires more money to pay more people for more time working.

Second, those more people do not get the same amount you do. There are a variety of factors that dictate how much a designer gets, a front end developer gets, a back-end developer, manager, project manager, qa, etc. The more you make is inversely proportional to how much you pay your sub-contractors/employees. The less you pay, the more you make. Except it’s not you, it’s the company… or are you just paying yourself? That gets into running a business which I won’t cover here. Obviously if they’re an idiot contractor who’s good at coding but sucks at math, you can’t pay them less than living expenses, else they’ll lose their house/apartment/flat in the middle of the project, and that’s no good. Yes, you’ll get people like this.

You then bill those people out at a higher rate. This is how it works with big clients. Large company hires large firm. Large firm hires smaller firm. Smaller firm hires you as a 1099 contractor. The pay goes like this: Large company pays Large firm $300/hr. Large firm pays Smaller firm $150/hr. Smaller firm pays you $80/hr. Now that you’re the Small firm, you now get the $150/hr… and you’re sub-contractors get the $80/hr. Make sense?

The more sub-contractors you get, the longer the project is, or both results in more money in your pocket; well over $100/hr.

How does one score such a Large client? One way, you can become a preferred vendor/consultant/provider of your favorite technology stack. Whether it’s the company that makes it, or those who have a vested interest in it, one things for sure: those who make technology are not consulting firms. They focus on making tech, not forcing a bunch of people to travel to some random location to build something for random business for a bunch of dough. YOU and yours are the ones who actually represent that company and do the actual work. Obviously they have small arms in the sales team that do this, but they usually don’t scale that side of the business.

Another way is networking with past clients. One way to utilize a network you’ve created is to contact past clients’ clients directly if your non-compete is up. For example, lets say you worked for a company as a 1099 that worked on a project for Nike. You did a great job, and had a good relationship with the company, and even had the opportunity to work with some people at Nike directly. Most smart companies will ensure you never talk to them for this very reason. 1 year+ later (or whatever your non-compete states), you reach out to them and ask if they have any work. If you kicked ass, they’ll remember you. Suddenly, that cut in pay is gone since you can form a direct relationship with them either as W9 (corp to corp), and possibly become a preferred vendor for that company: 1 of many companies who gets first dibs on projects they outsource.

Other times, you just get lucky as a Freelancer, and you portray yourself as a “company” with 6 people (who are really part time sub-contractors). Thus, larger companies will come asking you to deliver something quite large. It’s not dishonest at all if you truly can deliver. I’m making the assumption here you’ve worked on multi-person projects and can actually do what you say you can do. It’s all about how sell yourself. Example: jessewarden.com vs. webappsolution.com.

Don’t be afraid to write contracts that are too large for you to handle. If they were, you wouldn’t have the cajones to actually move forward with it, and finding resources for a project that’s too big for you is a good problem to have. It’s already assumed at this point that you know a bunch of freelancers, and might have even put them in a spreadsheet to list their name, contact info, last known rate, and area of speciality. BUILD UP THAT NETWORK and then USE IT.

Find A Closer

All closers are salesman, but not all salesman are closers. Many companies spring out from a talented closer who scores that big client, whether from a cold call or networking. It’s like the previous “Score A Large Client”, except there’s no work on your part: you just unleash the closer and wait for her/him to catch you a big fish.

I’ve seen some successful firms/companies who are basically run by these closers. Many are partnerships where a talented programmer partnered with a talented closer and together they built a company.

Actually FINDING one is where I can’t help you. Most either formed the company on their own or the technical person had a childhood/college/previous company relationship beforehand.

Commissions don’t help, either. “Dude, I know 9% is the norm, but I’ll give you 20%.”

“Oh yeah? How much y’all pulling in a year?”

“Uh… I guess $1 million.”

“My current company gives me 9%, but they rake in 30 million. Thanks for the free beer, though!”

Find a Network and Form a Firm

You can form a firm in 2 ways. Basically, you do #1 where you’ve either established a name for yourself, and find like minded people who want to do the type of work you want to do with the types of clients you like to work with.

The other option is just like her majesty’s life advice: surround yourself with those better than you. You basically find a group of people, at least 1 but hopefully more, who think like you do. You all agree to find work, share work if you’re too busy, or help each other out on projects WITHOUT a premium; meaning you don’t take a cut of the rate from each other. This makes some freelance gigs a lot easier because you can borrow people for helping you out on some projects. Since they make you a priority, and there is no worry about rate negotiations, it’s a no brainer. THAT has some serious value to clients that you should up-sell. Most clients who know what they are doing recognize that already when dealing with companies that have more than 1 person vs. an independent contractor… sometimes.

More importantly, though, is the hope that they already have the preexisting network contacts described above. Even better, you can combine networks. It actually goes over quite well when you describe to the client that you’ve left the previous firm to found your own since that client wants you anyway. They’ll often assume you formed it to work with like minded individuals and you’re still in the idealistic and prove yourself/your company phase.

This is basically what I did when one of the firms I was working with exploded on itself. Preferred vendor, existing client base to get opportunities from, and 3 guys who all have different strengths that compensate my weaknesses, specifically 2 of them doing back-end Java (I’m 100% front end). The bigger clients want Web App Solution, not Jesse Warden.

This is the opposite if your brand is really powerful, though. For example, some strong personal brands form a company, and larger companies will hire them strictly because they want that one person’s expertise/clout/reputation.

$101-$119/hr is no mans land. Once you have a company that consists of individuals, not just a bunch of subs, $120 on up gets tons more likely… because the sum is greater than its individual parts. That has a lot of value to companies who need you to scale, be used to scaling quickly, and have a network of your own to acquire certain resources for certain types of projects (UX, design, business analysts, etc). That and it’s easier for the CPA and lawyers to swallow since you’re a more legit entity to do W9 work with for tax and legal purposes.

Keep in mind, while it’s obviously nice to have a track record that you can show to existing clients of your firm helping companies build awesome, often it’s just as accurate to use past clients as that track record. For example, all of your past freelancing clients you can include in your company’s repertoire of past clientele.

If your partners, or even just sub-contractors don’t have a network, you better have one… else you’re just fishing for the big client with extra lines in the water.

Start A Business

Everything I’ve talked about up to this point has been B2B: Business to Business. Some company hires your company. However, that’s not where the real money is for software development. The real money is in products. Now, granted, you can create products for a certain set of businesses, thus making you a B2B, vs. targeting consumers as a B2C, but the point here is you are NOT a services company: You’re a product company.

If a clients software project fails, your company doesn’t fail. If your a product company, and your product fails, your company fails. Huge difference.

Products also have the nice ability to sometimes make passive income. That means, while you sleep they make money. Some products require companies around them to build and support them, hence the current state of Silicon Valley. The amount of effort gets less every day, as does the cost of entry.

While there is more risk, having hundreds or even thousands of people pay $10/a month for your software is a lot more appealing then hustling multiple times a year to get a client to pay for the next few months. You can flip that around, too; a few dozen customers paying you $250 a month.

While there are a bunch of great articles and books on the subject, here’s the general idea:

1. Find a problem you think you can solve with software, and if it has competition, you think you can solve it better.
2. Build a prototype in less than a week.
3. Show it a potential customer and ask them if they’d pay for it.
4. Iterate weekly/bi-weekly until they do.
5. Get more customers.

Eventually you’ll reach what Paul Graham calls Ramen Profitable. It’s a way longer ramp up time, but has a potentially greater reward. It’s also assumed you’ll fail multiple times getting there which is hard for some people to swallow in a culture that’s all about winning and “the thought of losing… is HATEFUL to Americans.” — Patton.

If you ain’t failin’, you ain’t trying hard enough, sucka!

Dangers

There are a few potential dangers you need to be aware of going the above route.

First, you need to be flexible. Are you willing to accept work at or below $120/hr? If not, can you survive on savings until you find a client? The “I deserve” or entitlement mentality is dangerous. You don’t get what you deserve, you get what you negotiate. Some companies just don’t have that kind of money.

Second, it’s hard to go back to salaried positions once you’ve gone the Firm or Freelance route. The startup route is a lot easier, and the freelance somewhat easier. Often, if the company doesn’t know your brand, it doesn’t matter. You need to be careful how you pitch your “long term consulting” or “short term freelance”.

If you ran a company, you suddenly know a lot about the game, and companies get nervous when you want to quit that and go back to W2. Sometimes that’s uber valuable to them, but as a front line software developer, it’s sometimes hard for them to see that value. Others get nervous if they see a lot of short term gigs on your LinkedIn and/or resume and you suddenly apply for a long term position. If you talk to a business owner, it’s an easier conversation; they get it. Other times this can backfire; “If you’re running a business, why come work for me? What about your competing interests?”. If you talk to an HR, manager, or senior developer, they might not understand at all. Remember, the truth of your history is written by you; modify your social media and resume to match the position you’re going for.

Also, be aware it’s a new world. Going back to the old one can be hard. You can sometimes forget what it’s like to NOT speak about business and software in the same sentence… vs. just software. This is reflected in your resume, social media, and conversations with people.

Conclusions

If you want to break the $100/hr barrier, getting a salaried position, being a single freelancer, or wasting your time with recruiters won’t get you there. There are a few exceptions with freelancing, especially on the back-end. Many Ruby/Python/Scala etc. guys can charge $200/hr to $300/hr in the Bay Area. The key, though, isn’t getting a project for that much money, it’s getting a career where that’s the norm.

Whether building a strongly recognizable personal brand, scoring a large client which is a catalyst for creation and growth, finding a closer, forming your own firm, or even creating a product that itself validates the company around are just 5 ways in which you can break that barrier. I’m sure there are more.

Even not being successful, you still learn a ton, and if you’re a long time software developer, constantly learning and re-learning is probably something you already do anyway. So it’s ok to try some of the things above and fail, especially the last one. I’ve had a lot of failures. I even once refused work for 6 months in an attempt to learn how to double my rate. I failed but I learned a ton.

I also posted a companion video to this post, embedded below, that you can watch.

The Priority Pyramid is a tool I use to stay on track with new consulting clients. It prioritizes how, who, and what I engage in at any given time. It can be overwhelming when thrust into a challenging situation, a code base in dire straits, and a frustrated team. You need a strong pillar of guidance.

This article goes over what parts make up the Priority Pyramid from a high level. I’ll talk about what milestones make up each section and how you navigate back and forward between the priorities.

When done, you should know how to engage your client’s team and tackle working on a large code base at a frustrated client site with 99 problems.

Why?

Over the years, I’ve prioritized what I need to be doing when working my consulting clients. There are countless things I need beyond “coding”, and all have to do with “people”. Code in its own right is challenging enough. Add people to the mix and it gets more complicated than it already is.

Every engagement is different, even with repeat clients. This is why I like consulting. Meet new people, travel new places, learn new things.

While I enjoy and thrive on improv, what I didn’t like was not having a set of guidelines to deal with each new client. The business blogs & books I’ve read are pretty dry, and don’t really focus on the people issues coders encounter and have to deal with. Most also assume YOU are the one creating & maintaing the app, not fixing/modifying a large one extremely behind schedule. It’s either sales, management, or product management. This includes the consulting books. Some approach it from a larger consulting perspective, where you come in, listen to the client’s problems, write up a plan, and pass it off to India. If you are involved, it’s just to either head off major disaster and/or provide face time for the client.

This is NOT what I, and my colleagues I’ve worked with over the years do. We’re in the trenches, working alongside our clients, playing the politics games whilst coding.

So, I made my own rules for engagement, prioritized based on importance, with verification points to ensure I’m on the right track. If I cannot work towards getting through all tiers of the pyramid, I will not be working for the client long, whether by my choice or theirs. It’s important I flush out these red flags early and tackle them full bore.

That… and it has D&D connotations.

Quantitative vs. Qualitative Foundations

I’ve used both quantitative and qualitative results from case studies, white papers, and my own experience to base this set of priorities on.

Mythical Man Month/Brooks’ Law: “Adding manpower to a late software project makes it later”. Some of the bad projects I’ve been on had too many people on them. Your goal at that point is to delegate refactoring to the team to compensate, lead with good architecture, and leverage your trust currency to guide the various teams into a direction you need them to go. Also known as software chaos management. This requires you be at a high enough level to be in charge of various teams. If you’re not, God help you.

Code Review: One person, reading code for up to but not exceeding 1 hour finds more code defects than unit testing. This is not peer review, but that is also effective. Citations: Code Review at Cisco Systems, Klocwork/Forrester “The Value and Importance of Code Reviews”, and some other stats from Code Complete. Keep in mind while most of the studies mention that defects do not significantly decrease after 1 person, the ability to learn from your peers and getting architecture suggestions are very well documented in the blogosphere.

Cheaper to Find Defects Early: Whether you are ruthless about upfront requirements gathering and/or initial architecture, or are adamant about short development iterations that includes scope reduction, both allow the ability to find more defects early. It’s easier to both find, and fix problems earlier than later for a variety of reasons (code size, feature acceptance, contractual obligations, etc). Beyond the IBM studies back in the 70’s here’s an excerpt from High Quality Low Cost Software Inspections. Also, crazy charts from Capers Jones (they have some other good studies). This is why I’m so adamant about getting the visual design (wireframes/design comps/ux/information architecture, etc.) right from the get go, even if 6 months into the project. Lowest hanging fruit and saves tons of time/money.

Distributed Development (PDF): The result that physical distance between developers doesn’t matter. Different room/building/country… not a big deal at all. What matters is how far the software developer(s) are from the stakeholder(s) in the organization management hierarchy. This is extremely important. I am firm believer in both telecommuting as well as on-site visits with clients for communication & leadership reasons. This is central to identifying the power structure of the organization in Tier #2 and garnering trust with those who can help you talk to who you need to talk to in Tier #3. I’ve been ineffective at more than one consulting engagement because I wasn’t  high enough to affect the required positive change.

Toyota Production System: Their continuous improvement philosophy and respect for people are what really ring true to me. While It Takes a Village to build great software, sometimes you have a crowded, drama filled city that you have to work within. Doing your best to get the team motivated to constantly improve, and SEE the improvement occur over time for motivation reinforcement, is just a small way to continually improve. You can only do this if you do in fact respect the people you work with. Empowering leaders amongst those who actually do the work can lead to effective production. You can use these Toyota Process strategies in your own team delegation.

The Priority Pyramid

The 8 steps are in order of importance:

1. Report
2. Understanding
3. Trust
4. Lead
5. Build
6. Explosions
7. Diagnostics
8. Architecture

While it implies 4 are about coding, make no mistake: The Priority Pyramid is all about people. It’s built on your relationships with them and those relationships ensure you can do your job.

Lets break down the tiers the following way: What milestones do you need to complete, how to do you move on to the next tier, and when should you move back? I make the assumption if you’re on a team, you’ll divide tasks appropriately.

A Note on Tier Foundations

Each tier works on top of the foundation of the former. If the foundation is weak, it won’t strongly support the one on top. If you don’t have the trust of management and your co-workers, it’s difficult to lead them. If you don’t have a good understanding of the company and people who work within it, it becomes very difficult to affect positive visual design changes to make architecture easier. It’s ok to be in Tier #8 and realize you need more understanding of how the application will be deployed from Tier #2; just like refactoring code over time, you can continue to strengthen the foundation tiers over time as well.

Tier #1: Report

Milestones Before Arriving

1. You’ve talked to stakeholder(s) on the project to have an idea of what you’re getting into.
2. Verify you actually want to get into it. Some consulting gigs are hard to get out of. Some can reflect poorly on your firm/you even if you do a good job. Make sure you’re willing to make the plunge. We’re looking for red flags here to save you tons of money and stress. I’m not saying be choosy, I’m saying be careful.
3. Where you’re going, who you’re supposed to see, and when.

Milestones

You/your firm has scored a client, you’ve booked your airfare + hotel, and you’re 1st day on-site has arrived. You look sharp, are excited, and looking forward to making a good first impression.

1. First question out of your mouth after small talk should be “Who’s do I report to?”. Yes, it’s ok to follow up this question once you’ve scored more rapport with “Great, so… who’s my boss?”. This ensures you don’t do good things that get you in bad trouble.
2. Second question: “What will make you happy when I leave?”. This helps verify why you’re really here, and what they’re really paying you for. Sometimes this takes alcohol to get the true answer. Sometimes just a neutral setting outside of the office/building.

Successful Exit

Know who you work for and your true goal in life for the next 8 months.

Tier #2: Understanding

The best communicators are good listeners. Your task now is to look people in the eye, lean forward, and listen well.

Milestones

1. Listen: Get people talking, asking questions, and listen to what they say. This is the most important step in the entire pyramid.
2. Goals: You need to understand what the goals are for the project, both stated and real. What are you and the client really trying to accomplish? Answering & documenting this will guide your actions for the rest of the project, overridden only by “Who do you report to?”.
3. Problems: What are the problems and challenges the company has run into? Do any relate to why you’re here? Do they have a thorough list or are there more? Solving problems earns trust, and helps in the next tier. It also validates your paycheck. Why does the client have those problems? Where do you fit in? Who’s accountable for identifying solution(s) for and solving those problem(s)? These are your first challenges in the game.
4. Dissect People: This is also an opportunity for you to start learning who the players are in the game. You need to understand what makes someone tick to best interact with them. Do they like business first, small later or the opposite? Do they have ulterior motives? Can they be trusted? Can they give you valuable intel on the project others won’t? What will it take to make them comfortable enough to tell you more? How can you possibly help them? You’re going to be spending the next 3 to 18 months with these people. Get to know them, make a good first impression, and understand them. These are the people you want on your team, who you want to do certain things for you, who you want to trust you. Once you understand them, you can effectively engage them. Sometimes this is done simply by watching how they interact with others. Ask questions to get them talking; their personality whilst reveal itself. Finally, figure out who reports to whom for real? What is the power structure? You’ll need to play within this framework; best to know how it works for real vs. what the label says on their door.
5. Explore: Finally, code stuff. Time for initial reconnaissance. Taken what you’ve learned, it’s time to verify what you heard is recent, relevant, and can be corroborated with the code. This should still be framed from a “learning the company” perspective. You need to:
1. Learn the Data Model: The VO’s, the Services it calls, and what those business objects actually mean to the organization.
2. Learn The Framework: How is the code architected; what framework did they use?
3. Understand The Story: With another developer, preferably one who worked on the code base and/or your client, ask the developer questions to learn the story. Even the worst code base has a reason how it got there. Like an archeologist, you want to understand this history, the pivotal decisions, or lack thereof, that made it the way it is. You’ll learn the to respect, and pity, even the worst code base once you’re armed with this knowledge.
4. Look For Red Flags: Both the currently benign, and the “holy eff we’re eff’d”. Whether that’s everything being a hashmap in Java, Angular & Backbone both being used in the same code base, or ActionScript 2. You don’t want surprises, you want to frame your perspective of the code base with your client’s. This is a VERY important step. Don’t say it, but talk about it internally in my mind. Find out why there is a disparity in perception.
5. Look For Mines: Like red flags, these are things that down the line of a project, based on what you learned above could go boom. They aren’t a priority but need to be documented.
6. Look For Validation: Did everything you learned in Steps 1 – 4 get validated or where you completely off? If so, continue to dig, and redo steps 1 – 4 to re-verify.

Successful Exit

When you firmly understand the client’s reality, the reality the code reflects, and the real reality once you’ve resolved the two, you’re ready to move on. If they still don’t mesh, keep asking questions & researching.

Tier #3: Trust

Assuming you’ve made good first impressions with those you’ve met, it’s now time to validate those initial impressions in those you’ve met. It’s time to start building trust.

Milestones

1. Provide Immediate Value: Check in code into the company’s source control your 1st week there. Preferably the code fixes a bug. Do NOT try to save the world in the code base. Pick some litter instead. If you clean the entire thing in a day, great, but get your feet wet and see what happens. A lot of drama and things you couldn’t predict happen AFTER you’ve checked in code and it goes into production. Start small and work your way up. Just ensure it’s immediate.
2. Make Professional Friends: Respect those you work with and get to know them. Whether this is small talk that’s sincere or genuine interest, whatever works to build a positive relationship. People trust those they like. Trust is a currency you’ll sometimes have to spend in buckets to make positive headway so start investing in earning some now.
3. Visible Logger: Invest in a visible logger. Even if the code doesn’t currently have problems, when it does, you want it to talk to you. Not only you, but the company. You want to corroborate this communication with your boss. When production explodes, and you know within seconds because your little secret keyboard shortcut debug window shows the error, that inspires confidence. It also provides a kind of transparency to your client when others start using it proactively to find problems. You just empowered a company to work together; well done, that’ll earn some trust. Make the code talk to you so you can trust what it’s saying, then expose this communication channel to your client.
4. Provide Transparency: As you start getting your feet wet, whether this is struggling to get your environment setup so you can compile, or are deep in the bowels of fixing your first bug, let your boss know. Keep them appraised of what you’re doing on regular intervals, even if she doesn’t ask. Come across with confidence; you KNOW what you need to be working on, and you’re informing your boss as such. Additionally, she has a chance to re-prioritize if you need to be working on something more pressing. No communication, and neither of these things happen. If they know and have confidence in you doing what you say you’re going to do, they can play defense and keep their boss off your, and your team’s back.

Successful Exit

Do you think people trust you? Have you checked in working code that fixes a problem and your boss has verified this? Can you even compile? Do you know the names of those you’re working with/near? If yes to all, you’re ready to move on.

NOTE: If you ever lose trust, fall back to continually adding immediate value. Trust isn’t given, it’s earned. If you lose it, the only way to get it back to is re-earn it from scratch.

Tier #4: Lead

At this point you know enough about the goals of the project to start formulating plans on moving forward, whether this is how to implement new features or how to fix/refactor existing ones. You’ve provided enough value to earn a modicum of trust. It’s time to lead people forward.

A manager puts people in a line, puts the guy with the machete at the front, and leads people through the jungle effectively. A leader climbs the tree, and tells everyone they need to go left instead.

Milestones

1. Short Term Goals: You’ve assessed the situation and identified priorities that need to be refactored (using my previous article). You need the team to agree on a common logging interface, both in code and visually. Finally, you need the team to agree on an architecture.
2. Long Term Goals: You’ve identified architecture holes that need to be plugged. Sometimes there are design problems that if changed could save months of work and hardship. You need to start work and documentation on it now. Solidify the long term goal into something defendable, and get the teams input. Be careful how you go about talking about it. While you need client feedback (remember transparency), it must be attainable to company-relevant, short term steps. You can spend trust currency for longer term refactoring/re-architecture endeavors, but I recommend against it.
3. Resources: Sometimes you need to hire additional people, whether from internal client teams, additional consultants/contractors from your firm, or hiring on behalf of your client. This could be staff augmentation or hiring a specific skill set you need/want. Identify these early and ask your boss.
4. Divide, Delegate, and Conquer: Whether the client’s employee’s or your firms, you need to divide up the massive amount of work amongst people. Offer up tasks first, and then assign to those you deem appropriate if no volunteers materialize. Building upon Tier 2 and 3, you should have a gut feeling for who’s best for what task. You cannot save the world by yourself. It may seem that you spend more time aiming people in the same direction then actually walking that direction yourself. Don’t fret; you’re on the right track.
5. Be Positive: While misery loves company, people like and follow positive people. In talking & delegating all of your goals, plans, do so positively. You’re not “fixing a pile of rubbish”, you’re “building an awesome application” or “improving an important machine” or whatever you can say and actually believe when you say it. Eat right, exercise, and/or surround yourself with positive influences. Make this the year you commit suicide, reorganize & clean your working environment/home office, or just accomplish a small goal that’s not work related that you use as positivity fuel. Mentor & encourage your team but don’t come off as a know-it-all/holier-than-thou. Play to win.

Successful Exit

If you know what you/your team needs to be working on today, next month, you’ve approved the hiring you need, and the team is all tasked up, then it’s time to move on.

Notes on Tier #5 – 8

The latter teirs are development specific, but rely on a strong firm foundation from the first 4. Remember, the human component is your weakest link, not your Factories. Strengthen them; do not enter these 4 latter tiers of first 4 are weak.

Tier #5: Build

You need to easily build the software. This is the most common, and frequent, option you’ll do many times a day, every day. The longer this takes, the longer it takes you to develop. This can also kill your team’s momentum. If something goes wrong, such as someone checking in a bug that breaks the build into source control, or a feature needing be implemented for a presentation by some date, a slow build exacerbates time to resolution.

Worse, some developers will start making their own build setup, leading to code that works on some developers machines and not on others. Validation of working code suddenly becomes meaningless which can adversely affect project schedule metrics. Even worse, you can think your code works, but it doesn’t for others. Who’s right?

Milestones

1. Quick: The build needs to run quickly. This obviously an arbitrary metric based on code size, libraries, continuous integration setup, etc. If developers say “the build is slow”, then it’s slow. Utilize libraries so the entire thing doesn’t have to compile, inject dependencies at runtime, utilize modules… whatever it takes.
2. Easy: If the build is complicated to do, you’ll get developers making a lot of mistakes during code validation time before they check in. They’ll either check in bad code, or make their own setup that allows the code to work on only their machine. They should be able to just click 1 button, run an Ant/Maven script, or do a 1 line command line execution.
3. Duplicated: The build should be able to be duplicated on a new developers machine. It’s completely fine to have company standards, such as only Windows 7 PC w/admin rights, Flex SDK 4.6, running Rake 0.8.2. It’s also ok if that takes some time with another developer to setup. What’s not ok is once they do that, it doesn’t work. If there are 3rd party dependencies that cannot effectively be deployed x-machine, find a way to remove them. Solutions include, again, using libraries, modules, development servers vs. local server setup, etc.

Successful Exit

If you can run the build multiple times a day without pulling your hair out, it can be run multiple times on the same code base and not break, and anyone on the team can explain to a new developer 90% of the setup, you’re good to go. Another validation includes Developer A checking in code, then Developer B updating to latest and running the build and it works on their machine as well.

Tier #6: Explosions

When things go awry, you need to immediately know where and why. More than a euphemism for errors/exceptions, explosions also include errors in the application that constantly cause fire drills in the company.

Milestones

1. Exceptions Handled: Handle all errors save null pointers. If you have global exception handling capabilities, implement it/them. This doesn’t mean just wrapping something in a try/catch; it means not only logging the catch, but putting something meaningful in the catch so you’ll understand what it means when it happens.
2. Logging: You need to centralize all long into a single library. It’s ok if this library is your own that builds on top of the built-in provided one, such as Flex’ ILogger. As long as anyone, anywhere on the team wants to log something, they use that vs. print/trace.
3. Visual Log: Optional: A visual window, built into the application itself (SWF/JS, etc), that prints out the log levels. This is done to allow logs to be seen by developers, not users. It also allows non-developers, especially QA, to proactively find problems and talk directly with those responsible vs. the 1st developer they can find. The value this provides in empowerment and time saved should not be underestimated.
4. No More Fire Drills: Wrangling in challenging errors to help prevent fire drills can do 3 things. First, you score a lot of trust in “knowing” why something is wrong vs. 10 people running around aimlessly trying to figure out why. Second, you can clearly cite accountability; is it the server-side team, your team, or the database team? Instead of yelling “I think your stuff broke” you can confidently say it did with helpful data for them to test against. That kind of attitude is much easier to solve problems with. Third, fire drills no longer sabotage your productivity.

Successful Exit

If an error occurs and you know where it happened, a general reason of why, and who’s potentially accountable, you’re in insanely good shape. Users don’t see these errors, just null pointers, or those you’ve built a GUI for (ie Alert error dialogue). Bonus points if fire drills happen on other teams that aren’t related to yours… but you have a way of helping through logging to make testing easier.

Tier #7: Diagnostics

Diagnostics form a range of tools, not just code. They are anything that helps provide insight into code issues or runtime errors without costing more overhead in maintenance than the value they provide. The reason diagnostics is before architecture is that in larger applications, especially in a consulting context, adding simple diagnostics has a ton of value with little effort whereas architecture takes a ton of effort but tends to have low perceived value (yes, it’s valuable, just harder to sell).

Milestones

1. Unit Test Coverage: Even if you’re not doing TDD, unit tests along help find & prevent bugs as well as improve API’s. Unlike code reviews, they don’t get tired, benefit the entire team, and if written well only slightly add to code maintenance. Finally, they can be automated. These are also great things to work on in down times such as when JIRA is cleared, you’ve hit a brick wall with another bug, or are waiting on dependencies for a feature.
2. Integration Tests: These are my favorite on service layers, more so than unit tests. The reason being is most of the Flex projects that I’ve worked on in a consulting context had some form of service layer problem; ie how they talk to the back-end. Both refactoring the service code and writing unit tests that allowed me to automate the testing. It’s also nice to quickly know what part broke with confidence; client, server, or database. Automating these also makes you feel better when the server guys test new code, you can quickly help them test. There are more to integration tests, but these are the low-hanging fruit of ’em.
3. Automated Builds: Expanding upon Tier #5, streamlining your build process to be more inline with continuous integration practices. This means designating a resource to setup, and maintain, a continuos build tool like CruiseControl/Hudson/TeamCity, etc. You should know who checked in bad code and when.
4. Custom Diagnostics: Some applications have challenging domains of complexity. For example, video; there are TON of things that can go wrong at runtime even if the code compiles just fine. There are also a sequence of events that can cause video to fail, and knowing this sequence is paramount in debugging it, or shrugging it off since there’s nothing you can do (i.e. CDN is down). More importantly, though, sometimes you need a way to glimpse this in a more visual way than a logging window can provide. Conversely, sometimes you need to see environment variables in real-time. This little window can verify your application is running in the mode you think it is for a developer in another country. Simply making a box with a text field in it that showed Flash Player’s sandbox security type saved me 3 days (I lost 3 figuring this out, heh). Additionally, they can help empower others to do testing & diagnostics on their own. Just be careful these are not a security risk for code and/or company information if deployed in production.

Successful Exit

If you have good unit test coverage, can automate their running, your build is automated in some fashion (even if just client side only), and you have gui or command lines way to gain insight to your running application to find out more about errors, you’re in awesome shape.

Tier #8: Architecture

While good architecture requires a book full of information + years of experimentation to get right, what we’re concerned with here is IMPROVING existing architecture. If you are starting a project from scratch and own the architecture, great, use this phase for maintenance. Otherwise, we’re looking for that sweet spot of a 1 day change for a more decoupled, easier to use & test in code system. If something takes longer than 3 days, you’ll be hard pressed to merge it back in and not inconvenience other developers… unless it’s very little code.

Milestones

1. Tight Factories: Any part of your application which takes outside data into it’s system, such as external JSON/XML as well as user input, needs to be further hardened. DRY the code, layer with #moarUnitTests. Form a convention on what happens when parsing/decoding fails; do you throw errors or return null and log them, thus passing the burden of handling null to your system? Decide as a team.
2. Fault Tolerant Services: Whether to a back-end, an external call to JavaScript in a host page, or an ad library… if it’s not your code, it’s a service. Make sure you wrap that with a Proxy that can NOT explode, and logs everything that went wrong. That extra 20 minutes pays off mad dividends.
3. MVC/MVP/MVVM/YourMom/SC/PV/PM: As a team, pick one an over arching architecture pattern and stick with it for new code. I like Supervising Controller, while others of my front-end  ilk like Presentation Model. A lot of JavaScript web frameworks follow more of a Passive View. The only right choice is team consensus & comfortability. Then endeavor as a team to get certain parts moving in that direction. If there is old code, and you’re currently working on it, see if I can convert in less than a day to make more congruent with the rest of the architecture.
4. DRY: If none of the above can be improved, simply making code more DRY is a good fall back task to more unit test coverage.
5. TODO/FIXME/KLUDGE/HACK: Do a find all in the code. If you see those, fix them. #fixBrokenWindows

Successful Exit

You never really exit Tier #8; in fact you tend to loop back to either 7 or 6 and 7 and then back to 8. However, if you find yourself working on new features, or fixing bugs with no other drama and the rest of your team is doing the same… then you’re in epic shape.

Conclusions

As you can hopefully see, my priority list helps keep you focused on delivering value to those that matter quickly. Good software development is iterative. Earning trust is also iterative; you don’t take people’s money and disappear for 6 months (that’s called good Capitalism via Waterfall). This whole list, while referring to software development, is all about relationships with people. Excluding code review, your challenge as a leader is delegating the tasks in each tier to divide & conquer, mitigating conflicts, and solving hard software problems in addition the rest of your responsibilities.

Each tier builds upon the former all the way down the line. While deep in the bowels of fixing explosions in Tier #6, I’m still continuing to build meaningful relationships in Tier #3.

Remember:

1. Report: Know your true boss and what will make her happy.
2. Understanding: Listen, learn about the company, the people, and dive into reading the code.
3. Trust: Earn trust by providing immediate value.
4. Lead: Take the initiative and move the team forward. Delegate, divide, conquer.
5. Build: Make the build fast, easy, and capable of being duplicated if need be.
6. Explosions: When things go awry, you need to immediately know where and why. Prevent fire drills.
7. Diagnostics: Get good unit test coverage, integration tests, automate your builds, and build any custom diagnostic tools needed.
8. Architecture: Decide on a direction/framework, and continue to nurture the code, and developers, in that direction. Loop back to 6 & 7 if need be.

Title photo by Ewan Monro is under a Creative Commons – ShareAlike Attribution license.

Refactoring is the discipline of applying a multitude of small, low-risk techniques to a code base in order fix and improve it. While corroborated by the software community, employing such techniques in a consulting context can be challenging because people are involved, often in a negative situation.

You need 2 weapons to win the refactoring battle. First, you need to understand what refactoring techniques are at your disposal and how to implement them. Below, I’ve listed the core ones I see needed time and time again. Second, you need to have a plan on how you engage the client company and their employees to allow you to do the first. That’s covered in the next article.

I’ve talked about how you do various parts of these initiatives in previous articles. What I want to talk about today is 1 of the 2 things: The core things you need to be concerned about in refactoring. In the next article we’ll talk about a prioritized plan you should follow when engaging a client where refactoring is needed. These are aimed at being used in the worst situations, but can provide positive benefits in benign or benevolent situations as well.

You should be able to take this blog post and the next, and from them both progressively improve a poor quality code base as well as engage a challenging client amongst challenging circumstances.

Note On Languages

I’ve intermingled JavaScript, ActionScript, and Lua to help provide a variety of examples, show this list is technology agnostic, and provide corroboration of techniques across technologies. That and I miss coding Lua since I’ve been so busy and needed an excuse. This does have a strong focus with front-end languages, namely those which run in a browser.

Nomenclature

Factory/Decoder/Parsing: Taking any kind of data, such as JSON or XML, and converting  into something you need it for. This could be as simple as accessing properties on it to converting it to a completely different type of object, or even creating new objects from it.

Coding Conventions

• Factory Errors vs. Null: Below, I’m using both error and null. Error means if a Factory/function/decoder fails in anyway to understand its data, you throw an error. This helps in unit testing, and expose errors early in the weakest part of a front end application; those that utilize non-strongly typed data. Optionally, when you find a parsing error, you return null instead. Consumers of the Factory must test for null, but you mitigate runtime exceptions and expose faulty consumers. I like using both, but it’s a lot of work to be sure.
• Don’t Create Grenades: Regardless of language, you shouldn’t create grenades. This means don’t use throw/error. Instead, dispatch a custom error event that is opt-in. Consumers shouldn’t have to worry about the code they’re using bubbling up problems to their area of worry unless they’ve opted into those concerns. ActionScript, JavaScript, and Lua also don’t have a strongly typed ways to verify with the compiler that these contracts have been met, unlike Java’s throwable. Thus, don’t throw, inform to those who wish to know. Log regardless.
• Factory vs. VO Self Parsing: Some like Factory’s to parse external data (JSON/XML, etc.) into ValueObjects for an increased likehood of DRY code (shared parsing code that’s easier to unit test). Others like ValueObjects to serialize/deserialize themselves to reduce coding overhead as well as make the API easier to use. I’ve used both below, but I’ve found this is usually a team decision and also depends on how complex your VO’s are.
• Model vs. Command vs. Remote Proxy: From architecture perspective, some people prefer to have a Model handle Application Data, and a Command/Controller/Presenter handle remote Service calls to update that data. Some prefer wrapping both inside of a Remote Proxy (basically a Model that has serivce(s) inside it), and allowing Controllers/Mediators/Presenters/ViewControllers to make calls on those Remote Proxies. I use both Model & Commands below, but no Remote Proxies. It’s up to you and your team which you think is best. If you’ve gotten this far in the discussion, you’re clearly better off than most. The point here is solve for Model and/or Application logic encapsulation.
• try/catch: I use try/catch liberally. Developers concerned about performance, such as game developers or those using complicated parsing algorithms should take note the significant performance cost of try/catch as well as liberal use of ExtractMethod. This article assumes the code is in bad shape and you/your team needs to refactor it over many months to ensure your team can prevent fire drills, meet milestones, and start to build a firm foundation. If the code base has the following problems outlined in this article, your first order of business should be fixing them first before you start optimizing. If you really need performance, just use unit tests instead and pray.
• Singletons: While not a replacement for global variables, and generally frowned upon, well written ones are a good first step if they have access control and utilize strong-typing. (ex Model).

Refactoring Basics

Improving existing code can be done in 3 ways: handling exceptions, using a good architecture, using strong-typing if available, and following refactoring paths. The reason you use refactoring, especially in a consulting/contracting context with existing code bases is that you’re not allowed to rewrite them from scratch. Thus an unwritten bequeathment of responsibility occurs between the code base and you: it now becomes your problem. Its failings become your failings. The insecurity it gives your client now has them project that insecurity, and responsibility to remedy it, onto you.

I’m assuming you’ve already done a code review by this point to ensure you, or your firm, want to even get involved. If you don’t but are still here, it’s probably because they’re paying you a lot of money to wallow in their mess. In that case, welcome to the suck.

The original definition of refactoring, referring to Martin Fowlers here, is making a small, positive change that has low inherent risk. This is done to ensure you don’t break anything. The theory is, over time if you make enough positive changes, you’ll make the whole code base positive.

Life is more complex than that, but the point here is that you use refactoring to affect positive change without breaking the code and looking like an idiot in front of your client and ticking off their customers. You do not make large, sweeping changes to the code base, even if they are needed. Take it slow and steady, 1 little change at a time. Some of the examples below are small (such as using strong-typing in place of Object and *), and some are larger (such as modifying your Model layer) are larger. Sometimes such changes you need help in tackling because it’s sphaghetti code; team refactoring can be invigorating and you get a lot more done, so don’t think you have to do this on your own.

When in doubt, make a small, positive change. If you take more than 3 days to make a change, abort.

Exceptions

Your first priority in refactoring should be handling exceptions or errors. It’s ok if you see how sausage is made in the meat factory, but it’s not ok if your client does. You can turn explosive bedlam into a controlled spectacle. That’s right, things breaking can be made into looking like your in total control. Magic isn’t magic; it’s sleight of hand through distraction.

“Look at this pretty logging window created by our company to handle such situations. All errors are now known to us, when and where they happen. This awesome ability to report said errors amongst your staff, not just QA, but you, your customers… everyone, even while in production! No surprises or fire drills here… ALL at no extra charge.”

But how do we get there? Let’s start at bottom.

A lot of programming languages execute functions or methods in 2 modes: protected or omg-it-might-blow-up-we’re-hardcore mode. JavaScript/CoffeeScript, ActionScript, and Java for example use try/catch. Ruby uses begin & rescue. Python uses try/except. Lua uses pcall. Most languages have various ways to ensure that if code explodes, it’s done so in a controlled fashion. Additionally, some have global exception handling as well.

Exceptions are the first area of uncontrolled chaos that must be contained. No controlled refactoring can take place without tackling these areas first.

Architecture

Architecture comes into play for large code bases, although, using it for small code bases can help you learn (albeit hard to appreciate as it’ll often get in your way of getting r done).

Architecture refers to how an application is built. It’s usually an amalgamation of design patterns used in a common way. For the sake of this article, we’re using architecture in a small sense of the word in helping move parts of the code to be more encapsulated, make things that break easier to identify, test in isolation, that sort of thing. While references to MVC/MVP/MVVM can get really esoteric and subjective, we’re not concerned with that.

What you need to verify with defining “good architecture” for you and your team is how it works, agree on approach, and ensure it helps you test things in isolation. If y’all agree, can be independently productive, and if something breaks you know where… that’s good architecture. Don’t get hung up on the definitions, get hung up on the contract on how things talk to each other, and that your team all agrees on that contract. This’ll come into play later in the next article regarding team synergy.

Strong Typing

Not much to say here. Don’t use Object/*/Dictionary. If you do, wrap it with a strongly typed API or unit tests. Putting the burden on the consumer of those objects leads to lots of code. Lots of code == bad.

Don’t do this:

var person:Object = {};
person.firstName = "Jesse";
person.lastName = "Warden";

Do this:

class PersonVO
{
   public var firstName:String;
   public var lastName:String;
}

var person:PersonVO = new PersonVO();
person.firstName = "Jesse";
person.lastName = "Warden";

When you don’t have strong-typing (JavaScript/CoffeeScript/Lua), #moarUnitTests. For JavaScript use jshint, jslint, and annotations that various frameworks use to infer type like Google’s Closure compiler for great justice.

Refactoring Paths

Beyond the suggestions below + mentioned resources, you have to use your own intuition. Refactorings on their own are good but when done as a team effort in strategic areas, you can make greater headway, earn more trust from your client, and do more “relevant” refactoring.

There are some things you’ll know are right such as investing in a good GUI logger, making friends with IT, etc. Others, on what to fix first, how to support dual architectures in some areas, and how to portray transparency to your client… some of those are just experience. When in doubt, go with your gut. The less code of the choices, the better.

A good refactoring path allows you the ability to code right now, satisfy non-programmers for trust earning, with assurance you havenâ€t coded yourself into a corner. It’s like a good marriage: compromise.

You’ll lose some battles. The goal is to win the war.

You’ll have detractors such as who don’t have their Code License; knowing the rules before breaking them… or some who are just afraid. Some are ivory tower zealots who aren’t punished for getting nothing done (some are rewarded). Some have emotional scars from attempting to fix things, and are hesitant to do what’s right. This is usually when they know the value but cannot effectively articulate it to stakeholders (this is called a “software developer”). Some are just insecure and don’t believe in their own refactoring ability and thus hold you back as well (low D on DISC). Some think you’re full of it.

Refactoring is temporal. You are creating a positive change to last for awhile… but not forever. It’s ok to refactor something, then refactor it again later as long as you’re actually making an improvement upon a problem. If a ship is taking on water, the first thing you do is plug the holes with wooden spikes. Later, when the French stop firing at you and your hangover is gone from drinking all the wine you found on their now apprehended ship, you can plug the holes proper with a leather & tar mixture. Then once in dry dock, replace the planks.

Architecture is not temporal… but can be as well. You’re supposed to establish rules and guidelines on how you approach a code base. Sometimes, however, you can jury-rig a solution to hit some deadline, or get a build out the door for some managerial milestone. Later, you can re-assess. Sometimes, you’re initial hack is controlled; meaning you are writing throwaway code on purpose. In doing so, you can make it easier to fix later.

Architecture is generally decided upon by the team, and you move forward for the length of the project on it.

Refactoring is a strategy that can change daily.

Step #1: Exceptions

Case: Service layer has 3 failure points: entry, error, and exit parsing.
Solution: Validate post data, log error, wrap parsing/factory/decoding.
Language: JavaScript using AmplifyJS

Bad Code:

amplify.request.decoders.appEnvelope =
    function ( data, status, xhr, success, error )
    {
        if ( data.status === "success" )
        {
            success( data.data );
        } else if ( data.status === "fail" || data.status === "error" )
        {
            error( data.message, data.status );
        } else {
            error( data.message , "fatal" );
        }
    };

amplify.request.define( "decoderExample", "ajax", {
    url: "http://server.com/service/doSomething/",
    type: "POST",
    decoder: "appEnvelope"
});

amplify.request({
    resourceId: "decoderExample",
    success: function( data )
    {
        data.foo; // bar
    },
    error: function( message, level )
    {
        alert( "always handle errors with alerts." );
    }
});

Refactored Code:

/*
Our decoder function is now:
1. shielded from bad data
2. assumes the response not well formed from the get go
3. logs each parsing error separately for easier diagnosis
*/

// modified appEnvelope decoder function
function ( data, status, xhr, success, error )
{
    try
    {
        if(data == null || data == "")
        {
            error("Decoding error in parsing data.");
        }
        else if(data.status == null || data.status != "")
        {
            error("Unknown status.");
        }
        else if(data.message == null || data.message != "")
        {
            error("Uknown message.");
        }
        else if ( data.status === "success" )
        {
            success( data.data );
        }
        else if ( data.status === "fail" || data.status === "error" )
        {
            error( data.message, data.status );
        }
        else
        {
            error( data.message , "fatal" );
        }
    }
    catch(e)
    {
       error("Decoding error.");
    }
};

/*
Notice we:
1. Validate our requestData (you could do more than a null check) before making an actual service call.
2. Additionally, we log the failed request with the Service name and reason for easier diagnosis in a larger application.
*/

if(requestData != null)
{
    amplify.request({
        resourceId: "decoderExample",,
        data: requestData,
        success: function( data )
        {
            data.foo; // bar
        },
        /*
        Our request error handling now has:
        1. a log, vs. an alert, for logging our error
        2. a common logging signature for easier diagnosis in a larger application
        */
        error: function( message, level )
        {
            console.error("MyService::error, message: " + message + ", level: " + level);
        }
    });
}
else
{
    console.error("MyService::error, requestData is null.");
}

Case: Null values in GUI. View/GUI must assume data is not always good; must handle null without exploding.
Solution: Check for null using if/then.
Language: ActionScript 3

Bad Code:

myTextField.text = person.name;

Refactored Code:

/*
We now:
1. check for a null VO first
2. if it is in fact null, we have a visual, conventional way of displaying null values w/o exploding.
3. if a property of the VO is null, that'll display as normal (in this case as an empty String)
*/

if(person)
{
   myTextField.text = person.name;
}
else
{
   myTextField.text = "???";
}

Case: Global Exception Handling
Solution: Add global handler that logs errors away from users to see.
Language: ActionScript and JavaScript

Refactored ActionScript Code:

package
{
   import flash.display.Sprite;
   import flash.events.Event;
   import flash.events.UncaughtErrorEvent;

   public class ErrorHandling extends Sprite
   {
      public function ErrorHandling()
      {
         super();
         addEventListener(Event.ADDED_TO_STAGE, onAdded);
      }

      private function onAdded(event:Event):void
      {
         loaderInfo.uncaughtErrorEvents.addEventListener(UncaughtErrorEvent.UNCAUGHT_ERROR, onUncaughtError);
      }

      private function onUncaughtError(event:UncaughtErrorEvent):void
      {
         trace("Uncaught Error: " + event);
         try
         {
            // note, fails in Asyncronous errors
            throw new Error("stack trace creator");
         }
         catch(error:Error)
         {
            trace(error.getStackTrace());
         }
      }
   }
}

Refactored JavaScript Code:

// via http://stackoverflow.com/questions/951791/javascript-global-error-handling
//
// more techniques here for Opera/Safari older versions
// http://stackoverflow.com/questions/645840/mimic-window-onerror-in-opera-using-javascript
//
// also note various browsers pass different arguments, and some suggest
// handling existing handlers if they exist
// https://developer.mozilla.org/en/DOM/window.onerror
//
// also note that the error in some browsers will still occur unless you handle it
// a certain way; here we're returning true from the error handler to do so.

window.onerror = function()
{
    if(arguments && arguments.length && arguments.length > 0)
    {
        var logStr = "";
        var len = arguments.length;
        for(var index = 0; index < len; index++)
        {
            logStr += "\t" + arguments[index] + "\n";
        }
        console.error("Global Error:\n" + logStr);
    }
    else
    {
        console.log("Global Error");
    }
    return true;
};

Step #2: Architecture

Case: Encapsulation of statefull, Model data.
Solution: Encapsulate Setting of Model Data to single place (DRY)
Language: Lua in Corona SDK

Bad Code:

_G.score = 0

local scoreText = display.newText()
function updateScoreText()
   scoreText.text = _G.score
end
updateScoreText()

local powerUp = display.newImage("powerup.png")
powerUp.name = "powerUp"

local enemy = display.newImage("enemy.png")
enemy.name = "enemy"
function enemy:collision(event)
   if event.phase == "began" then
      if event.target.name == "bullet" then
         _G.score = _G.score + 1
      end
   end
end
enemy:addEventListener("collision", enemy)

local ship = display.newImage("ship.png")
function ship:collision(event)
   if event.phase == "began" then
      if event.target.name == "powerUp" then
         _G.score = _G.score + 1
         updateScoreText()
         return true
      end
   end
end
ship:addEventListener("collision", ship)

function onTouch(event)
   if event.phase == "began" then
      local bullet = display.newImage("bullet.png")
      bullet.name = "bullet"
      return true
   end
end

Runtime:addEventListener("touch", onTouch)

Refactored Code Round 1:

--[[
Notice we've added an addScore method to:
1. have a central place everyone can update the model data
2. make it easier to identify WHO is calling this add function
3. ensure we never forget to update our Text Field with the latest value like in the original code
]]--

function addScore(amount)
   _G.score = _G.score + amount
   updateScoreText()
end

-- Fixing our enemy collision handler to now call our encapsulated method
function enemy:collision(event)
   if event.phase == "began" then
      if event.target.name == "bullet" then
         addScore(1)
      end
   end
end

Refactored Code Round 2:

--[[
Now we use a more generalized Observer pattern, and dispatch an event
when the value changes. The system is free to listen to this event
and react however it needs to. This allows the GUI to change w/o worrying
updating the model changing behavior to compensate for a changing GUI API.
]]--

function addScore(amount)
   _G.score = _G.score + amount
   Runtime:dispatchEvent({name="onScoreChanged", newScore=_G.score})
end

-- we now can update more GUI parts as they become needed
function onScoreUpdated(event)
   updateScoreText(event.newScore)
end
Runtime:addEventListener("onScoreChanged", onScoreUpdated)

-- notice this includes encapsulated GUI controls as well;
-- they can just listen in on the Event Bus.
-- Here, we have a Level Progress bar that listens to the score change
-- to visually indicate how far along the user is until they level up.
require "com.company.project.controls.ProgressBar"

LevelUpProgressBar = {}

function LevelUpProgressBar:new()

   local bar = ProgressBar:new({width = 100, height = 60})
   bar.levelMax = 1

   function bar:onScoreChanged(event)
      self:setProgress(event.newScore, self.levelMax)
   end

   function bar:onLevelMaxChanged(event)
      self.levelMax = event.newLevelMax
   end

   Runtime:addEventListener("onLevelMaxChanged", bar)
   Runtime:addEventListener("onScoreChanged", bar)

end

return LevelUpProgressBar

Case: Access Control for Statefull Model Data Using Application Logic (English: you need to update some model data, and multiple parts in your application need to do this). aka, removing global variables.
Solution: Utilize Proxy Pattern or Command Pattern for single access (DRY), this ensures there is only 1 way to update your model data, inputs are validated. This makes it easier to debug who is calling/invoking it, and what data they are passing, as well as ensuring those who need to know about the change are informed.
Language: ActionScript

Bad Code:

var firstName:String             = firstNameTextInput.text;
var lastName:String              = lastNameTextInput.text;
var birthdate:Date               = birthdateControl.value;
var myPersonVO:PersonVO          = new PersonVO(firstName, lastName, birthdate);
MyStaticModel.person             = myPersonVO;
MyStaticModel.person.lastName    = "McTaggart"

Refactored Code:

// First we create a factory class to test our creation & validation in isolation.
// This is also easier to write unit tests for. It's also DRY in that all classes
// who need to create PersonVO's and validate them are using the same code to do so.

class PersonFactory
{
   public static function getPerson(firstName:String, lastName:String, birthdate:Date):PersonVO
   {
      if(firstName == null || firstName == "")
      {
         throw new Error("firstName cannot be null nor an empty String.");
         return;
      }

      if(lastName == null || lastName == "")
      {
         throw new Error("lastName cannot be null nor an empty String.");
         return;
      }

      if(birthdate == null)
      {
         throw new Date("birthdate cannot be null.");
      }

      return new PersonVO(firstName, lastName, birthdate);
   }

   public static const validateLastName(lastName:String):Boolean
   {
      if(lastName != null && lastName != "")
      {
         return true;
      }
      else
      {
         return false;
      }
   }
}

// Second step, create a change event that those who need to know about a changing
// personVO in the model can be made aware of.

class PersonModelEvent extends Event
{

   public static const PERSON_CHANGED:String = "personChanged";

   public function PersonModelEvent(type:String)
   {
      super(type, false, true);
   }

}

/*
Third, create a Model class Singleton that:
- dispatches change events when it's internal person variable is changed, or modified
through accessor controls
- validates creation & changes
NOTE: If classes need to operate on PersonVO itself, create additional methods to
operate on the internal PersonVO to ensure proper change events are dispatched.
NOTE: For those who wish to remove Singletons, create as an instance, and inject the dependencies,
whether via a DI framework such as SwiftSuspenders/Guice/Spring, or manually via
getter/setters for those classes who need instance access.
*/

class PersonModel extends EventDispatcher
{

   private var _person:PersonVO;

   public function get person():PersonVO { return _person; }
   public function set person(value:PersonVO):void
   {
      _person = value;
      dispatchEvent(new PersonModelEvent(PersonModelEvent.PERSON_CHANGED));
   }

   public function PersonModel()
   {
   }

   public function setNewPerson(firstName:String, lastName:String, birthdate:Date):void
   {
      // first, validate data is good, don't want to pollute our model
      var personVO:PersonVO;
      try
      {
         personVO = PersonFactory.getPerson(firstName, lastName, birthdate);
         person = personVO;
      }
      catch(error:Error)
      {
         trace("PersonModel::setNewPerson error: " + error);
      }
   }

   public function updateLastName(lastName:String):void
   {
      if(person)
      {
         if(PersonFactory.validateLastName(lastName) == true)
         {
            person.lastName = lastName;
            dispatchEvent(new PersonModelEvent(PersonModelEvent.PERSON_CHANGED));
         }
         else
         {
            trace("PersonModel::updateLastName, failed because the lastName '" + lastName + "' is invalid.");
         }
      }
      else
      {
         trace("PersonModel::updateLastName, failed because the current person is null.");
      }
   }

   private static var _inst:PersonModel;

   public static function get instance():PersonModel
   {
      if(_inst == null)
         _inst = new PersonModel();

      return _inst;
   }
}

Refactored Code 2:

/*
In the case of need of many needing to affect the Model, and there is no
desire to all Models/Proxies to have public methods accessible by others,
you can use the Command pattern. Additionally, this solves the use case
where multiple Models are needed to be accessed and/or modified. Finally,
we also handle asynchronous use cases where you need to update a Model(s)
based on a server response. Notice how each step is validated, and a log is
produced if any step fails. You need to know WHERE it failed and WHY.
Also, no rollback support in the following.
*/

class CreatePersonEvent extends Event
{
   public static const CREATE_PERSON:String = "createPerson";

   public var firstName:String;
   public var lastName:String;
   public var birthdate:Date;
   public var personModel:PersonModel;
   public var organizationModel:OrganizationModel;

   public function CreatePersonEvent()
   {
      super(CREATE_PERSON);
   }
}

class CreatePersonCommand extends AsynCommand
{

   // injected dependencies; you could use a DI framework,
   // wrap Command class creation with these, or simply pass
   // in through the Event payload like the below shows.
   private var personModel:PersonModel;
   private var organizationModel:PersonModel;
   private var createPersonService:RESTFullCreatePersonService;
   private var personVOToCreate:PersonVO;

   // Create a PersonVO, set on the PersonModel,
   // and ensure the OrganizationModel is updated with the
   // new person once the server has verified it's creation.
   public function execute(event:CreatePersonEvent):void
   {
      try
      {
         personModel = event.personModel;
         organizationModel = event.organizationModel;
         personVOToCreate = PersonFactory.getPerson(firstName, lastName, birthdate);
         if(personVOToCreate != null)
         {
            createPerson()
         }
         else
         {
            throw new Error("ERROR: CreatePersonCommand::exeucte, PersonFactory returned null.");
         }
      }
      catch(error:Error)
      {
         trace("ERROR: CreatePersonCommand::execute, error: " + error);
         finish();
      }
   }

   private function createPerson():void
   {
      createPersonService = new RESTFullCreatePersonService();
      createPersonService.addEventListener("success", onCreatePersonSuccess);
      createPersonService.addEventListener("error", onCreatePersonError);
      createPersonService.createPerson(personVOToCreate);
   }

   private function onCreatePersonError(event:Event):void
   {
      trace("ERROR: CreatePersonCommand::onCreatePersonError, event: " + event);
      finish();
   }

   private function onCreatePersonSuccess(event:Event):void
   {
      // server has successfully created PersonVO, let's update ours with what
      // the server sent back to ensure we now have a proper PersonVO.ID set
      // by the server
      if(createPersonService.savedPersonVO != null)
      {
         personModel.person = createPersonService.savedPersonVO;
         organizationModel.addNewPerson(personModel.person);
      }
      else
      {
         trace("ERROR: CreatePersonCommand::onCreatePersonSuccess failed, server sent back a null savedPersonVO.");
      }
      finish();
   }

}

Step #3: Strong Typing

Case: Using loose typing/variants/Objects/*, resulting in loss of compiler time checking and thus errors that only appear at runtime.
Solution: Use strong-typing.
Language: ActionScript

Bad Code:

/*
Notice:
- personVO.lstName is a mispelling, but no error will be raised by the compiler.
- no error will be raised by the updatePerson function as Object is dynamic,
and lastName will be created and set on the personVO Object.
- no error will be raised if you pass something other than a personVO to updatePerson
except for runtime errors
*/

var personVO:Object = {};
personVO.firstName = "Jesse";
personVO.lstName = "Warden";

function updatePerson(person:*, newNameFromStringBlock:String):void
{
   var nameArray:Array = newNameFromStringBlock.split(" ");
   person.firstName = nameArray[0];
   person.lastName = nameArray[1];
}

Refactored Code:

/*
Notice:
- our "lstName" will be caught by the compiler
- our updatePerson function ensures only a PersonVO is accepted to be operated on. If not,
our compiler will let us know.
*/

class PersonVO
{
   public var firstName:String;
   public var lastName:String;
}

var personVO:PersonVO = new PersonVO();
personVO.firstName = "Jesse";
personVO.lstName = "Warden";

function updatePerson(person:PersonVO, newNameFromStringBlock:String):void
{
   var nameArray:Array = newNameFromStringBlock.split(" ");
   person.firstName = nameArray[0];
   person.lastName = nameArray[1];
}

Case: Service layer has no input validation, is hard to test, and has no error reporting. Burden is on class user to wrap in try/catch as well as parse server response including knowing business logic. Finally, asynchronous loader is not a class member variable, thus potential memory leak + harder to debug.
Solution: Create a Service class that is easy to use, validates inputs, and logs errors. Encapsulates business logic.
Langauge: ActionScript

Bad Code:

class CreatePersonService extends EventDispatcher
{

   public var loader:URLLoader;

   public function CreatePersonService()
   {
      super();
   }

   public function createPerson(person:PersonVO):void
   {
      var loader = new URLLoader();
      loader.addEventListener(Event.COMPLETE, onComplete);
      var req:URLRequest = new URLRequest("http://someserver.com/restful/api/");
      req.data = person.toJSON();
      loader.load(req);
   }

   private function onComplete(event:Event):void
   {
      dispatchEvent(new Event("success"));
   }
}

var service:CreatePersonService = new CreatePersonService();
service.addEventListener("success", onSuccess);

function onSuccess(event:Event):void
{
   var json:Object = JSON.decode(service.loader.data);
   var person:PersonVO = new PersonVO(json.firstName, json.lastName, json.birthdate);
}

Refactored Code:

/*
Note:
- createPerson validates you gave it a valid PersonVO.
- all errors within class are opt-in, no throw's. User has to register event listener to hear; #dontCreateGrenades
- class assumes single-concurrency if possible, kills previous load call before proceeding
- listens for all errors, and responds with 1 error with more detail logged if needed; simplifies API
- wraps actual call to verify SecurityError isn't thrown and if it is, it's logged w/ opt-in error
- uses united tested Factory for DRY parsing and assumes
- assumes Factory can fail, and reports it as such
- result in the form of a strongly-typed ValueObject in a read-only property to ensure proper API usage
*/
class CreatePersonService extends EventDispatcher
{

   private var _savedPersonVO:PersonVO;
   private var loader:URLLoader;

   public function get savedPersonVO():PersonVO { return _savedPerson; }

   public function CreatePersonService()
   {
      super();
   }

   public function createPerson(person:PersonVO):void
   {
      _savedPersonVO = null;

      if(person == null)
      {
         onError("You cannot pass in a null person to create.");
         return;
      }

      if(loader == null)
      {
         loader = new URLLoader();
         loader.addEventListener(IOErrorEvent.IO_ERROR, onIOError);
         loader.addEventListener(SecurityErrorEvent.SECURITY_ERROR, onSecurityError);
         loader.addEventListener(Event.COMPLETE, onComplete);
      }
      else
      {
         try
         {
            loader.close();
         }
         catch(error:Error)
         {
            // only exception that is ok to swallow
         }
      }

      try
      {
         var req:URLRequest = new URLRequest("http://someserver.com/restful/api/");
         req.data = person.toJSON();
         loader.load(req);
      }
      catch(error:Error)
      {
         onError("CreatePersonService::createPerson, error: " + error);
      }
   }

   private function onIOError(event:IOErrorEvent):void
   {
      onError(event.text);
   }

   private function onSecurityError(event:SecurityErrorEvent):void
   {
      onError(event.text);
   }

   private function onComplete(event:Event):void
   {
      try
      {
         _savedPersonVO = PersonFactory.parsePersonFromJSON(loader.data);
         if(_savedPersonVO != null)
         {
            dispatchEvent(new Event("success"));
         }
         else
         {
            onError("CreatePersonService::onComplete, factory returned a null PersonVO.");
         }
      }
      catch(error:Error)
      {
         onError("CreatePersonService::onComplete, parsing error: " + error);
      }
   }

   private function onError(errorString:String):void
   {
      trace("ERROR: CreatePersonService::onError: " + errorString);
      dispatchEvent(new Event("error"));
   }
}

Step #4: Fine Tuning

If you made it this far, and have managed to continue to maintain the above, congratulations! This stuff is icing on the cake. You can continue onto smaller scope refactorings, as well as continuing to increase your unit test coverage.

Final Tips

1. When casting, ensure result is not null before using. If null, log the casting failure.
2. For Flash Player, set ExternalInterface.marshallExceptions = true if using ExternalInterface
3. Log all errors
4. Code Review. Often. Weekly. Whatever, pick a schedule.
5. Object / * / Dictionary == if you can’t avoid, wrap with unit tests
6. Remember: small, low-risk changes.
7. TODO was invented for a reason.
8. If you haven’t committed to source control for 3 full days of working, abort and just check into a branch for later revisiting/reference.

Conclusions

Remember, the most important refactoring you can possibly do is reading the code base for 1 hour a day, no more. Just 1 person. This is has more positive impact than good unit test coverage. Daily code reviews, even in isolation, are extremely important. The earlier in the project life cycle, the better.

From that, you can make small, low risk changes. Keep track with TODO’s. Breathe, Rome wasn’t fixed in a day, and a pile of rubbish wasn’t fixed in one either.

For further, positive refactorings you can check an older list by Martin Fowler, and this book has a ton of wonderful ones + tests as well. While a Code Review has decreasing value the more people you add in terms of defects found, the ability to learn & make positive suggestions for architecture are wonderful. If you’re alone, use codereview.stackexchange.com.

In the next article I’ll show you how to get help with the above… and permission.

What is Consulting?

Consulting in the Flash/Flex world usually consists of 3 tasks that may be related:

1. Offer your architecture expertise.
2. Offer your code mechanic expertise.
3. Augment an existing team.

For #1, companies either want you to architect a project, give professional feedback on a suggested/signed off architecture done by another firm (usually to give a stakeholder corroborated evidence), or are having scalability problems and want your advice.

For #2, things aren’t going well and they want you to fix it. No, not re-write it, fix it.

For #3, they want you to augment an existing team. Some firms do this because the pay + finder fee is good money. Other firms do not because you can sometimes be put into situations where you’re setup to fail since you may be smart enough to fix it, but you’re not in charge, thus you cannot do so.

#3 is how I got into consulting, staff augmenting an existing team. While the #1’s were fun, they were few and far between; usually big companies would rather pay lots of money to fix things vs. pay what it costs to do it right. This isn’t cynical, this is fact.

Why Get Into Consulting?

The reason is often simple: more money. More money than full-time/salaried/W2 work. More money than freelance/contracting.

Other reasons include working with really smart developers, learning about how Enterprise companies build & sell software,  learning about how to work in and manage large software teams… TONS of opportunities to just learn on a variety of subjects. Sometimes people havenâ€t worked on extremely large codebaseses. Itâ€s fun to take all the theory and see what it actually does in the real world, with real people.

Me personally, I like travelling, meeting new people, and seeing how different companies work.

Getting Into Consulting

You have a few options listed in order of ease.

1. Find a firm, become an employee.
2. Find a firm, become a sub-contractor.
3. Become an independent contractor.

If you find an existing firm, especially when your country isnâ€t in a recession, this is the easiest way. Whether large like Deloitte and Accenture, to smaller firms (more focused on Flash/Flex) like Roundarch and Universal Mind. Regardless of skill level, while youâ€ll be sold to the client as a “consultant”, but larger firms will ensure a senior is on the project unless youâ€re merely staff augmentation. Joining as an employee usually is easier because youâ€re cheaper tax wise/cost wise to the firm, and youâ€re more versatile to them. Meaning, since youâ€re on payroll, they can pay the same rate to fix a huge clientâ€s code base as well as working on your firms intranet when in between clients.

If youâ€re the freelance type, or typically like getting a variety of clients (and often potentially making more money), becoming a sub-contractor is another option. This is how smaller firms get off the ground, and is common place even in larger firms. While you usually cannot do mundane work, this is often easier for smaller firms tax wise, thus itâ€s an option as well. If the firm has no current clients, you wonâ€t get any work though. A W2 will get paid for the 2 week downtime, you wonâ€t. Hustling during consulting engagements is usually harder than hustling during contracting ones.

If you have enough contacts or typically do only Enterprise type software (LiveCycle, BlazeDS, Java/Spring/Hibernate), then going the independent route is also an option. Basically, start your own company, and start working directly with clients. This is the hardest, even if you do Enterprise software, because most larger clients only work with “companies”. Just because you have a company legally filed on paper doesnâ€t mean youâ€re a “company”. Often theyâ€ll want multiple developers on a whim, liability insurance, and multiple large clients on your track record/portfolio. Iâ€m personally still learning the sales for this, but it seems networking tends to help a lot/the most.

My advice, seek out people you know from the community at Roundarch, Universal Mind, or Cynergy, and make sure youâ€re known to be available, even if they donâ€t currently have any openings.

Skills

Being a consultant involves a lot of things a normal software developer doesn’t do. Even if you’re a salaried/W2 employee, these are still required:

1. leadership
2. large scale architecture
3. travel on-site to client’s location
4. expense reporting
5. meeting clients and their stakeholders
6. offering professional, 3rd party opinions
7. dressing nice
8. attending meetings for a company you don’t work for
9. interviewing/hiring members for your team and/or the company’s on the company’s behalf

All the standard stuff like team management, working with the company’s stakeholders, and tracking your hours are there too. You also donâ€t always do all the above mentioned; sometimes just one. Itâ€s just those arenâ€t normal required in traditional freelancing (excluding #3 and #5). Let’s break down what these skills mean.

Leadership

Unless your role is for staff augmentation, leadership is the most important skill for a consultant. You need to be able to inspire confidence in strangers you’ve just met, inspire confidence in your chosen direction & decisions, and to keep people moving on the right path.

Some leadership skills can be taught. Some people are just born with the other aspects. If you don’t know how to do this, watch & learn from those that do. Examples include raising your Charisma score. Doing one or more of the following will help:

• have good hygiene
• have clean clothes that are ironed
• dress to impress; this boosts your confidence as well. You want to look successful.
• listen: people like good listeners
• empathy: people like others who understand them. If you listen to their pains, and sound like you understand, you connect.
• be knowledgeable: if you know what you’re talking about, you’ll exude confidence when you talk. You also won’t get offended if someone disagrees and will want to hear their point of view. If you don’t know, ask/listen vs. act like you know.
• have a vision: assuming you know the companies problems, have a long term vision to fix everything. Communicating this to your colleague and your clientâ€s employeeâ€s is paramount.
• communication: you need to be an effective communicator to articulate your vision to others, and get them to follow you. Be relaxed, look people in the eyes, be confident in your delivery, and be open to listen. Using slang/ebonics/l33t in normal conversation negatively affects peopleâ€s perception of you. Be professional when you speak.
• egg shells: crush those sons of bitches. You do NOT walk on egg shells. You’re a consultant; grab drama by the neck, raise it high, and execute it. Then, move forward.
• be positive: while Andrew Dice Clay and Rush Limbaugh have gotten popular for their negative spin on things, they don’t last. Positivity is the antithesis to Entropy; that lasts, especially in people’s perception of you.
• control your emotions: software is hard. People in large groups do really dumb things, particularly large companies. Have patience, breathe, and keep your emotions in check.  Your self-control inspires confidence in your actions by others. People assume you have things under control if you’re relaxed and poised.
• win: You have to WANT to win. You need ambition to reach your goals and vision. If you have that, you’ll have the motivation to do all of the above.

Large Scale Architecture

The most common need in the Flex world is architecting how the Flex talks to the BlazeDS/LiveCycle, and how that talks to the Java, and how that talks to the client’s stuff. Often, they’ll have an existing infrastructure in place and you’ll need to decide & describe how and where to integrate technology stacks to a client’s existing infrastructure and possibly already in progress project with the existing resources, which are often in a variety of teams.

You need to know this well enough that you can cater design, development, and deployment techniques to various client needs. You need to be able to effectively articulate these to the client, the team, and ensure the tasks meet the resources currently available; meaning the client can build, deploy, and support what you’re actually suggesting to do. Thatâ€s a lot of traditionally Project Management tasks.

If you don’t know how to architect large Enterprise sized projects, specifically Flex, learn. If the back-end/middle tier isn’t your thing, partner with those who know it. Unlike learning traditional software skills, you can’t really get away with practicing as a consultant. Based on my consulting gigs people can do this all the time if they’re a salaried employee of a large company. So, if you want to get on the fast track to learn, join a consulting firm and get mentored.

Travel On-site to Client

Unless it’s staff aug, most consulting involves travelling on-site to the client’s location(s) to meet the stakeholders and team. This means donning your business casual, booking airfare & hotel, and travelling both on the weekend and during the week. Being responsible by ensuring you have ample lay over time, donâ€t get the last flight out,  arriving to the airport early, and arriving at a client site early to ensure you’ve gotten enough sleep are assumed.

For those with needy significant others and/or young children, this is challenging to do, and will determine if you do higher level consulting or not. This has forcibly paused my career which Iâ€ll defer to a later blog post.

To me, this was one of the draws I have to consulting. I like traveling to new places, meeting new people, and the lifestyle of being on the move. Being on the road is one thing that’s therapeutic to me.

If you don’t have a few thousand in the bank to cover the costs (flight, hotel, fuel, food), the firm you work for will have to front the money. Either way, you have to ensure this is tracked as reimbursed expenses for tax purposes (unless you’re salaried with the firm). The benefit of paying for these things yourself are tax write off opportunities as well as frequent flyer miles with certain airlines.

If you can use expedia.com, drive a car, and find your way around an airport, you’ll be fine. Sometimes you get to meet new people you sit next to on the plane. Yes, there are cool people in coach, but you want to strive to be in first class even if the company will only fund coach. Make sure you use your own miles program vs. the companies if you can. You aren’t paid for your travel time like lawyers, so it’s nice to have some way to offset costs; i.e. being able to work. Trying to type on your laptop in coach is torture vs. first class.

Expense Reporting

A lot of consultants, even if salaried, are required to document their time and expenses. This means documenting, usually in some web based time tracking program. Thus, you need to be aware of how much time you’re spending on tasks, what those tasks were, and how much more you think you’ll do. This can get tricky, too, when you end up in a staff aug position and basically end up running the project. Suddenly you’re holding the ball, and people are wondering why you’re billing time for meetings vs. coding… you can get into really uncomfortable, and extremely irritating and unfair situations. Examples include being the architect & mentoring company employed developers on the project, and when the UAT comes up at the end of an Agile SCRUM Sprint, you show zero User Story points completed, and people in charge question what value youâ€re providing.

If you document well, cya (cover yer arse), and have transparency with the client into what you’re spending your time on by talking to them early and often, you’ll do fine. While they often don’t plan for you to spend a lot of your time in meetings for doing architecture, as long as they’re aware that out of 4 months of billable hours, 2 months were spent helping the client align their processes to ensure they could support the app, ensure the user stories/features in the application were valid, and the design was actually capable of being built… then you’ll at least get paid.

Document your time, be aware of what you’re working on, and what you need to work on. Communicate what you’re doing for the client often.

Meeting the Client and Its Stakeholders

I like meeting new people. I like talking. I like meeting successful people and learning from them. Consulting with companies that desire your expertise teaches you a lot about software that supersedes the construction of it, but how it’s actually consumed and sold. This makes you question a lot of the commonly held beliefs by OOP Purists and other fads touted in the news. It’s awesome. You get to learn how to build software, how to fix it, how to align teams, how to prevent fire drills, why you’d even want to prevent a fire drill, how to compromise amongst silo’d departments, how itâ€s sold… the list goes on and on.

To get things done, and get bigger problems resolved (like using the wrong technology stack/methodologies/processes), youâ€ll have to meet & talk with the big wigs. If you arenâ€t comfortable talking with upper level management, having an MBA helps. If that isnâ€t your thing, find someone who is good at it, and learn. Sometimes these are either A) the only people that can move you forward and/or B) theyâ€ll great at articulating why youâ€re so effâ€d and just need to deal with it.

Bottom line, you can get the REAL story behind why the way things are, and exactly where they are going by talking to project stakeholders vs. the variety of “this is my world at this company” responses youâ€ll get from interviewing employees who arenâ€t Director level or higher.

Offering Professional, 3rd Party Opinions

Often youâ€re firm will be hired for your realm of expertise. Other times, they already have the expertise, whether internal employees or another firm, and just want your opinion as a 3rd party who isnâ€t currently involved nor has stake in the current project. They actually care what youâ€re opinion is and pay for it. This helps them confirm what they already know with an “iron clad” assessment, or perhaps challenging strongly held beliefs in a certain section of the company.

Sometimes these validations, such as:

“Yes, this other consulting firm is billing out a bunch of n00bs to you for $150/hr, and yes, youâ€re internal employee DID in fact build something amazing in 1 week what the 2 n00bs couldnâ€t do in 3 months.”

…lead to consulting engagements. Sometimes confirming what the company already knows builds trust, and thus leads to a longer term engagement.

Other times youâ€re actually hired for a less valued position such as staff augmentation, but youâ€re experience/knowledge ARE in fact beneficial the project. Thus, you need to find a way to ensure those who need to know learn about what you know. If you sucked, you wouldnâ€t be hired for your high price, thus, ensure the client gets value from you via your professional opinions.

Dressing Nice

Iâ€ve mentioned this countless times before. Clothes make the man. Women typically dress to impress other women; in this case, women need to dress to impress the client. Business casual is usually ok, although, the larger the account, the more formal you need to look. In my opinion, you CANNOT be overdressed for an engagement. If someone mentions on the side you donâ€t have to, theyâ€re either threatened, or donâ€t understand the game.

Dress to impress. If you look impressive, you must be impressive. Youâ€re thus apparently successful because youâ€re knowledgeable. This includes accessories such as the car you drive, the bag/briefcase you carry, and the business card you deploy.

Attending Meetings for a Company You Donâ€t Work For

Sometimes, especially if you end up being a shield for the rest of the team, or if you just want to learn about the lay of the land, the players, and all the drama, youâ€ll need to attend company meetings. These are often a waste of time, or things to be avoided at all costs. However, to management, THIS is their transparency to give to stakeholders at some companies. Providing attendance by your firm is often a requirement.

Either way, youâ€re involved in the project, and need to attend the meetings, and sometimes participate. Sometimes you even need to call/create meetings (OMG, the horror!). These are usually to get consensus from the team on an issue that you couldnâ€t do in SCRUM, or resolve drama, or to brainstorm on how to solve some challenging coding issue.

Interviewing/Hiring Members for Your Team and/or the Company’s on the Company’s Behalf

Sometimes youâ€re brought onto a project, and realize you need help. The company looks to you to “build it” or “fix it”; if that means more developers/designers from your firm, so be it, theyâ€ll find the budget. Getting resources can be challenging. At a smaller firm, you may have to have the resources yourself already ready to go. David Ortinau, one of my mentors on this, has helped me create a spreadsheet of people Iâ€ve met over the years. On it, I list out people Iâ€d hire (and who I wonâ€t ever hire), what their speciality is, and what the last rate I got them for was. This is because they are often working for me. Even at my firm, my partners are uber-busy, so I canâ€t immediately assume theyâ€re always available. Obviously theyâ€re my first pick to work with.

If youâ€re with a larger firm, they can often help in 2 ways. First, they can provide you additional consultants if the client has the budget for it. Secondly, they can sometimes provide resources from other firms. This is more challenging because usually the other firm will want their cut of providing a resource. This means, either your firm makes less revenue from that resource, or justifies the lack of serious profit from your dire need…. or both.

Other times, the company is looking to maintain the solution/software you/you and their team has created. This means hiring employees that work for the client. They’re responsibilities include adding features to & maintaining that software. Often, youâ€re the most qualified to hire said employees. Interviewing potential coders is a challenge & learned set of skills in and of itself.

Getting Out of Consulting

A profession that provides a significant amount of money, a huge opportunity to learn, and networking opportunities with new people & companies seems like something you wouldnâ€t ever want to leave, right?

Wrong.

Consulting has a lot of overhead on the soul. This includes the following:

• copious amounts of travel to be on-site wherever the client is. This is time away from your loved ones.
• dealing with incompetence where said incompetence cannot be fired/laid off, yet continues to actively sabotage your project and/or client relationship.
• dealing with politics that theoretically help the companyâ€s stockholders, but ensure the software team is setup to fail
• various implementations of Agile SCRUM that arenâ€t true to the tenets of SCRUM, and thus donâ€t see the benefit of it. A lot of times, this angers everyone involved in the team including the PMâ€s running it, and is just a gross feeling.
• You potentially never “love the code” youâ€re working on.
• The ultimate consulting goal of “leaving the company better than you found it” may potentially be unknowable in how to do so.
• Entropy is scientific fact that all things eventually will return to chaos. Youâ€re constantly fighting this in consulting/leading large teams regarding the code base; this can take an emotional, and spiritual, toll.
• Sometimes, companies pay you lots of money to produce code that never sees the light of day.
• Sometimes, companies pay you lots of money to code in an IDE you loathe on an OS you are unfamiliar with using a framework you hate implementing design patterns you disagree with amongst a team who doesnâ€t understand why youâ€re unhappy with the status quo.
• If things go sour, you can sometimes not get paid, or take awhile to get paid.
• Depending on the team, the complex processes involved on the surface appear to provide no value to the project and prevent developers from actually writing code since they’re in meetings or writing docs instead.

Add to that the paperwork around expenses & taxes, and itâ€s an enough to make anyone want a salaried job. A steady, consistent paycheck with easy taxes. Sometimes way less stress, too.

In most cases Iâ€ve seen a change of scenery, a long vacation, or just a different project is enough to rejuvenate even the most burnt out consultants. Other times a dive back into the W2 world is a great vacation from consulting.

Just be aware there is a huge pay scale difference between consulting and non-Enterprise salaried positions. Just because you take a salaried, full-time position at a large company because they offer comparable money & benefits doesnâ€t mean youâ€ll actually be able to use your consulting skills. There is a lot of power in not working for a company directly. You can get away with telling them off for being incompetent, explaining how to get out of the mess, and theyâ€ll thank you for it. You do that as an employee, you typically get a different reaction, one you donâ€t want.

Bottom line, this can make finding comparable employment & compensation challenging if youâ€re thinking of getting out. From a skill set perspective, usually only start-ups need someone of that caliber, and unless they have known backers, itâ€s hard for them to afford you unless they offer some serious equity.

Conclusions

Consulting is a profitable endeavor, usually involving your skills on larger projects for larger companies. You can work with various teams or simply offer your expertise, perhaps via training. Itâ€s a great opportunity to learn, meet new people, and discover the business of software and the development processes various companies use. The money canâ€t be beat, either. The easiest way to get in is to find an existing firm such as Universal Mind or Deloitte and get hired.

The skills required are more demanding that normal freelance software development. Specifically, knowing how to architect extremely large applications, having good leadership skills, and the ability to communicate complex subjects succinctly are key. These skills can be learned and practiced.

Consulting is a demanding career choice and itâ€s ok to take a break from it. Being an expert in your field requires you to be constantly researching, learning, and being on top of your game.

Keep in mind, too, you can work for a consulting firm and “just code”. This isnâ€t consulting, though.