Is Good Code Impossible? Part 2: Project Manipulation Patterns

August 4, 2010 John Blanco Methodology

This blog is the second part of my post, Is Good Code Impossible?. In it, I go through a case study of a project with “Gorilla Mart” that illustrates how difficult it is to maintain good coding practices in contract- and commercial-based software.

I’ve gotten a lot of feedback on Part 1 of this blog series and quite a few of you have been quick to lay blame on the developer, while the rest have sympathized as having been there before. You’re all right! And what I hope to lay out for you now is not some generic contracting checklist we’ve seen a million times, but for once begin to outline a very clear, clever, and repeated strategy that clients will use to manipulate a project. When we’re all done, we’ll tie it all back to good code and why it’s so difficult to execute on it and how we *CAN* change things to make it possible once more.

Oooooooooh it sounds cool, let’s go!

The Basic Project Manipulation Patterns

The client is bright. You, the developer, are also bright. Two smart entities should be able to run a project that’s smooth and free of problems. But, we know that never happens! So, why not? Well, the reason is that the client and developer are not on the same side. Neither is good or bad, but both are expectedly self-serving.

The developer’s goal is to either finish a flat-rate contract under-time or up-sell features for an hourly-rate job. In either case, profits are maximized. When a project has risks, the developer hopes those risks are unfounded. If new technologies are required to complete the job, the developer holds hopes that their inexperience in those areas does not cause delays. In summary, the developer wants maximum money for minimum work.

The clients’s goal is to get the most work possible from a flat-rate contract or get the most work done in the fewest hours for an hourly-rate job. They expect bug-free code — done fast! They want the project to be done on time, preferably early, and have their product (A) making them money right away and/or (B) be able to bring it in-house to plan out future money-making updates. In short, the client’s goals are the exact opposite of yours.

Now, think back to every project that didn’t go as planned. You’ve no-doubt taken a host of lessons from these: maybe you didn’t nail down the requirements well enough, you mis-estimated the client, or perhaps there were too many bugs and you spent too much time fixing them to cut a good profit (i.e., your hourly rate dropped too much). Think about each of them. And, if you do, you’ll realize that there are several patterns that emerge.

Yes, patterns. Like design patterns. What I’m about to tell you is that clients have a set of patterns, strategies if you will, to meet their goals for a project. So let’s do this thing — we’re on to you, fellas! Let’s reveal the client gameplan!

False Representation

The next time you’re establishing a contract with a new client, pay attention, because this one *ALWAYS* happens. Here’s how it’s done.

The client contacts you with a project proposal. The project is “pretty straightforward” or “simple.” All you need to do is maintain a list of ___________ that you retrieve from a server they already have. Or maybe they “have a guy” who can do it in no time. The user does a few “basic” things and there ya go, the app is done. They might need a “couple of extra features” but “for the most part” that’s “about it”.

Sound familiar? Of course it does.

False Representation is the client’s tactic of delegitimizing the project’s complexity. You’ll be led to believe that the work is simple and if you don’t think it’s simple then you’re probably not cut out for the job. The macho pride that is the hallmark of every quality developer is a strength that is manipulated into a weakness in such a way that would make Karl Rove proud. (From his rotting, underground lair.) To be honest, clients may not even realize they’re doing this. All they want is get you to quote a cheap price. You can’t blame them, really. It’s their job.

One of the worst cases of this I’ve ever seen happened when a Network Diagnostics company came to us about re-implementing their Java-based application in Flex. The pitch was classic False Representation:

What we need is a simple port of our application from Java to Flex. We understand that Flex applications can be built much quicker and, since the application already exists, we won’t even need requirements. Nothing complicated. We’ll arrange for each of you to have a copy of the application and the source and we’ll have a small team available for consulting. It should be a piece of cake for you guys.

The sign that you’re getting hit with this tactic is the soothing language. Everything will be simple. The app is very straightforward. These guys even went the Full Monty on us and presented one of the most misleading tours of their product imaginable: they showcased the two main screens of the applications, discussed the behavior, and called it a day.

I wasn’t part of that presentation, but the initial SWAG was made based on it. After I joined the team, another presentation was made before kicking off development. Screen after screen after screen after screen…it was endless. Where developers were previously convinced that the other screens were very much the same, the client had not let on that the data and behavior were completely different — and there was a LOT of data, and it all required more custom behavior. After the meeting I was like, “You guys think this is two months?” and they explained how they hadn’t seen 85% of the stuff they just saw.

What was initially SWAG’d as a two-month effort took us a full year. The lesson here is that when discussing requirements with the client, either at introduction or in a formal analysis session, *IGNORE* their vocabulary. If the client thinks a feature will be easy to implement, ignore them. Evaluate it on your own. And if they’re demo’ing an application, keep a keen eye out for every menu item, every view, every corner and crevice of that application. And get a copy to play with yourself before you SWAG anything.

It’s a Bug, Not a Feature!

A favorite joke amongst developers is to be presented with some of the strangest, buggiest behavior in our code to which we reply, “That’s a feature!” While it’s just a joke for us, the opposite phrase will be a favorite of your clients’ — and it ain’t gonna be a joke to them.

The basis of It’s a Bug, Not a Feature! comes in the root philosophy of flat-rate contracts. The idea is that you are guaranteeing a set of functionality in exchange for a sum of money. The expectation is always that this functionality is only considered complete when there are no significant bugs included in it. The problem is that I have never, ever seen any language that defined exactly what constitutes a “significant bug” included in an SOW (Statement of Work).

