I made a new years resolution to double my rate this year. If you take a look at the current Flex Consulting Rates, and think double or triple, you’ll have an idea of what I’m trying to do.

In the past 8 months I’ve found three challenges to reaching my goal. First, I had some misperceptions of what level of quality of software businesses want. Second, I have been distracted from the truth by the echo chamber I participate in, specifically the Twitter followers and blogs I read. Finally, and most importantly, while I’m good at marketing, I’ve completely failed in selling the value of my services.  The following lists the failings in detail with my new goals to fix those problems.

Why Double My Rate?

I’ve found there is a glass ceiling with programming rates. I figure if I find a way to break through that ceiling, then I’ll learn. You should always be learning in programming, and thus doubling my rate this allows me to learn.

Programmers Want to Create First and Foremost, Businessmen Want to Make Money First and Foremost

Any programmer who wants to be good is constantly focused on learning and improving their craft. Specifically we focus on anything, and everything that can positively contribute to ensuring we produce better code that’s more enjoyable to work with, reduces project risk, and ensures a good user experience. This includes, but is not limited to, learning new design patterns, languages & runtimes, and processes such as Continuous Integration, Agile/Scrum, and TDD.

When talking to 3 successful businessmen I know, all 3 aren’t focused on improving their craft. They are focused on making more money. My Dad is in sales and sells luxury hardware installations. My Uncle Barry is in luxury retail. My Uncle Flip is a corporate lawyer. All 3 are financially successful.  While they have different educational backgrounds, and different businesses, all 3 corroborate each other. I’ve found that other successful people, whether in their blogs, in company press releases, or public interviews all have the same primary motivation. They’ll quickly follow with others, but making money is ALWAYS #1.

I’ve spent 10 years learning how to make the best software possible. It’s not helping me make more money.

New Goal #1: Learn more about making money.

Good Enough Software

One thing I’ve noticed in my consulting over the years is that a lot of companies have an extremely low expectations for software quality & velocity compared to me and my colleagues. Many would rather purchase software made at Walmart vs. Louis Vuitton. While investing in the R in RIA has a higher return on investment (PDF), many find that simply investing in the ubiquity of Flash Player with its predictable playback is good enough.

Later, a lot of these companies realize their software has usability problems or is hard to sell. This is often where I come in; to make an existing Flex application look hot. This is backwards how you’re supposed to do software. It happens again and again because companies are rewarded through profit for good enough software. While it costs them a lot more later to implement a design, at least they DO eventually recognize the value of it.

One of the biggest challenges I’ve had in winning new engagements is educating a potential new client on what the true value of quality is vs. “good enough”, as well as justifying the cost of good design and UX. While iPhone was a game changer, Android sales are surging past it. From a consumer perspective, many would agree iPhone provides a better user experience compared to Android, yet that is not hindering Android sales success enough to prevent it from beating iPhone in total market share. Having multiple operators, multiple device types, and targeting different demographics are all the primary drivers, none of which have to do with good UX. This fact validates the “good enough” point, and makes it even more challenging for me to quantify the value of good design when it’s not a prerequisite for software profitability.

I still believe good design in software is a must IF you believe in quality. It ensures less risk, time & cost savings during development, and an overall better customer experience. This in turn leads to saving a lot of money as well as making more money.

New Goal #2: I need to get better at communicating the benefits good quality software will bring in both quantitative and qualitative ways.  I know what they are, but wrongfully assume my clients do as well.  Educating them with qualitative experience as well as providing hard numbers & associated risk costs should help.

New Goal #3: I need to quantify the savings & benefits of doing design early vs. later since in my experience every client who does design last ends up spending more and having more risk & technical debt.

Selling Value, Not A Price

Clark Howard, a consumer advocate and popular talk radio host recently said:

One good thing about the recession is that it has taught us to be frugal consumers.

He later went on to quote those retailers that did well in Q2 of this year. Unsurprisingly, most were retailers who sold goods as cheap as possible (Walmart, Dollar Tree, etc).  I, however, consider my services top of the line goods because I continually focus on being the best.  Even in the recession, people still buy Porsche’.  This recession certainly has made me focus on what makes a Porsche’ a higher quality choice than a Hyundai, and translating that into how I can sell my software services vs. competitors who compete on price.

There are a ton of expenses working for yourself. People who work at companies as W2/employee’s often have no clue of these expenses, and often respond with sticker shock to some quotes. Some just have no idea of the costs of software. Some are just playing the haggling game until I call their bluff.

I’ve spent years building the Jesse Warden personal brand, trying to cash in on my passion and not bothering to have a resume.  Many of my first time clients have no idea who I am, nor who my company is.  If it’s a referral client, they’ve only gotten a distilled version.  Thus, I have to start from scratch to sell my expertise, my experience, and my company’s value.

Two of the recommendations I received from David Ortinau, Jeff Roberts, and Ed Grasing was to sell value, not price. I don’t compete on price; I ensure I’m the most expensive to associate myself with the quality I deliver. This doesn’t work, though, if you don’t have an established brand the client can already recognize, like Cynergy. You can do this by showcasing past work; not just the project, but the VALUE it provided the previous client of yours.  Additionally, doing the legwork on how much it will cost them if they DON’T hire me/my company helps inspire a CYA (cover yo’ arse) feeling.

I’ve done enough consulting to know projects that should of taken 3 months that took 8. I’ve even bid on projects where I said it’d take 4 months, the client figured 2, and then I later hear from those who won the bid that it took 10. Therefore, it shouldn’t be overly difficult for me to also create a project cost estimate based on what I know will happen when others who compete on price do it instead of me.

New Goal #4: Create case studies from past clients that show the value my skills provided them, and how much money it saved/made them.

New Goal #5: For new projects where I’m putting together a Statement of Work (SOW), also add what the cost will be without hiring me.

Selling Myself as a Purple Cow

Seth Godin has an idea about making a product a Purple Cow; something unique that stands out.  Things that makes me unique in the Flex Community are I know how to implement complex designs in Flex, have a thorough knowledge of the Flash Player from my Design Agency background doing Flash, and have an extensive network to use in hiring/sub-contracting additional help as well as answering questions outside my expertise domain.

Not once have I used those 3 things as a selling point to clients about what value I provide.  However, Universal Mind, three times, has used those traits in selling me to THEIR clients, the now defunct ESRIA once, and Roundarch once.

I’ve also recently joined Web App Solution as a partner.  One of the goals was to further increase my networking value since I now have 3 additional senior Flex/Java/Blaze DS resources as well as their experience.

New Goal #6: Use my unique traits to help sell my value to clients.

Conclusions

My goal this year was to double my rate for the sake of learning, and hopefully making more bling.  I want to break the glass ceiling by years end.  Even if I fail, I’ve learned so much already in trying.  I’ve also gotten really close a few times this year so I know I’m making progress.

Another over all goal that I’ve been pursuing is to seek out mentors in the business field vs. the software development one.  When starting out in software, the #1 thing that helped me the most, quickly, with the least pain was mentors.  Everything from official ones to simply reading their books/blog posts.  I’ve sought out entrepreneurs and others online, cornered ones I found at conferences I attend so I could grill them, and gotten a lot of good book recommendations for business as opposed to software.

The consolidated list of my new goals to help reach my New Years Resolution:

1. Learn more about making money.
2. Get better at communicating the benefits good quality software will bring in both quantitative and qualitative ways.
3. Quantify the savings & benefits of doing visual design early vs. later.
4. Create case studies from past clients that show the value my skills provided them, and how much money it saved/made them.
5. For new projects where I’m putting together a Statement of Work (SOW), add what the costs/risks will be without hiring me.
6. Use my Purple Cow/unique, standout traits (design integration, Flash Player knowledge, network) to help sell my value to clients.

This is a lot harder than I thought.  My Dad just said to double my price and the work would roll in.  I’m not the salesman he is, though.  Either way, I’m making a lot of progress and learning a lot, so I know I’ll get there eventually.