Have I seen some language on it? Sure. Not always, but on occasion, yes. But it’s certainly not the kind that a lawyer has gone through. The difficulty is that bugs come in so many shapes and sizes, it’s simply impossible to classify them well. On top of that, as a developer, you will be inclined to win some equity from the client by fixing some bugs you wouldn’t otherwise need to. (Yeah, the easy ones, but still, they don’t know that, and you’re doing it for free anyway so you should get credit, right?)

What occurs is a tango between client and developer. The Tango Cod-ing. (Any Rent fans in the house?) Once the client starts receiving builds, the dance music begins. These buttons should be a darker shade of blue. You didn’t specify they should be skinned. Yes, but I can’t see them. Skinning them wasn’t in the contract, and I can’t draw. But, if they don’t stick out to the user, the app is broken. It’s a bug. Fix it or you don’t get paid!

It’s my belief that it’s the developer’s experience that determines the effect this has. The experienced developer is adept at identifying where a client has misunderstood what they themselves say they want. These developers have gained a feel for where the problems will be later and either (A) address it during the requirements gathering phase or (B) forsee it and code it the right way anyway. They know that they have gone against the will of the client, but they’re also confident they know it’s what they’ll want.

Experience can’t be bought. The less-experienced developers will have to fight clients on these issues for a while before that intuition builds up. If you find this is happening to you, you can combat it somewhat by being more proactive with the client. Be pushy on their desires if you feel they will dislike their own idea later. Trust yourself. It’s what they’ve come to you for. Tell them why. Don’t be afraid, the client wants someone who can guide them. It will boost your credibility and ease your workload!

Deadline Shoveling

This is the one that sometimes makes me want to simply leave the industry entirely. :-) Tell me if this sounds familiar…and you don’t even need to be on a contract to have it happen…

You’re working on a 3-month project and there’s a week left. You’re excited! All the hard work is about to pay off in a released product. It’s going pretty well, but you have a little more work than hours available so you’re going to have to put in some 10 hour-days (at least). Monday, Tuesday go by and you’ve worked 21 hours. Wednesday you put in some serious crunch time and work until 2 AM. Thursday you still manage to push out a 9 hour day before heading to sleep early, but things look good for Friday! Friday comes and at about 10 AM you are pulled into a project meeting:

Jim just got off the phone with Bob and he said he wants to add a new screen that allows you to rotate the interface in 3D space. They can push the deadline a few days, but they really need to have it by Wednesday because there’s a tradeshow on Thursday and they really want to show this feature off to the industry drivers.

I really don’t know if these tradeshows exist, but they come up quite often, eh? It’s a great way to specify a deadline and not have to negotiate it. The client says they’d loooooove to give you more time, but the tradeshow can’t be pushed back. And now your manager has no room for negotiation. They want to keep the client happy and there doesn’t seem to be room for compromise. The killer feature the client decided 5 days in a advance simply had to be completed has to be shown off at the immovable tradeshow. And if the client were to become unhappy, at the last minute, your manager’s manager may not be too please come promotion time.

So, you have to kiss that weekend plus a comp’d Monday goodbye (no more Vegas!) and you put in 15 hours on Saturday and Sunday and a massive 26 hours Monday and Tuesday and you’re tired. But the code is in place — though it ain’t pretty. But, you’re done.

Wednesday comes, hold the phone. The design isn’t gonna fly. They’ve decided not to show it off at the tradeshow, but now they want to do a presentation for the CEO first-thing Monday morning. And guess who has to fix the design?

Don’t laugh, and don’t point fingers! This happens all the time! It transcends development, this is about business. Keep the client happy and future work will come. It’s justified by the fact that the project is almost over. It always seems to happen (to varying degrees) and it’s brutal. I was once on a project that had done this for months, sans the huge hours. After 4 months of having a deadline pushed at the last minute, I simply didn’t care anymore about the product. I hoped it would succeed, but I really didn’t care anymore. It’s massively demotivating. Development is about setting a goal and getting it done and celebrating the accomplishment. If you pull out the accomplishment, it’s just work. Never-ending work.

The only way to fight this is with good management. In many cases, this isn’t going to be on you. Your representation has to fight for you, and this may or may not happen depending on who it is doing it. Be sure to communicate the time you’re putting in and the de-motivation. Make it known that you want clearer milestones, that you are willing to do more work in a proper timeframe, but you need a realistic goal, predictibility and more trust in the client if you are going to create a great product.

Now Let’s Get Back to that Good Code, Shall We?

So how does this all relate to good code? Well, my gosh, it has everything to do with it! Look, you’re a developer capable of writing good code. How do I know? You wouldn’t even be reading this if you weren’t! How many happy-to-be-a-lacky developers will read an article about “good code?” None, that’s what. But *YOU* want to write good code.

Can you? Not if the client is pulling these shenanigans!

Get familiar with these tactics, learn how to prevent them, and you’re going to open yourself to a freer world of time and expectations. In that environment, you can take the principles your favorite authors have taught you and fulfill the implementation of a world of good design. With good project planning, minimal surprises, and creating a good pace with your team you can hit all of your milestones coding the way *YOU* want to be.

Good luck out there!