This article will discuss what Technical Debt is from a Flash/Flex developer perspective, how it negatively affects my Scrum projects, and what are some of the prescribed ways to prevent it.  Nothing ground breaking here folks, just corroboration that TD IS a major problem, and not even Scrum is immune.

What is Technical Debt?

Martin Fowler has a good summary about what Technical Debt is.  Here are 2 quotes from his wiki:

You have a piece of functionality that you need to add to your system. You see two ways to do it, one is quick to do but is messy – you are sure that it will make further changes harder in the future. The other results in a cleaner design, but will take longer to put in place.

Git-r-done vs. doing it right.

Another quote which describes the metaphor:

…doing things the quick and dirty way sets us up with a technical debt, which is similar to a financial debt. Like a financial debt, the technical debt incurs interest payments, which come in the form of the extra effort that we have to do in future development because of the quick and dirty design choice. We can choose to continue paying the interest, or we can pay down the principal by refactoring the quick and dirty design into the better design. Although it costs to pay down the principal, we gain by reduced interest payments in the future.

The metaphor also explains why it may be sensible to do the quick and dirty approach. Just as a business incurs some debt to take advantage of a market opportunity developers may incur technical debt to hit an important deadline. The all too common problem is that development organizations let their debt get out of control and spend most of their future development effort paying crippling interest payments.

He goes on to mention that unlike money, you cannot effectively measure technical debt. Additionally, you only get a return on your loan once you deliver.

Signs of Technical Debt

There are various signs of Technical Debt.  System fragility, tons of reoccurring bugs, or code that “sometimes” works.

System fragility examples include when you move a login button, the entire login form doesn’t work.  Another sign is when you change a ValueObject’s property name slightly, yet get no new compiler errors.  Yet another, usually a violation of DRY, is when you change a parsing error of a server’s response, yet still get the bug after compilation.

Another example is the statement “the application doesn’t seem to be working”.  If there had been diagnostic tools in place such as unit tests, a debug/log window, or other testing tools, that question could be quickly answered.  Even if it can’t, if you can’t quickly isolate problems after asking some follow up questions, that’s another indicator.

Another is when you fix a bug. 3 times. Over 3 Sprints.  Then it comes back in some other unrelated area.  Another is before the user even does anything you’re presented with one or more error dialogues.

The best are when you see the right data.  Sometimes.  You have no idea if it’s your fault, the server’s fault, or… what.

Bottom line the code has growing pains, and is challenging to change.  When you change one thing it breaks something else unrelated, your change is a pain to implement, or your new code duplicates a lot of functionality because you can’t borrow other functionality because it isn’t encapsulated enough to share.

The one that took me a LONG time to get over when I first started dealing with extremely large code bases was “fatique”. I’d get tired of dealing with all the problems, and feeling like I wasn’t making any progress. That, and I had no confidence in my changes because I wasn’t sure what the ramifications were, what would break, etc.  Effectively, I didn’t want to work on the project anymore. This has happened twice to me.  It’s not from my attention span, but rather just pure loathing at not being able to move forward.  Part of this is remedied in experience, part in “learning the story” of code base by spending a lot of time with it, and just general growth as a programmer. If you’re grown, and still have this fatigue, that’s another clue.

All these and more are signs of Technical Debt.  If not dealt with, they only get worse and more numerous.

Technical Debt’s Effects on Scrum

In Scrum, your user stories need to pass User Acceptance Testing (UAT).  At the end of every Sprint, your client validates each user story your team completed is in fact done.  If you have technical debt, this’ll eat away at the quality and/or dependability of your user stories actually working.  This means one or more stories won’t pass UAT.  This then slows down your, or your team’s, velocity.

This often will negatively affect your client’s view of the team as your earlier velocity will have been higher.  Usually your team will start off slow or fast, but eventually 4 Sprints in, a common velocity will emerge.  With a lot of Technical Debt, the reverse will happen; your initial speed will slowly decrease as your team struggles to cope with the increasing Technical Debt.  If not tackled, more debt is created, and your velocity stays slow, or decreases.

Technical Debt will also often exhibit itself as “bugs”.  In Scrum “there are no bugs”.  Benevolent Scrum Masters will assign 1 point to bugs.  This is often done to put a sense of accomplishment that the bug was completed, but more importantly that it’s trackable.  Its low point value can unfortunately skew to its business value.  Perhaps the bug is what prevented your original user story worth the maximum of 5 points from passing UAT.  Worse, if your team is working on fixing bugs, they aren’t working on user stories.

Again, negatively affecting your velocity.

Eventually your team will either have to pull back and pay off their technical debt, continually pay off a little to show some payoff, or just pray the client focuses on more pressing user stories in other areas and “forgets” the glaring issues.  I’ve seen all 3 happen.

Pullback & Reassess

Scrum doesn’t really have methodology for pulling back and fixing core architectural problems.  It’s generally assumed that 80% of your 2 week Sprint is spent refactoring.  I’ll let that sink in.

Done?  Worse, Technical Debt, being unmeasurable, wreaks havoc on a Product Manager’s ability to give transparency into the project for stakeholders.  You don’t often have a stable velocity; some Sprints your team could simply deliver 0 story points.  This makes it challenging for the PM to project when the Backlog will be completed and when certain milestones will be reached.  It’s even worse when managing budgets and getting contracts signed.  Scrum is hard enough to sell to clients who are used to fixed bid; suddenly Scrum sounds like a bait and switch, or just a money pit.  Assuming your team is actually working on the user stories they were assigned and aren’t trying to sabotage the project, then that situation is usually irrefutable proof that your team has some serious Technical Debt.

Software done with Scrum is like a plane flying from A to B.  While the flight path is continually corrected, eventually it’ll get there.  Planes usually can’t fly with ice on the wings, hence why you setup good architectural bases in the first 2 Sprints.  Ice on the wings during flight can be disastrous.

For some projects, sometimes you have no choice.  Your team has to take the hit, pay off the debt, and rebuild trust with your client.  Yes, these can be bloody, but hey… anything is better than Waterfall which in my experience ends like Lock, Stock, and Two Smoking Barrells: Tons of death, theft, and people get bling who don’t deserve it.  While this is effective with Capitalism, life is too short to product shitty software.

American Credit

While not an American only phenomenon, it’s certainly indicative to our culture, hence why Fight Club had such an interesting ending.  If you’re quick, good, and lucky you can get away with paying as much Technical Debt as you can per Sprint while knocking out a few new user stories as well.  Sometimes this is just how things are; other times, you’re merely postponing the inevitable day of reckoning.  Consultants are famous for this.  They get away with masking the massive Technical Debt, and moving on letting some other poor W2 (employee) sap, or consultants like me, to actually fix the Technical Debt.

Eventually, you have to fix the broken windows… or maybe “you” don’t, but someone does.  It’s easier to do this sooner than later.  I’ve even seen a team where one guy would fix windows 90% of the Sprint, and another would unintentionally break them again.

Pray for Priority Shift

The third one I’ve seen happen in larger companies who don’t adhere 100% to Scrum.  The priorities change for the user stories, and other parts of the application which are basically broken are ignored, buried, and eventually assumed to work.  Flowers don’t grow as well over a dead robot’s grave.

Incidentally, when higher ups find out, this is where I get some of my work.

Preventing & Fixing Technical Debt

As you can see, Technical Debt has devastating effects on Scrum, and Iterative Software in general.  The best way to ensure Technical Debt doesn’t negatively affect your project is to prevent it.  It’s like insect infestations in your house; if you don’t attack the problem early, it can be very challenging to remove.  The best way is to prevent the infestation in the first place by not leaving out food, water, and generally ensuring you have sealed entryways and windows.  Same with software.  Start with a tight, simple architecture, and continue to maintain it.

That sounds great from a high-level perspective, but what does that really mean?

Here’s a few I know & have experience with:

• good design
• good developers
• fixing broken windows ASAP
• OOP, specifically encapsulation
• unit tests with a decent coverage
• an agreed upon framework
• throwing optimization out the window
• using old technology
• Continuous Integration: frequent checkins & religious tagging

Here’s a few I know of, but don’t have a lot, or any, experience with:

• Test Driven Development
• Automated Build Systems
• Automated Testing (Hudson, Cruise Control, etc)
• Functional/Automation Testing (QuickTest and others)

Let’s go over these in short detail.

Good Design

The #1 thing that saves you the most time, reduces the most risk, and directly contributes to the efficiency of your team is a good deign.  Wireframes you hate since you’ve re-worked them so many times with gallons of dead tree’s at your feet, and design comps you love.  5 minutes of a designer’s time can save a week of a developer’s.  When you hit a brick wall during Sprint 5, a designer can quickly put your team back on track quicker and more accurately than a developer can.

Hire, and keep around, a good User Experience/Interaction Designer/Information Architect/Designer today!  If you’re made of epic win, hire a Usability Engineer as well.  They are the ONLY ones who can provide real facts to your team.

Good Developers

A common complaint of Scrum is that it only works with senior to mid-level developers.  I agree.  While it takes a village to build great software, you need to ensure your development team is top notch, or mostly top notch with a rockstar to guide the rest.  I realize this isn’t a reality for a lot of people.  Even if you have a senior dev, the bad developers can actually detract from the senior’s ability to deliver as he/she struggles to re-factor their code while ignoring their own user stories.  That or the bad/mediocre developer continually creates Technical Debt.  While developers not focusing on their user stories is a management problem, not a Scrum specific one, if they can’t even be professional and do what they are told, they are effectively sabotaging the project, and thus need to be removed.

Remember, small agile teams are more effective than larger ones.  If it ends up only being 2 heavy hitters, so be it.  Or you can just hire my team.

Fixing Broken Windows

Not much to add here other than they are usually one of the few things that can clearly indicate Technical Debt.  If you have to prioritize, choose to ignore the ones you can easily predict and reproduce.  They are less dangerous and take a lot less time to annoy your clients.  It’s when you go, “Whoa… never seen that happen before” is when you worry your client and PM.

OOP Encapsulation

One of the good concepts of Object Oriented Programming is Encapsulation.  It may seem silly to bring up something so basic, but it’s a basic, core concept for a reason.  Without good encapsulation, your code cannot grow, nor be flexible; something that’s VERY integral in Iterative development.

It’s ok if your API is good and the code underneath it sucks.  This is where Test Driven Development can shine.  Instead of “creating a component” from the inside out you actually write like you’re going to use the component yourself.  A better API usually results.  Then, you can focus on writing the guts to make that API happen… or not (see throwing optimization out the window).  It’s easier to fix bad code inside encapsulated, and thus easily isolatable components than it is sphaghetti code.  Sphaghetti monsters are waaaayyyyy more scary to fix than WW2 tanks that just need a new engine.

Unit Tests with Decent Coverage

Even if you don’t practice TDD, it’s still a good practice to implement unit tests on problem areas of the code.  TDD purists will state you should write tests first.  If you don’t, there is still a ton of value in writing unit tests, or getting good “coverage” of problematic areas.  Key areas include your Service layer or any code that accesses non AS3 data and injects it into the system.  This includes XML, text, JSON, AMF, binary data, and anything that “parses” something.

Strong-typing is awesome, but it assumes you started with strong-typing.  Parsing XML to ValueObjects is great, but if “That PersonVO is a Spy!”, good unit test coverage can usually point that stuff out early and save the team days of debugging and lost time.

Plus, it’s really awesome to blame with 100% confidence the back-end Java team for your woes in 7 seconds vs. 2 hours of frustrating searching for a needle in a haystack whilst being verbally bashed by the back-end devs wondering why you didn’t use HTML5 instead of Flex.  Suddenly Outlook does a cliche freeze before you can write a scathing, emotionally charged, career destroying email back at those over-architecting ($*&Us.

While they have less value on GUI components, some of the ways in which you architect Flex 4 components can actually facilitate easier testing.  Examples include really complicated components that NEED to be in a specific state when data is injected.  While a really complicated chart that has 100 unit tests around it still has to be visually verified, those 100 unit tests can help dramatically.

Finally, in those areas where you have good coverage, you can do minor refactoring with a ton more confidence.

Agreed Upon Framework

Doesn’t matter what framework your team chooses, as long as you all are in agreement.  This could even include using no framework.  I prefer Robotlegs, my partners prefer Swiz, and my clients often still use Cairngorm 2.x.  Regardless of your thoughts on frameworks, in my experience they help you manage, scale, and work with a team on larger code bases.

Premature Optimization

Knuth once said:

…premature optimization is the root of all evil.

After awhile, common optimizations you do by default, and to me, aren’t even considered intentional optimizations.  Some are small, low hanging fruit, that you can do without even thinking and make into habits.  Examples include setting an Array’s length to a local variable instead of inside of a loop, using Object Pooling, and using visible vs. removeChild.

Good programmers constantly want to make their code better.  Sometimes this means faster or more responsive.  The really good ones know when to leave a TODO, and move on.  Most users are happy with a reasonably responsive GUI.  A programmer’s expectations of “responsive” is often way higher than what a user will accept.

Code it and refactor later.  You can’t refactor vaporware.  Focus on pimp API’s.  Besides, this is ActionScript, not C.  We have certain limitations (no threads, a VM vs. all code being machine code, and a lot of missing optimizations).  Brandon Hall once said if you have a performance problem in Flash, you’re probably doing it wrong.  Instead of re-factoring code, step back and re-assess your approach.  Recognize those limitations early, and yell like crazy at the designer, “WE CAN’T GO TO THE MOON IN A TRICYCLE YOU FRAKIN CRAYON PUSHER!!!?”

If you have something to prove, do it at night and post to your blog.  If the GUI isn’t responsive, well duh, that’s not a bad optimization, that’s a required one.  The point here is if you need to prove through tests cases that by not doing your optimization(s) that the app will be unresponsive, you’re either in dangerous time sink territory, or doing something amazing.

Use Old Technology

While I love using Flex 4, a lot of the apps I still work on, and clients have in development and/or production are Flex 3.x.  Flex 3.5 & Flex Builder are solid, 4.0 SDK and IDE, not so much.  You want your problems to be programming challenges, not unexpected scrollRect or IDE magically disappearing code hinting bugs.  These things can be major time sinks and devastating to your productivity, sometimes killing your entire day as you attempt to reinstall & reconfigure various things.  Mitigate those risks by using old software that works and has a proven track record.  Most won’t listen to this paragraph and I don’t blame them.  Flex 4 skinning does help a lot in the “make this design work” department, although, no one talks about the overhead costs of putting an icon in a Spark button, and all the other simple things that are now more complicated.

Software traditionally outlives it’s original expected lifespan by 3 times or more.  One of the reasons is that it works.

Continuous Integration

Continuous Integration is a gigantic topic, and actually encapsulates a lot of other sub-topics I’ve already mentioned.  I just want to focus on the parts of it that I found extremely helpful and harmful if not followed.

The first is checking in your code often.  If you don’t know how to merge code, learn.  If you don’t know what tool to use, use BeyondCompare.  If you’re on a Mac like me, use CrossOver to make BC work (I’ve been using that setup for 4 years).

Even on a 2 man team, merging and testing your changes can take a lot of time, even if you and the other developer are on completely different sections of the code base.  On one project, we actually set a specific merge day on the 2nd week of our 2 week Sprint to ensure we planned for this disruptive day.  We’d both merge frequently, but we’d still ensure we didn’t merge much more after that since it can wreak havoc on UAT day.

Regardless of what source control system you use, you NEED to implement tagging.  This doesn’t need to be a team thing at all; just give 1 person responsibility with this important task.  Every UAT day, they need to tag the build.  Developers in general should make their own tags and branches, but sometimes the code isn’t in a risky spot and you don’t end up doing it.  That’s ok.  You should still have Sprint tagged builds so you have SOME saved point to confirm/deny major bugs/changes against.

Test Driven Development

I won’t go into detail here, but I’ve seen the positive benefits on my Service layer, or when I’m writing a library for others to use.  For both, you actually create the API first and it feels immediately relevant.  Additionally since the Service layer is often the weakest link in your application it’s great to proactively find bugs that would of usually cost a lot of time early on.  That, and you have a dependable suite to test for changes that may negatively affect things later on.  Finally, you can test if the entire applications communication system is working within seconds, quickly killing assumptions that add to debugging time.

What I haven’t resolved yet, and this is probably due to my inexperience with it, is how to manage the amount of code I have to refactor.  No longer just the components, but the tests often as well.  This is especially true with some of my more complicated GUI composition components where I test the controller layers.  Maybe it’s my inexperience with TDD & unit tests, maybe my tests just aren’t very good… I don’t know.  Like any problems with the GUI, I just blame the Designer.  That doesn’t make the re-factoring amount & time go away though.

Automated Build Systems

Automated build systems include things like ANT and Maven or even Rake.  This is the #1 question that sabotages my sales call when talking to Enterprise clients.  They want to here me say, “Why yes, of course I’m a major proponent of automated build systems.”

I don’t, though.  ActionScript & Flex Dev isn’t Java, and is a lot simpler.  I’ve seen more team productivity lost to setting up & maintaining build systems.

… except for deployment.  When you’re deploying to various servers, and doing integration testing with different systems, I’ve seen TONS of value here.  I’ve only seen this work if you have a dedicated build person who doesn’t mind having a lower story point contribution.

If I can’t hit the run and debug buttons in Flex/Flash Builder, I perceive that a serious problem.  I’ve seen many teams who can’t do this, and fire drills rage.  Once you solve that problem, you can start tackling other problems.  There are many who disagree with me, but they are nowhere to be found on my consulting gigs where I’m saving a project.

Automated Testing

The King James Bible says in the 10 Commandments that you shouldn’t covet your neighbor.  I’m an uber-sinner then because I’ve never worked on a team that had the chops, client permission, and/or resources to setting up and maintaining an automated testing server, yet I continually wish I had been, or soon will.  I’ve been on teams where we talked about it, but it was never executed because we too busy TRYING NOT TO DIE AND ACTUALLY SHIP SOFTWARE.

Hudson and Cruise Control look awesome.  That said, a lot of the people I’ve worked with don’t even write unit tests, so……..

Functional Testing Tools

As I stated, a lot of things in Flex are insanely visual; you can’t write unit tests to test visual accuracy.  That, and some of the state’s they get in are unwieldy to write tests around.  You can utilize functional testing tools to automate a lot of that… and man, seeing them in action is HOT!  They are wicked expensive as a result, and only the larger Enterprise companies employ them.  Here, too, is another thing that sabotages my sales calls with clients:

“You ever use Functional Testing tools?”

“No, but I’d love too, they look HOT!”

Conclusions

In my experience with Scrum, and Iterative Development in general, Technical Debt is the only thing I’ve seen that can really destroy the promises that Scrum is supposed to deliver on.  Thus, it’s been the one thing I’ve been focused on better understanding on how to identify, prevent, and fix.  If you’re using Scrum, beware.  Twice I’ve seen Technical Debt make a huge negative impact on my projects.

There are a bunch of things you can do.

Think heavily upon the decision of coding something quick vs. planned out well architecturally.  There are pro’s and con’s to each (OOP Purists will tell you nothing should be quick, they are wrong).  Sometimes you have zero clue if feature is even relevant to the your users, and it makes huge business sense to only make a quick foray vs. a huge, heavy architecture investment in case the user quickly scoffs at the functionality.  Patton called this a “calculated risk”.  Software IS War.  Other times, that quick implementation without any good architecture can have major negative consequences later down the line.  That’s ok, though, just get really good at refactoring.  Yes, it’s a skill you can learn.  Yes, refactor is a good word; it’s not the same thing as rewrite, and is integral to developing software well.

The other ones are ensuring you have a competent team, ensuring they follow commonly known practices, and tackle problems early.  Check your code in often and early.  If you don’t employ TDD, at least think about getting some unit test coverage on areas that continually are causing problems.

Remember, part of this recession was caused by people having massive debt they didn’t deal with, and ignored.  Debt is a valid way of doing business, and so is software, but you need to see some eventual value on that investment, and not let your debt get out of control.

If you ignore everything I said above, just remember 3 things: encapsulation, refactor, and use a damn good logger.

Caveats

I continually abuse 2 terms below, Backlog and Sprint.  Sprints don’t have to be 2 weeks, but for the sake of simplicity, I assume they are.  Also, Backlogs contain user stories, not requirements or features.  However, I assume for the sake of this article your features are already formed into user stories.  Finally, I assume that once I capture a requirement, it’s thrown into the Backlog.  I actually have a document which holds the validated requirements, which I then later formalize into user stories, and then put those officially into the real Backlog.  In this article’s case, that process is assumed to have already happened.

Review: What is a Backlog?

First, a review. A Backlog is a place you store features, or user stories. There are often 2 Backlogs for a software project, a Product Backlog and a Sprint Backlog. The Product Backlog contains all features for your software. At it’s purest form, it’s an spreadsheet that lists all the things your software is supposed to do, with a rated business value. While it can be seen somewhat as a requirements document, it is more defined, and singularly focused. It merely lists features/user stories.

While a requirements document may say “The application needs to allow users to register and login”, the Product Backlog would probably have that as 4 line items:

• Upon entering [product URL], and the user isn’t logged in, they’ll be presented with a login screen. They can enter their username and password, click the “Login” button. If the correct credentials are provided, the user is shown the landing page.
• If the user inputs the incorrect username and/or password, the Login screen is shown with the error message “Your username and/or password was incorrect”.
• If the user is already logged in when entering [product URL], they are automatically taken to the landing page.
• If the user does not have an account, and arrives at the login page, they can click the “Register” hyperlink to be taken to the New User Registration page.

There are a lot more user stories you can write, or even refining the ones above. There are a few points here in the difference. The client wants users to register and login. This requirement can easily be documented in a requirements document. That requirement belays a lot of work for developers, and a lot of things for the PM to track. Requirements are for capturing the client’s needs, but are not setup for clearly laying out what a developer should do, nor what the acceptance criteria is. The developers want clear instructions on what they are supposed to code with a clear acceptance criteria. Most importantly, the Project Manager needs to have trackable items, clearly documented, that are accepted by the client. Additionally, she needs to have weights and priorities attached to these items so she can track over time and give the client transparency into the project.

These units of work, called user stories, are stored in the Backlog. They are mutually agreed upon by the client, developer(s), and the PM.

Review: Sprint Backlog

A Sprint Backlog is where you put features/user stories that team needs to complete each Sprint. You put user stories into the Sprint Backlog from the Product Backlog. Once the Sprint starts, the Sprint Backlog becomes frozen. While you can add & modify things in the Product Backlog while the Sprint goes on, you cannot add/modify things in the Sprint Backlog. Additionally, the Developers are the only ones who actually mess with the Sprint Backlog. They’ll assign user stories to themselves, complete it, and move to the next.

What Are We Building?

One of the reasons for the high rate of software project failures is due to the software not being what the client wanted. Software is usually built to a specification or “spec”; a document that outlines what the customer/client wants. Clients are busy. Thus, back in the Waterfall days, you’d get a sales and/or PM to document as much of the client’s requirements as possible, formalize it into a contract, usually a Statement of Work or similar, and have both parties sign it. This contract was supposed to be what you were building, by when.

There were 3 huge problems with that. First, it assumes you accurately captured requirements. This is a fallacy. Communication is a flawed process based on the filters we humans use to understand other humans (my mind filters the thought into speech I believe you need to here, you hear this speech and interpret the meaning of my words, and filter it to what you think I said). Thus, you need to, rightfully, assume any documentation, even mutually agreed upon, is flawed.

Second, developing software is slow compared to making dinner. The business and/or customers who needed the software can change.  Software needs to embrace change to be relevant.  Iterative development embraces that concept whereas Waterfall does not.  Waterfall assumes you got it right “months ago”, and there is no room for the client to change their mind.

Third, it’s a myth that people can tell you what you want.  Clients think they know, even if they are actually involved in making software, but they don’t.  Usability testing is the only proven way in software to validate if your software works or not.  To do usability testing, you need to have a working build of software.  To have a working build of software, developers have to make a build vs. work on the build.

Iterative development forces you to make working builds every 2 weeks, and gives the client the opportunity to validate that your implementation of user stories are actually valid.  This also allows them to validate the software is solving their current needs, and if not, they can shuffle the Product Backlog around, and re-prioritize for the next Sprint.

The Product Backlog contains all of the features your software has, and the Sprint Backlog has the frozen features your team is implementing this Sprint.  The key here is that the Product Backlog can change.  Whether your client wants to re-prioritize, or they have new things they want to add.

Scope Creep

Scope Creep is defined as the scope, or total requirements for a project, growing over time.  The word “creep” is used to imply that it’s growing beyond the originally agreed upon scope, and it’s doing it slowly enough not to raise the ire of anyone beyond those actually designing & developing the project.  It’s the bane of web & application developers everywhere.

Unless you use a Backlog in Scrum.

If the client wants to add new functionality, they can.  Adding new functionality to a project is often a good thing.  Whether a good idea that could of only arisen AFTER a build of the software was used by the client, or a glaring hole in available functionality was noticed weeks later.  Sometimes the new functionality is just a piece of functionality re-stated, but with additional work behind it.  Developers usually hate this because while the client perceives it as “the same scope, just re-worded”, developers know that it’s 3 times the work.  First, they already built it; second, they have to re-work their existing work assuming it can be re-factored at all; and third, they still have to code all the NEW functionality added…

…within the same timeline.

Unless you use a Backlog in Scrum.

Remember, the Sprint Backlog, the things developers are working on during a given Sprint, is frozen once your team starts.  It CANNOT be changed once you start.  The client is welcome to modify, change, and re-prioritize the Product Backlog whenever they want.  If the functionality your team delivers at the end of every Sprint meets UAT (User Acceptance Testing… also known as “we built exactly what you asked”), and the client wants to change it, it’s added as a new feature to the Product Backlog.  This is huge.

This means that anytime the client “adds” or “changes” something, it’s clearly documented in the Product Backlog.  The key here is if your team already delivered a user story from the Sprint Backlog, and the client wants to change things, they can’t magically undo the completed user story your team completed.  It stays completed, and a new one is created for insertion into the Product Backlog.  This is a track record for the PM and your team to clearly show they client they ARE adding scope the project.  Your team IS delivering on what they were asked to do.

I don’t want to get into teaching the client, managing their expectations, etc. I just want to point out here that’s how it’s supposed to work, and that’s fine.  Most Product Backlogs grow as the project moves forward.  This is a good thing.  It shows things are evolving and getting refined.  Your client is getting what they want.  Your team is shielded from scope creep sabotaging your work and the client’s expectations.

Product Development Helper

I’m involved in 2 products currently.  One is an Enterprise Dashboard Framework for my company, and one is an image app I’m working on with Joel Hooks.  Both projects were well under way when I was brought on board.  Both project owners specifically asked me to join to help them accomplish 2 things.

First, they wanted to launch.  Second, they wanted an opportunity to do Scrum development.

While I have gleefully accepted helping them reach these goals, this put me in a few challenging situations.

Economics of Design Phase

From my experience in software, I’ve found (and read online to corroborate) that the most impact with least cost is spent in the Design Phase.  This is when the User Experience (UX)/Interaction Designer (ID)/Information Architect (IA)/Designer people/person figures out what we’re building.  To give you context, let’s pretend I charge $50/hr (<– lol!) and conveinantely leave out the design part (where wire frames are made to look hot via Photoshop/Illustrator/your mom):

• 2 hours spent on wire framing a Login = $100
• 16 hours spent coding the Login to work = $800

Now, the ratio varies, but typically development time greatly exceeds time spent wire framing.  There is also a dependent relationship here that the above math doesn’t show. Attention to detail & well thought out user stories implemented in the wireframes often significantly reduces the amount of time developers have to spend.

• 2 hours spent refining registration = $100
• 6 hours saved by devs not having to stop, lose momentum, ask questions, get clarity, re-work, wtf = $300

Another advantage is “cheap flexibility”.  If you want change your mind about something in Design Phase, it’s really cheap.  I’ll often utilize a pen and paper for creating software, whether that’s in the beginning, or after we hit a design/functionality challenge in the design comps and we have to go back to the drawing board as it were.  Drawing boxes and arrows, and then summarily ripping out the piece of paper for 2 hours until we get it right.  This, as opposed to having developers figure out mid-sprint, costing them valuable momentum, and setting them up to fail.  …and costing a lot more money.

• 4 hours playing around with the Landing Page = $200
• 2 days using developers to play around with the Landing Page = $800

Keep mind, your Designer doesn’t contribute, nor is beholden to, Story Points.  If you utilize your Developers to experiment, you’ve detracted from their ability to deliver on their committed stories.  This costs you twice: Their lost productivity they’ll have to make up, and by spending more money using developers vs. designers to play around with a design.

False Starts

I’ve tried & failed enough times at launching my own product ideas that I’ve learned what not to do.  The #1 problem I ran into was lack of design direction.  As a single man team, I had to do design, front end & back-end development, and product management.  That’s hard.  If you know the idea, the market, and are passionate about it, you can actually do pretty well simultaneously performing all of those roles.

However, as a coder, I naturally spend way less time on design.  That was consistently a mistake I paid for. It absolutely annihilated my momentum.  More importantly, as I got frustrated I didn’t have design direction, knowing I’d have to stop coding and do more upfront design work, I lost the will to continue.

Once you lose the will, you’re screwed.  You won’t launch.

Design Phase vs. We’re Almost Done

Thus, for both projects, I’ve spent a lot of time on the design phase.  This means everything from documenting what we’re doing, drawings and wireframes, and keeping track of our Backlog.

The problem is, both teams are rearing to go… they want user stories to munch on with Sprints.  The old adage here, “garbage in garbage out” still applies to the Backlog as well, thus I’m sticking to my guns.  While we collectively could extract what user stories there are, and sort by priority, without a good design to guide those user stories, we’re just going down a misguided path with awesome equipment.

I haven’t figured out how to manage this.  My only saving grace is that I can easily remember back to when I was “just starting” or “re-starting for the 4th time” that my will was waaaayyyy harder to break in the beginning; it was only once I had been working for 3 days straight, and hit a design brick wall that it crumbled.  However, if I was just thinking and playing around, my will could stay strong for months.

We Need To Do This Also: Work Intimidation

Both projects have their challenges.  For the Dashboard, I know the audience, so it’s pretty easy to wireframe for it, and outsource the design.  For the image app, I have no clue who they are, and the descriptions I get from her majesty and Joel, I can’t relate to.  So, I had to create Persona’s, validate these persona’s, and then create goals from them.  Even simple goals lead to a lot of software work.

Another problem I found with trying to launch a lot of my own products and failing was breadth of work.  Not scope, but the amount of goals the software was trying the accomplish.  I’ve found the amount goals you’re trying to solve is directly proportional to the amount of work you have to do.  I was only successful when I targeted a reasonable amount of goals to the created a somewhat reasonable amount of work.

At first, you think “man… that’s ALL the software does?  This’ll be easy… and disappointing.  There’s not much of a challenge, and I’m not sure my users will like software that doesn’t do a lot.”

Bullshit.  If you believe that, you’ve never launched software.  I believed that, then I failed 50 billion times trying, and eventually gave in, and tried to launch even something mediocre.

The incorrect perception I had to overcome was that launching, with all the hard work it takes, is the end all, be all.  It’s not.  A “launch” just has to be a working product normal people can pay to use.  Like any web based, or self-updating desktop software, you can iterate well after version 1.

I’ve constantly had to remind myself of this as I document & wireframe functionality for both applications.  I get really disheartened when I recognize a Persona goal isn’t met, implement it on paper or the wireframes, and recognize the breadth of work I’m creating for my team.  The fun challenge I’ve found is figuring out how much I can take away, yet still launch.  The key point here is “take away” merely means tossed in the Backlog.  Good, valid idea, documented, but not making the 1.0 launch cut.

I don’t have to feel bad at all, in fact, I should feel good twice over.  First, because I’ve significantly reduced scope, and thus increased our chances of successfully launching; and second, I’ve done my part and documented the valid feature, and stored it in it’s appropriate place.

Painful process, but I seem to be getting better at it.  I can’t imagine building the Google.com homepage.

Projects Backlog

I do a lot. I’m busy.  I work a lot.  Thus, prioritizing my time in helping with these projects actually creates a “Project Backlog” in my real life… one that I am not following very well.  I can only do so much in a day, and if I don’t prioritize my tasks into a linear list, nothing will get done.  So far, I’ve tried 3 day sprints where I focus on 1 project for 3 days, and then hop back to the other.

Some days, that doesn’t work, and I get confused on which one was I was working on.  At the very least, I at least try to do my “5 minutes a day” rule: spend at least 5 minutes a day working on the task.

While the ivory tower solution is to focus on 1 project first, and get it done, it doesn’t work like that because there are dependencies.  So, I’ve tried to balance it out by working on 1 project while the other is in a lull/waiting on someone else.  Sadly, it seems a Project Backlog doesn’t really work because I can’t freeze it like a Sprint Backlog, and there are too many dependencies out of my control.  I refuse to waste time, thus, I’ll just hop to some other project to keep productive.

Conculsions

If I had the choice, I’d probably just focus on project at a time.  However, this is way different than coding.  With coding, assuming I have a ton of user stories and design comps waiting for me, the onus is on me, and the time is full.  With designing & managing… sometimes I physically can’t do anything other than wait.  Also, some of the tasks I need to do are a lot shorter.  Writing a document takes 30 minutes vs. 4 hours to code a component.  Therefore, it’s way easier to shuffle a schedule around, and make it full of multiple projects vs. just 1.  While hard, I feel like I’m on the right track… I just need another 10 years of practice.

Bottom line, I’ve found the Backlog really helpful in both capturing all we want to do, and all that we don’t have time to do.  It shields my from my clients inadvertently sabotaging my team’s development on their project, while ensuring we capture what they need.  It ensures everyone knows what they need to do, are setup to succeed, and is trackable.  It kills scope creep dead, and helps me reduce software complexity.

Introduction

Early in the year, I knew I was done with freelance, and working with other consulting firms. Freelance doesn’t make enough money, and working with other firms prevents you both from doing what you want to do, as well as making more money. I could either build my own firm, which required a ton of branding & marketing work, or just join an existing one. There are pro’s and con’s to each and after weighing the options for about a year, I just joined Web App Solution as a partner for a year to see how it went.

I figured, even without doing a marketing push on my blog, Twitter, and speaking engagements, it was a shoe in to more, larger engagements. My assumptions were WASI already had an existing client base I could tap into, having 3 additional Flex + Blaze/LiveCycle developers associated with me exponentially increased my value to clients, and I could leverage my existing brand to enhance both.

It hasn’t worked out like that at all. The recession from the fall of 2008 is still in full effect. Back in 2006/2007, I’d have 4 clients I’d court, and then pick 1. Getting them to sign a SoW was cake; I wanted them, they wanted me; it was just the formalities on getting a number we could both agree on. Last year, and this year, I’ve lost count of how many clients I’m courting. It’s gotta be in the realm of at least 20 who are worth pursuing, and tons more who aren’t, yet may pay some money in between the larger engagements. That, and my expectations for engagements are higher. As a company, we have a lot of value from a resources, tax benefits, and experience perspective. We can charge more for that value.

Additionally, the type of clientele I target are very different from the clientele I targeted when I was freelance. To summarize, I used to target Flash engagements that lasted 6 weeks or less (often just 2 days). When I got into consulting, the firms I used to work for would usually target engagements, often Flex, that lasted 2 months, 6 months, to 18 months. The 2 month gigs often cost more for the client, but didn’t have a lot of consultants on-site, and thus weren’t very profitable. The 6 month gigs were either small engagements to help a mid-size company get started a project, or more often to save their failing project. The 18 month gigs were often larger enterprises who wanted to create some B2B product, and needed a partner to do so. Meaning, they didn’t the in-house development resources, and thus hired the firm.

My firm targets the same types of 6 and 18 month gigs. To get those kinds of gigs, however, is really hard. Companies are sitting on $2 trillion dollars in the USA, and a lot of the banks have $1 trillion to lend; all aren’t spending/lending it to grow their business because our Congress is trying to pass some new bill to replace the failed Sarbanes/Oxley. The 250+ new rules has them scared, and thus they are holding back doing anything until I they know what our crazy blue gov’t plans to do. The 2000 page document that no one in the Senate has read, has 150 page summaries being sent out to various companies by their lawyers. Yes, I’m aware that “summary” is the incorrect adjective to utilize for “150 pages”, but it is what it is. Also, given my blog word count, I’m aware I’m not at liberty to judge (too harshly anyway).

Thus, I’ve had to work extra hard to ensure the leads (potential customers) I’m dealing with actually have money and can afford my company’s services. Once that’s complete, I have to barrage them with questions to ensure I understand what they need, and my company is in fact what they need. Third, I then have to draft some documents, usually a proposal, to ensure I’ve documented and shown I have a more than adequate understanding of what their company needs my company to build/fix/help them with. Fourth, this needs to be formalized into an SoW that ensures we’re protected, the client is protected, clearly states what the client will get, and ensures we get fairly compensated for what we’re doing. Fifth, we need to close the deal. I don’t want to do any of that, however, unless I’ve ensured the potential customer has any potential, and thus is worth spending time on.

I really really really suck at those things, hence this blog post explaining what I’ve learned and what I think I don’t know, as well as what others have advised I do.

Qualifying Leads

Qualifying leads means ensuring that those who contact you have money, have valid work, and they are worth talking to. Just because someone who emails you for a Flash job has no money, and no valid work doesn’t mean they aren’t worth talking to. I’ve learned a lot about our industry just talking to clients, getting to know them, learning about what they are working on, their perceived challenges, and who they know. These are valuable networking contacts, and sometimes gateways to future work.

That’s the exception to the rule, though. Your gut can quickly tell you if someone over email/the phone is a client you want. While there are a lot of exploratory things you can look for, I only want to know 3 things before I spend any time investing more time than a quick phone call/email reply:

1. How long is the project?
2. Do you have money to fund the project to completion?
3. Am I and/or my company a good fit for the project?

Project Length vs. Sales Cycle

In the past years of doing freelance and consulting, I’ve found you can spend a TON of time on qualifying leads if you’re not careful. While sometimes this leads to good networking contacts, as well as helping your fellow contractors/freelancers pay it forward by referring clients to them if you’re busy, you also lose a lot money. As a freelancer, the only way to make more money is to raise your prices or increase your hours. Freelancers often don’t really have high overhead costs, so you can’t reduce overhead. Thus, time spent talking to clients to get work is time NOT spent working on billable hours.

Incidentally, this is one of the reasons I specifically try not to do any Flash work anymore. The length of those projects, 2 days to 6 weeks, is significantly less than Flex projects which last 2 months to 18 months. Sometimes you actually spend the same amount of time talking to a client to get the ball rolling on the project which significantly cuts into your margins (aka, profit made working on the project minus how much time it took you to get the client to let you start working on the project). If I’m going to spend 2 total weeks courting a client when it only leads to a month of work, that’s pretty costly.

What I’ve noticed is that a lot of Flash freelancers tend to have many clients going on at the same time. The churn and frequency of clients is very high; this offsets their down time. That, and Flash projects have high frequencies of intense activity, and then die off for days at a time, usually as the agency waits for a clients feedback. This works to the Flash freelancer’s advantage to arrange their schedule to make multiple clients work. Additionally, there are federal laws that ensure freelancers can set their own hours (although I’ve yet to meet a client who gives a shit).

Bottom line, you want the shortest sales cycle (time it takes to get the client to sign your contract, or you sign theirs, or both so you can actually start designing/coding) with the longest amount of work. Any downtime between gigs is time you aren’t making money. Charging $200 an hour doesn’t mean much if you only work 3 month out of the year because it’s so hard to find clients who are willing to pay that much. For some people, that’s actually fine.

Do They Have Money?

If a client doesn’t have money, they are usually wasting your time. There are rare cases where a client is actually putting feelers out; this could be a director at a medium to large company, or an Entrepreneur who is doing recon before he talks to his investors. Additionally, it’s not as black as white as having money or not; some don’t have enough, and maybe you can work something out. You need to have a clear idea of what you charge. That topic is too large for this post, but I’ll let you know how I operate for context.

I believe in creating high quality software with a high quality team, and thus charge for that. I don’t compete on price. I don’t lower my price to score a deal because a client thinks I’m expensive. I know what my competitors charge, and I know I’m one of the best, and thus price appropriately. There is a major problem in our industry right now with Flex and Flash work sometimes bleeding into each other. This includes a LOT of factors that muddy the waters, and require a lot of education, re-education, and clarification that you need to do with clients. Some of it is subjective, too, because there are a TON of people who do compete on price right now in our recession, and can give the perception that your points aren’t valid.

“I can go to Best Buy and buy a laptop for $300 right now… why the heck would I buy a $1,500 Mac?”

You don’t see Porche lowering their quality and price just because we’re in a recession. Neither do I.

Regardless, common problems include pricing Flex projects as Flash projects. A lot of programmers have flocked to using Flex and Flash Builder. While 5 years ago, most of us would of used Flash to build a Facebook widget, nowadays a lot will use the Flex SDK. This causes 2 problems. First, you often get high caliber programmers put on low caliber projects that do not utilize their full skill set. Building an Enterprise RIA is most often done utilizing the Flex SDK by software developers. A lot of smaller scale Flash work is now more often more easily done using the Flex SDK, but the price point for such work is still in the low caliber, “quick git-r-done” programmer range. Additionally, the time estimations for such low caliber work are often geared towards a shorter shelf life with consumers often use the tools, not clients who have a feedback channel. Thus, the deadlines, and thus quality of code, are significantly lower because they can be. This leads to extremely short, non-moveable deadlines.

This goes counter to what most Flex Developers who build Enterprise RIA’s are used to; long deadlines, mostly negotiable because of Time & Materials contracts, with good quality code. There are a lot of up and coming Flash Developers who utilize Flex for some of these projects, and thus helps create additional confusion on why one person use the Flex SDK is $30 and hour, and another is $80; when they effectively “doing the same work”. *face palm*

If you are one of those Flash Developers, this is fine. If your’e a Flex Developer, you often have to ensure the client even gets Flex. Most real clients don’t care what technology you use. However, Design Agencies service a completely different clientele than software shops/consulting firms do. As such, you need to ensure the lead on the phone/over email is talking about a “true Flex project”. Otherwise, they are doing a Flash project with Flex, and their rate expectations will reflect this. This means they’ll often be WAY too low than what you were expecting even if they go on about “Flex consuming SOAP web services”.

Another common client I get is the eff’d one. Their developer went AWOL, their team doesn’t know what they are doing and need mentoring, or they are slowly realizing they are getting screwed over by another company and need me to confirm it. If they are a big company, they’ve actually often factored this into the budget, or can easily get these budgets approved very quick. While it sucks that its’ easier to get bling approved to cut your losses than it is to help increase your gains, my consulting career has confirmed this with a lot of large companies. However, every so often I get a company who’s eff’d, or they might not even know they are eff’d, and do NOT have the budget to get themselves out of it. Sometimes they do, but by hiring a $30/hr miracle worker. Consulting in bad situations is bad enough, that’s why you charge for it. Consulting in bad situations where they client cannot afford it are situations I don’t put myself in. While it’s hard to get the true scope of death-incarnate over the phone, it’s pretty easy to get the client’s background and understand if they can fund the rescue operation or not.

Keywords for me include, but are not limited to, the following:

1. 2 week project
2. coder is almost done, but pulled off on another project
3. we’re almost done, but this one feature is killing us, and we’re not sure how to do it (usually means someone who doesn’t know Flash Player capabilities sold their client on something that they couldn’t do, or couldn’t afford)
4. we’re an design agency
5. Flash widget
6. our game is having a few problems

I could go on and on, but all of the above basically mean “we can’t afford your services”. A 2 week project isn’t profitable unless I can ensure 20 of them come in exactly at 2 week intervals, and I don’t spend months trying to line them up this way.

If the coder is almost done, but was pulled off onto another project, it means the company is small, or doesn’t have the resources to tackle larger projects, thus they need you for staff augmentation. I’ve seen a few rare instances where Flex projects have this happen, but pulling the main developer off of a 6 month Flex project isn’t smart at all, and there typically isn’t just 1 Flex developer. Thus, it’s a Flash project, under a deadline, you’re left beholden to that developers’ code, usually not using best practices because the company is more focused on getting it done, on time. Software isn’t done “on time”; if you think it is, you’re not building software, you’re building some short shelf life Flash project for a client on a fixed budget.

The “this last feature we need a heavy hitter on” usually implies either something that shouldn’t have been sold to the client in the first place, or a wrong approach. For the latter, sometimes you can often knock it out in a day, but 4 hours of back and forth with the client for 8 hours of work is extremely unprofitable. This can get worse if you actually do a good job, and they start expecting you to fix their technical debt. While more hours are nice, if you only budgeted a day for the project, it gets complicated to fit into your schedule.

“We’re a design agency” means they’re used to getting Flash contractors for $30 to $50 an hour, thus your software developer rates aren’t going to fly. Worse, most companies/firms charge more for shorter gigs because you have to take resources off of other projects to help the client with their shorter, less flexible project. This has a major cost, and thus you factor that into your price. This, in turn, makes agencies often get a more incredulous look at your price. Bottom line, they want a Flash freelancer, and I’m trying to provide them a resource from my company. Wasn’t meant to be.

Flash widget. I don’t know many Flex coders using Swiz, Continuous Integration, and attempting to master TDD in their SCRUM process who build Flash widgets. Thus, you’re often left with a really small budget, that’s fixed, that’s already coded, on the timeline, and you’re beholden to that alien workflow. Not going to work.

Our “game is having a few problems” is often the worse. Games are actually some of the most challenging things to code. In Enterprise architecture, you often have a long history of patterns and processes to cull from. In games, you have to have good knowledge of algorithms, specific design patterns, and a good breadth of technical understanding of how the Flash Player works. If a client is calling you to help them fix this, they should of called you in the first place. I’ve lost 2 game gigs last year where they ended up calling me back to help them fix it; by then I was deep into a gig, and cursed myself for my lack of sales ability. I don’t like when clients get bit by the obvious, getting what they pay for, but I also don’t like when I would of saved them, but am not given the opportunity to do so. Gaming architecture is often more tightly coupled for performance reasons, and thus is way harder to fix. Combined by the fact most games are done in agencies on fixed budgets with fixed deadlines, it’s just a lose lose situation.

As you can see, making sure leads aren’t looking for a Flash freelancer is hard. Once Flex seeped its way into smaller Flash projects, it made the perception even worse. A larger majority of the “gigs” I’m filtering out are those above. I’m looking more for “engagements”; longer term Flex projects that are for building software for companies.

Is My Company A Good Fit?

The last filter for leads is confirming my company is a good fit. While a client may have settled on Flash, oftentimes I can teach them about Flex and we go the right route. However, if they have their heart set on a custom PHP/Python back-end, it’s more difficult to sell my companies services. My dad would say, “If they ask if you can do PHP, you answer that yes, you can do PHP”. I know PHP, and I’m sure my fellow partners do too, but we specialize in Java. That’s not just a preference, but Java tends to exist in the real of larger Enterprises. There are some, yes, that do PHP… but the clients who provide the longer term Flex gigs use Java. Back in the day, you didn’t invest in Sun servers because they were 10 times what a LAMP stack costs because you were dumb; it’s because it was WAYYYY easier to get Sun/Java consultants than LAMP consultants. If you’ve invested half a million of your company’s money into a project, and no one can help you fix it when it breaks, you’re screwed. Thus, double the budget, and ensure it’s a well known tech that you can hire consultants on in case things go south.

Thus, usually by mentioning something other than Java for the back-end, that’s usually my first indication we won’t end up working together. While both PHP and Java have a lot in common in the open source world, if they’ve invested in a LAMP stack, they are doing so for cost reasons (most anyway). Most large companies I’ve worked with do not care at ALL about cost; they care about making money. If their costs are high, they focus harder on making more money to cover those costs. I’ve seen a lot of good businesses run on LAMP, but they often aren’t the ones financing long term Flex projects. Thus, middle-tier technology choice is often my first clue.

Another is vibe. Does the client sound like someone I’d want to work with? In freelancing, you can be way more forgiving. If the client yells at the designer in front of you and makes her cry, you can usually hold your tongue, knowing you won’t have to work for that mean person anymore who doesn’t respect women in 2 weeks because you’ll be done. For Flex projects that tend to last months, even a year; you’re basically entering a long term relationship. You really need to ensure you both have the same set, or at least mostly common, beliefs. If the client is more interested in getting it done than doing it right, I actually respect this because they believe in making money. Clearly they respect the craft because they are still talking to someone like me who believes in finding that middle ground. Now, keep in mind Jesse Warden is focused on quality first, money second. Others are focused on money first, quality second. It seems trivial, but when this forms the basis of your belief structure, you can get widely different responses on what client is worth forming a relationship with.

For example, if I can tell it’s going to be a staff augmentation job where you’re placed inside a huge company who doesn’t mind if you produce nothing of value for 9 months, most rational company owners would definitely move forward, and ensure more developers could be put on the project. Once you take your cut, you ensure a significant amount of revenue flows your way, AND the risks are low; win win.

Not for me. I don’t want to spend 18 months of my life producing no value for my clients. I didn’t invest 10 years of my life, 18 hours a day, every day honing my craft only to waste it warming a chair, judging the previous vendor’s code base and doing nothing to change it.

That said, I’ve had to lower my idealistic expectations a bit. A lot of large companies who fund the engagements I want to be on often DO want me to produce value for them, they just don’t know how, and it’s just REALLY hard to get message across over a phone call. That, and some of these larger companies don’t run as a dictatorship, and it’s harder to get things done in a democracy.

My dad the salesmen says, “You need to ask them questions.” I’ve taken this a step further and asked them the same questions twice. This can give me insight into their true motives. Some clients really want you to come there, make bling, and help them create awesome software. Others want me to work for free, or at least do the discovery phase for free. The challenge I have is discerning between what the client needs to be educated about, and what they truly believe, and where we can meet in the middle to form a working relationship.

I’m still not sure what’s a good fit, but so far my criteria of ensuring they having money, paying for the discovery phase, and signing Time & Materials contracts is good enough so far; weeds out 90% of the non-valid ones.

Conclusions

I’ve got the initial pitch down. I listen, and ask a ton of questions.

The guys I work with are better at the above than I am. They are, slowly, working with me to better understand who I should focus on, how, and how their SoW formulation process works (because mine clearly doesn’t scale to the Enterprise).

However, because of my personal brand and my vast network, I have an easier time of getting a plethora of leads. Sometimes a hand off isn’t practical, and I need to feel them out directly. Sending a bunch of $30/hr, 2 week, Flash gigs to my partners is just a waste of time. I end up doing a lot of legwork talking to clients, feeling them out, and qualifying them as potential customers. I’ve still got a lot to learn, and feel like a budding AS1 developer.

Another thing that’s extremely frustrating is that my personal brand right now does NOT reflect the clientele I want at all. The honest, edgy, and high strung Jesse Warden is not what Enterprise clients are used to. I’d argue that’s what you need to get anything done there. Once I’m in these companies I can work my magic. The problem is, I’m seen as the medicine they don’t want to take. I’ve had 2 different salesman from a former consulting exclaim how they’d love to have me on a project, but they don’t see how I’d fit. They’ve never seen me on-site with a client, in business attire, having a calm meeting with them working through their issues. What they see is me at conferences rousing with my fellows in the industry, speaking at conferences being “me”, and giving honest accounts of how I do things.

That works great in the freelance game, and even in the consulting firm game, but not in the “I’m my own company” game. Leads keep coming to “jessewarden.com” and contacting me as Jesse Warden vs. webappsolution.com and contacting me as WASI. We’re in a huge rebranding effort right now which I believe will help. Still, it’s effing frustrating.

Tom Link from Universal Mind once told me:

“You don’t hire Schematic to get Schematic; you hire Schematic to get Danny Patterson. Just because you hired Schematic doesn’t mean you get Danny Patterson”.

I’m not sure if it was Danny Patterson or not, but that’s not the point; the point is, I know I’m sitting on a gold mine with my brand, but I’m not sure how to leverage it to make more bling. Many people have been very forthcoming with advice, but none of it seems to work, or I’m just doing it wrong. Many businessman who already make money in Flash/Flex without coding in Flash/Flex, and getting others to code for them, have told me I could be infinitely more rich than they were if I just leveraged my name to bring in business. I’m not ready to do a marketing blitz on WASI just yet; we’re not ready, but I’m not sure what it would do if I did?

At this point, I’d argue that I could only do that doing Agency work because right now, all the Flex clients are either in Manhatttan’s financial sector, or through the magical, and elusive Adobe Professional Services gateway. If I want those types of clients, I’ll have to start watching my mouth, redesign the format of my blog, and start playing the game differently; “clean up my act” as it were. I’m not yet convinced I need to do that.

However, I’m a little frustrated I’ve spent years curating (buzzword bingo, WIN!) my personal brand only to have it cap out at some dollar amount. Eff that. I recognize if I want to make bling, I’ll eventually have to stop coding, and get others to code for me. Fine… but right now, I can’t seem to score the bigger clients. I know we’re in a recession, and even if the big clients have money, they won’t spend it. Those who typically just get a loan now, can’t. I get it, I really do; I recognize I need to use context in understanding the current economic climate and it’s affect on rates, and frequency of work. Our client sales cycles have tripled in the last 2 years because of it. Clients still are signing, it’s just taking longer.

That said, people still buy Porches during the recession. I just want to know how to get them and stop wasting my time with these damn recruiters that never give me anything of value, nor these small potatoes Flash gigs. My dad gets mad when I ask him advice for this, and threatens to start working for me. I don’t work with family. However, at this point, I’m uber close to start focusing 50% of my attention on hiring a salesman, because this is ridiculous. Maybe it isn’t ridiculous, and it’ll soon be great, it just sucks now cause I suck at it. People on Twitter have suggested I’m great at scoring the lead + the initial conversations, I just need to hire a closer. :: shrugs ::

Download

References:

• Swf2XNA
• Port Flash Games to XNA a lot Faster
• Getting Started with XNA
• InfoQ: State of the Art in Enterprise Flex Frameworks
• Apparat
• Hobnox Online Audio Tool
• FITC San Francisco – Flash & Flex Conference
• 360Flex – Flex Conference in DC | Register Now!
• Jesse Freeman
• Follow Jesse on Twitter
• Flash Art of War
• Personal Site

Beer:

Heavy Seas: Smoke on the Water – Beer Advocate | Brewery