We need pigs not chickens

The PE Funcast is a team of readers. We fly through books. Lots of books.  Not just business books and technical books, but novels and short stories, newspapers, even some comic books—-We highly recommend Usagi YoJimbo.  Urban legend has it that Warren Buffet and his longtime business partner, Charlie Munger, try to read an hour each day and that’s as good a reason as any to pick up a book.  We read because we love to and we read because there are tons of people out there that know more than we do about lots of different things.  It's the same reason that we listen to lots of podcasts too.  We read on planes and trains, and we listen to podcasts in cars.  We get lots of interesting ideas from reading, and this post is one of them.   

I recently finished Duff McDonald's The Firm: The Story of McKinsey.  The book got mostly positive reviews on Amazon--3.9 stars out of 5 as of this writing—-but it was the subject that caught my eye.  McKinsey is considered to be "the" name in strategic consulting, an industry that is very intertwined with private equity. Whether every vignette in McDonald's book is true or not isn't relative to this piece.  It was enjoyable to read and provided me some fascinating insight into McKinsey and their ilk, and into the strategic consulting business.     

McKinsey is famous for a particular discipline: "Never taking credit" and "Never taking the blame".  They provide strategic advice upon which the client can choose to act or not.  Sometimes their advice was good and sometimes it was bad. (Read the chapter on Enron for more details on the bad advice.) For those of us that live and die in working with smaller companies, the McKinseyites and their kind are, as Phil Connors would say, "a colossal waste of time".  Smaller companies need partners that are as committed to the solution as we are. As the saying goes, "when it comes to breakfast the chicken is involved but the pig is committed".  

We need pigs not chickens.  

I am not saying that smaller companies don't EVER need help with strategic decisions. I'm saying that more often than not they need help EXECUTING on strategic decisions, not getting consultants to MAKE their strategic decisions for them.  

If you read the McKinsey book you will certainly get an appreciation for where they can (and have) added value. Historically it has been very large companies that were hamstrung by indecision or political issues in the "C" suite.  McDonald's book provided a balanced view of McKinsey and their value in this regard. However, at our end of the market we just don't see these same types of problems -- and we certainly don't have the EBITDA to absorb the massive fees that these consultants charge for their services.  McKinsey famously doesn't keep track of hours, and merely presents an invoice that they deem to be "fair" for the work performed.   

We get cold calls from the high-end strategic consulting firms all the time. Some of the biggest, most successful, private equity shops are big users of the McKinseys of the world; some even have their own in-house mini-McKinseys at their disposal. Most strategic consulting groups view private equity groups as a terrific target market: You sell me on how smart you are and I turn around and jam you and your $2500+ per day down the throat of my portfolio companies.  Portfolio company managers will figure it's the cost of having a private equity partner involved in their business, shrug their shoulders and deal with it.   Then your strategic consulting firm bills a bunch of hours, makes a bunch of non-binding recommendations and takes the private equity partners out for a nice golf outing once a year.  

I don't golf. 

C-Suite executives at our companies are rarely at a loss to determine strategy. They are often at a loss for good, effective, tactical consulting resources that can help them to implement their strategy.   And that isn't to say that all strategy consulting is bad.  We get tons of value within our portfolio from Gartner Group technology research, at a price well below the standard daily rate of McKinsey-style consulting.  

Larger corporations have different problems; problems that may be better solved via independent third-party consults like McKinsey.  What makes a problem strategic?  Let's take some examples straight from McDonald's book: CEO succession planning, matrix management of staff, large-scale acquisitions or divestitures, designing sophisticated financial structures or entering entirely new markets.  

We don't have these kinds of problems in our market.  CEO succession planning?  We don't have dozens of divisions with trusted lieutenants that are vying to move up into the big chair.  When we buy a company we are most often buying it from a founder who already has a COO ready to step into the big chair. If they don't, and they don't want to run the day-to-day business anymore, then we are coming to the table partnered with a CEO to run the business post-close.  

Matrix management? We never have a management bench large enough that a single employee is reporting to multiple managers. In fact we are often tasked with recruiting new managers to fill key holes in the team. We need head-hunters, not consultants.  

Our companies make tuck-in acquisitions.  Small competitors or tangential technology pieces that fit into the grander scheme of things.  We aren't looking at large-scale mergers with other billion dollar companies and trying to figure out integration and redundancy plans.  Likewise, we don't have billion dollar divisions that we'd like to spin-off into their own publicly traded entity.    

We do make use of state-of-the-practice financial structures to minimize the tax burden for our selling founders. But we aren't designing sophisticated holding structures and off-balance sheet subsidiaries à la Enron and their ilk.  

If we are entering a new market, we are following a Geoffrey Moore model and moving to a parallel "bowling alley". We don't need help identifying these markets or understanding the concept of "the bowling alley".  

Our companies often need consultant/contractor hybrids.  Folks that are both capable of providing some experienced advice but are also capable of getting their hands dirty; folks who are committed instead of just involved.  We are happy to give you the credit; we just want to get the work done.   

Contractors are people too

If you are a lower middle market company that is implementing a new customer relationship management system (CRM) or enterprise resource planning (ERP) system, chances are pretty good that you are using some third-party consultants.

This holds true beyond the realm of CRM and ERP implementations as you might be using consultants or contractors for some custom software development as well. But it is almost a necessity when you are implementing somebody else's software stack. 

Anytime that you are working with third-party technical contractors there is always room for disagreement.  You can be buried in a sea of change orders; the consultants may lack all of the necessary skills or have communication problems.  Your team's personalities might clash with their personalities.  Each project brings its own sets of unique challenges. 

In my experience, however, there is one problem that ALWAYS crops up in these projects and it's the one problem that most CEOs and Founders least expect.  It's a problem of expectations, specifically the expectation that your consultants are going to work like dogs to get your project done. 

Let me explain. 

In the normal cycle of things your internal technical team probably puts up a fair amount of unpaid overtime.   I've seen the question asked on Quora: "How do I MAKE technical people work overtime?"  It's an idiotic question.  You can't MAKE them.  However, technical people, like me, often work overtime because we truly love what we do.  To us, solving complex technical problems is interesting work.  For example:  I've been up since 3:30 am today working with one of my teams on a software launch. We made the decision to delay the launch until tomorrow at 3:30 am after we uncovered some things in the launch process that we didn't like.  I was working until 11 pm last night along with team, we took a short catnap and then hit it 3:30 am.   I'm cooling my heels, drinking Starbucks and getting ready for our 10 am status call -- so I decided to crank out this post. Is it overtime? Definitely. Do I mind? Definitely not.   

The team and I have been burning the midnight oil for a few weeks now to get past a big launch date.  However, once we get through this process I'll need to make sure that the team dials it back for a few weeks—Go home early, play with the kids, hit the gym, get your car washed, whatever.  The point is that it is vitally important that the team gets some mental rest or they won't be prepared for the next little window of scrambling.  Even if they want to keep scrambling I need to help them help themselves by forcing them to "shift it to glide" for a while. 

So what's the problem here?  The problem, folks, is that you CAN'T work your short-term consultants and contractors like this.  Why you ask?  Because, while your team is catching their breath, your consultants are likely off working at the next company.  This is particularly true for "specialists" that are working on a rotating cycle for several customers at once.   If every one of their customers expects them to go the extra mile each and every day these folks are NEVER going to catch a break.  This leads to contractor burnout, which is why consultants turn over so often.  This in turn means that the next consultant that you get does not have as much experience and you need them to work harder -- it's a vicious circle.  Never mind that these poor folks are staying in a hotel every night, away from their families and pets.  

Side note.  The next person that tells me that traveling for work is glamorous is going to get punched in the schnozz.  End of side note. 

It's a matter of setting expectations—your OWN expectations—and this is a very, very hard thing for most CEOs and Founders to do.  You have a passion for your business and you expect EVERYONE around you to share that passion.  Unfortunately it does not work that way.   

So, what can you do?   

Set your expectations lower.  Your consultants are not going work full tilt week in and week out.  And it does not matter how much their company is charging you a day for their services.  

Plan for the project to cost 30% - 50% more than you've budgeted from a services perspective.  That does not mean that you have to spend that money, but you don't want to run out in the middle of a project.  

Don't focus on the "edge cases".  Edge cases are one-off pieces of functionality or workflow that happen a very small percent of the time, but often require the most effort.  This is a meaty topic; one I'll talk more about in a future post.  For now, think of it this way:  Don't try to cover every single scenario the first time through. Focus on the 80%.  Leave the edge cases in the parking lot.  This is probably the most important suggestion I can make.

Beware of the time/functionality continuum.   You can either commit to a hard and fast date on a technical project, or a specific set of functionality, but never both.   If you HAVE to live with a certain go-live date, then you have to be willing to throw luggage from the plane.  On the other hand, if you HAVE to have a given set of functionality in place for the go-live, then you will likely have to be flexible on the date.  I call this a continuum, because it's never a simple case of black and white.  In particular, this often means being flexible on EDGE CASES. 

Having said all this, we work with plenty of consultants and contractors that go above and beyond the call of duty every day. In fact, we are partnered with Virtusa on a web application porting project right now and the very person that kept me up late last night was the one that got me up early this morning.  Ravi, our onsite resource from Virtusa was the last one to bed and the first one back at his computer today. The moral of the story is,  expect your consultants to be great, just don’t expect them to be you.

Just say "No" to sending out an RFP

In my many years working as a Pre-sales engineer for a variety of enterprise software companies the single biggest waste of my time and effort was answering a request-for-proposal (Yes, the dreaded RFP). I am so jaded from my past experiences with RFPs that I strongly encourage my portfolio companies to refrain from the practice of issuing them entirely.  “Why?” you ask.  Because your garden variety RFP is an unnecessary step comprised of useless information.  

On the one side of things you have an enormous list of unprioritized questions put forth by the buyer. It represents a complete superset of every possible feature and function by every single solitary employee of the company from the CEO on down to the second shift janitor. Everyone wants to have their say in the process, but in most cases their feedback is a waste of time.  You end up asking a bunch of questions that having no actual bearing on your business.  For example:  

“Does your software run on Windows 95, Windows XP, Windows 7, Windows 8, Mac OS X, Red Hat Linux, Debian Linux, Solaris, IBM eSeries?”  

Really?  Do you really need to run the software on all of those platforms?  I SERIOUSLY doubt it. A subset of skilled professionals can whittle down a set of products to very short list of best-fit solutions with nothing more than a very concise list of requirements put down in order of priority.  If you must ask, do it that way. Period.   

On the other side of the equation you have the vendor.  As a former representative for a number of vendors I am uniquely qualified to let you in on a little secret.  And here it is.   As a pre-sales engineer for EVERY vendor that I ever worked for, my job was to figure out a way to answer "YES" to every single question on an RFP — regardless of how much I had to stretch the truth to do so.  Here's an example:  

“Does your software run on Windows 95, Windows XP, Windows 7, Windows 8, Mac OS X, Red Hat Linux, Debian Linux, Solaris, IBM eSeries?”

“Yes, by running Parallels or VMWare you can run our software on Windows 95, Windows XP, Windows 7, Windows 8, Mac OS X, Red Hat Linux, Debian Linux, Solaris, and IBM eSeries.”  

What this means is that you can install Parallels and a copy of Windows and then run the software under Windows 7.  So the real answer is "No, we do not run on all of these platforms, we only run on Windows 7.” I wasn't lying in my answer, but I was certainly massaging the truth.  Every single RPF is RIDDLED with weasly answers just like this.  

And why is that, you ask?  It's because the RFP itself is riddled with a million questions that may or may not be critical to the success of the product in your environment.   If you are going to ask me a bunch of inane questions that may or may not mean anything then I am going to turn around and give you back a bunch of vaguely worded answers that allow me to answer "YES" to every question.  As a rep, my goal is to get past the RFP stage and into the face-to-face meeting stage where the REAL selling can begin. Government agencies and purchasing agents at large companies are the kings of issuing RFPs.  And this is EXACTLY why I like working with middle-market companies on the buy side of the equation.   

Let's say that you are a company with $55 million in sales and $10 million of EBITDA looking to move off of QuickBooks and onto a bigger and new accounting platform.  Do you really think that you are going to make a better buying decision by putting together a 500-question RFP and sending it out to every accounting software vendor that comes up when you Google "accounting software"?  You won't.   

Get a small team of people led by your CFO in a room and put together a short list of requirements in priority order:   

- What platform do you want to run it on? (SAAS?  On premises?  Windows? Linux?) 
- What Accounting functions do you need to support (G/L, A/R, A/P, Purchasing, Invoicing)? 
- Budget — how much do you have to spend on licenses and implementation? 
- Lists of any unique functions/features.  

For example, maybe you need to support both English and simplified Chinese for data entry.  You can get the whole thing down to a few simple sheets of paper.  With some simple Googling and conversation amongst your team you'll come up with a list of 3-4 likely candidates in no time.  Call up the vendors, get a demo, and ask to SEE them demonstrate the few unique requirements that are specific to your situation. Get multiple quotes and talk to some references.  Pick one and negotiate a deal.  I guarantee you that these steps will work better and faster than any RFP-based process — and you will save yourself a TON of time.

The "Out-Of-Box Experience" and the Mobile Market

In the old days, companies used to ship you their software in a big square box.  Actually, when I started, the software delivery guys from Digital Equipment would hand-carry the magnetic tapes to you. By the time we reached the PC/Server era, your software would arrive in a massive mailer.  Inside that Costco-sized box was a manual and a compact disk (…okay, okay, it was mostly floppy disks). It wasn't always easy to get a trial version of software because the company actually incurred some real costs in packing and shipping the materials to you. As a consumer, you had to put in work too. You had to march through a phalanx of sales reps and sales engineers in order to get your trial copy.  It was a far cry from today's world, in which you just download the ZIP/EXE/DMG/TAR file from the web site and away you go.    

Once your trial arrived, you'd open the box, install the software and fire it up. We called the period from the opening of the box through the installation, all the way to the first hour (or so) of using the software, by the phrase the "out-of-box experience".  Yes, I know it SOUNDS like some hippy-trippy saying about you becoming one with the cosmos—or an overused company retreat exercise—but that's not what it meant.  When you mentioned the "OBE" you were talking about your initial impressions of the product and the likelihood that you would purchase it.  

If the product put a smile on your face during the installation and first-use, it had a "positive" OBE. Products that were difficult to install, were difficult to use at first, or were just plain ugly to look at (bad colors, bad fonts, busy screens) were said to have a "negative" OBE.  After all the work that went into just getting the trial software into a customer’s hands, a bad OBE could be a real killer.

Having a bad OBE can kill you in today's universe too.  

These days, expectations are higher particularly in the mobile apps sphere. Serving up a lousy web page is a bad idea, but it's not necessarily fatal. It does not cost you much to surf to a lousy web page; you don’t actually have to download or install anything. Will you go back to a bad web site? Maybe. 

Mobile apps are a different beast altogether. I tend to get mightily perturbed when I go to the trouble of downloading and installing a mobile app and it's terrible. I get particularly angry if I also have to create some sort of web account to go along with it on the back end. A bad OBE means that I might delete the app in question and never try it again. 

So the question becomes, do you risk putting out a mobile product with a clunky OBE in the middle market? Despite my previous remarks, my answer is a guarded YES.  If you are technology company in the middle market with solid customers in a defined niche, it is a bigger risk to get to the market late.  Go early and iterate, rather than wait until your app is “perfect”. Your customers are with you anyway and, while they might not love a clunky OBE, they will live with it. They are likely to be more unsettled by the lack of a product on your part, particularly if your competitors have a mobile product in play.  

However, if your FIRST product is a mobile product then my advice is the opposite.  Your OBE had better be killer or you'll get deleted and never re-added.  

Hire developers that understand mobile (iOS, Android) and your first product will be more likely to have a decent OBE, even if the software lacks a ton of functionality. Shoot for a minimum of features, make it run fast and keep it as error-free as possible. Apps with tons of features tend to have lots more errors that jump out at the user. Since you aren't likely producing a game app, your mobile software will need to connect to your backend systems--upping the potential for errors (limited signal coverage, data synchronization issues, etc). A fairly simple app, with clean graphics, that runs fast and relatively error-free is a good start.

We may be years removed from the literal box, but the OBE is still very relevant. The appearance and ease of use of your mobile product (or website, for that matter) communicates its quality to your customer. You are asking them to expend their time and effort to acquire and install your app--or worse, to discover that it doesn’t exist--so it’s up to you to make that effort worthwhile.

A Helping Heap of Technical Debt

I was talking to a founder about a process for working down their backlog of technical debt when it dawned on me that many business owners might not actually understand the concept at all.

Consider your car.  Most cars require you to get the oil changed every 3000 miles or so.  Once you get past 3000 miles you start running the risk of having problems.  Maybe you won’t see a problem right away, but somewhere down the line you might end up with a mess.  The longer that you wait to change the oil, the greater the risk becomes and the more near-term it gets.  

Technical debt is nothing more than required maintenance of a piece of software, like changing the oil in your car.  The difference is that the technical debt is coming from three directions: 
 
1.    External Influence — Your technology partners and suppliers.  Every time that they make a change to their software, they are adding technical debt to your software.  When Oracle releases version 12 of their database software, you inherit the technical debt of updating your database from version 11.  You don't have to do it right away, but you are going to have to do it sooner or later.  The longer that you wait, the more difficult it will be.  If you wait until Oracle ships version 13, you could end up in big mess.  We'll talk about this kind of technical debt in more detail in a subsequent post.  
2.    "Fashion” — Trends come and go in the technology business.  
For example, at one point technologists had the idea that putting all of your business logic into your database was the smart thing to do.  A few years later, they changed their mind.  As technology trends move out of fashion you, the business, are stuck with the task of removing these older designs out of your code line.  
3.    Internal Influence — Your own development processes and the changing business requirements of your software. 
For the remainder of this post we are going to talk about just this sort of technical debt - let's call this internal technical debt.   

Internal technical debt is a backlog of software maintenance that you have built up all on your own.  Executive management, product management and software engineers all contribute to the problem.  This probably sounds confusing to you. After all, how can you build up your own technical debt?  It's easier than you think.  To show you how, let's use a fictitious, but realistic, example of business logic.   

Let's say that you have a web ecommerce platform with an electronic shopping cart that your customers use to buy your product.  Early versions of this software allowed users to add products to their cart and make purchases by entering a credit card.  Simple.  

At some point, somebody in the company gets the clever idea to add a discount code for the upcoming holiday season to drive a little extra business by encouraging your customers to speed up their purchases.  Sounds like a great idea. At this point your team may not have a fully fleshed out idea of what the "discount code" should do.  However, since you had embraced a "ship and iterate" mentality, you might pull a basic storyboard together and dive in.   

[Now clearly I am being a little tongue in cheek.  It's never this bad, but I am simplifying the process a bit in order to tease out the core of the problem.  So I am asking for a little liberty here.]

Let's say that you call this new feature DiscountCode, and your team agrees on a basic set of features:  
- A discount code field will get added to the checkout screen 
- The discount code itself is a string called "HOLIDAY2014" 
- The server-side code will look for HOLIDAY2014 and subtract 10% from the order  

Engineering starts cranking out the code and the test cases.For the purposes of our little tale, we'll ignore the client-side code and just concentrate on the server code.Engineering adds the following code to the checkout layer: 

/*
** ... Checkout code
*/

IF (@V_DISCOUNTCODE == "HOLIDAY2014")
{
@V_TOTAL_SALE = @V_TOTAL_SALE - (@V_TOTAL_SALE * .10);
}

Simple, really.  If the variable @V_DISCOUNTCODE is "HOLIDAY2014" then we take 10% of the @V_TOTAL_SALE.  [Once again apologies for this psuedo-code. I’m going for simplicity here, not precision.]  

So far, so good.  This is a pretty simple change and, while it’s maybe not that well done, we haven't really disrupted the applecart so far.     

Now let’s say you realize that you shouldn't be enabling the discount code right away — after all, this is supposed to be a holiday promotion.  So you make a simple change:  

/* 
** ... Checkout code 
*/

IF (@V_DISCOUNTCODE == "HOLIDAY2014" and @SYSDATE BETWEEN "2014-11-28"
 AND "2014-12-31") 
{ 
@V_TOTAL_SALE = @V_TOTAL_SALE - (@V_TOTAL_SALE * .10); 
}

Still okay, we dodged a bullet there.  Let's say that our little promotion worked pretty well.  So we decide to add a first-quarter promotion in order to spark up the post-holiday sales. We'll make this one a little more aggressive because the first quarter is usually soft.  

/* 
** ... Checkout code 
*/

IF (@V_DISCOUNTCODE == "HOLIDAY2014" and @SYSDATE BETWEEN "2014-11-28" 
AND "2014-12-31") 
{ 
@V_TOTAL_SALE = @V_TOTAL_SALE - (@V_TOTAL_SALE * .10); 
} ELSEIF
(@V_DISCOUNTCODE == "1STQTR2015" and @SYSDATE BETWEEN "2015-01-01" AND "2015-03-31") 
{ 
@V_TOTAL_SALE = @V_TOTAL_SALE - (@V_TOTAL_SALE * .15); 
} 

We've got to keep the old code in there, even though it's not valid, because we might need to go back in time to understand why holiday sales in 2014 had a discount.  

[Once again, a small aside in the hopes of avoiding a flame-war here.  Yes, most developers wouldn't be this sloppy.  They would log the data. They could update the source and remove the old code, knowing that their version control system would track the changes.]  

By the end of the year we've ended up with several more simplistic promotions as follows: 

/*
** ... Checkout code
*/

IF (@V_DISCOUNTCODE == "HOLIDAY2014" and @SYSDATE BETWEEN "2014-11-28"
AND "2014-12-31")
{
@V_TOTAL_SALE = @V_TOTAL_SALE - (@V_TOTAL_SALE * .10);
} ELSEIF
(@V_DISCOUNTCODE == "1STQTR2015" and @SYSDATE BETWEEN "2015-01-01" AND "2015-03-31")
{
@V_TOTAL_SALE = @V_TOTAL_SALE - (@V_TOTAL_SALE * .15);
} ELSEIF
(@V_DISCOUNTCODE == "2NDQTR2015" and @SYSDATE BETWEEN "2015-04-01" AND "2015-06-30")
{
@V_TOTAL_SALE = @V_TOTAL_SALE - (@V_TOTAL_SALE * .10);
}ELSEIF
(@V_DISCOUNTCODE == "3RDQTR2015" and @SYSDATE BETWEEN "2015-07-01" AND "2015-09-30")
{
@V_TOTAL_SALE = @V_TOTAL_SALE - (@V_TOTAL_SALE * .25);
}

Sales decides to get cute in the fourth quarter and add several different holiday discount codes in order to REALLY spice up sales.  For the day AFTER Thanksgiving they get a 15% discount, on Cyber Monday they get 25% and then after that the discount code drops to 10% until the end of the year.   

/* 
** ... Checkout code 
*/

IF (@V_DISCOUNTCODE == "HOLIDAY2014" and @SYSDATE BETWEEN "2014-11-28"AND "2014-12-31") 
{ 
@V_TOTAL_SALE = @V_TOTAL_SALE - (@V_TOTAL_SALE * .10); 
} ELSEIF
(@V_DISCOUNTCODE == "1STQTR2015" and @SYSDATE BETWEEN "2015-01-01" AND "2015-03-31") 
{ 
@V_TOTAL_SALE = @V_TOTAL_SALE - (@V_TOTAL_SALE * .15); 
} ELSEIF
(@V_DISCOUNTCODE == "2NDQTR2015" and @SYSDATE BETWEEN "2015-04-01" AND "2015-06-30") 
{ 
@V_TOTAL_SALE = @V_TOTAL_SALE - (@V_TOTAL_SALE * .10); 
} ELSEIF
(@V_DISCOUNTCODE == "HOLIDAY2015") 
IF @SYSDATE is "2015-11-27" 
{ 
@V_TOTAL_SALE = @V_TOTAL_SALE - (@V_TOTAL_SALE * .15); 
} 
ELSEIF @SYSDATE is "2015-11-31" 
{ 
@V_TOTAL_SALE = @V_TOTAL_SALE - (@V_TOTAL_SALE * .25); 
} 
ELSE 
{ 
@V_TOTAL_SALE = @V_TOTAL_SALE - (@V_TOTAL_SALE * .10); 
} 
}

By the first quarter, you might decide to add discount codes for certain products, or only for certain classes of customers.  This is when things start to get really hairy:  

/* 
** ... Checkout code 
*/

IF (@V_DISCOUNTCODE == "HOLIDAY2014" and @SYSDATE BETWEEN "2014-11-28" 
AND "2014-12-31") 
{ 
@V_TOTAL_SALE = @V_TOTAL_SALE - (@V_TOTAL_SALE * .10); 
} ELSEIF
(@V_DISCOUNTCODE == "1STQTR2015" and @SYSDATE BETWEEN "2015-01-01" AND "2015-03-31") 
{ 
@V_TOTAL_SALE = @V_TOTAL_SALE - (@V_TOTAL_SALE * .15); 
} ELSEIF
(@V_DISCOUNTCODE == "2NDQTR2015" and @SYSDATE BETWEEN "2015-04-01" AND "2015-06-30") 
{ 
@V_TOTAL_SALE = @V_TOTAL_SALE - (@V_TOTAL_SALE * .10); 
} ELSEIF
(@V_DISCOUNTCODE == "HOLIDAY2015") 
IF @SYSDATE is "2015-11-27" 
{ 
@V_TOTAL_SALE = @V_TOTAL_SALE - (@V_TOTAL_SALE * .15); 
ELSEIF @SYSDATE is "2015-11-31" 
{ 
@V_TOTAL_SALE = @V_TOTAL_SALE - (@V_TOTAL_SALE * .25); 
} 
ELSE 
{ 
@V_TOTAL_SALE = @V_TOTAL_SALE - (@V_TOTAL_SALE * .10); 
} 
} ELSEIF 
(@V_DISCOUNTCODE = "1STQTR2016") AND (@SYSDATE BETWEEN "2015-01-01" AND "2015-03-31") 
IF (@V_CUSTOMERCLASS IN "1,3,12") 
{ 
@V_TOTAL_SALE = @V_TOTAL_SALE - (@V_TOTAL_SALE * .15); 
}
ELSEIF (@V_CUSTOMERCLASS IN "5,6,18") 
{ 
@V_TOTAL_SALE = @V_TOTAL_SALE - (@V_TOTAL_SALE * .17); 
}
}

While I could carry this problem out to its bitter end, let's stop right here. I’m already cross-eyed anyway.

You can see from the preceding example that the code still works, but it is going to get harder and harder to debug and maintain.  Somewhere along the way your development team is going to tell you that they should probably build out some database tables to hold discount codes, effective dates and values — and maybe some subtables for customer class codes and product class codes.  They'll also need some cycles to build out some user-interface panels for sales to use when entering and updating codes.  

The important thing to note here is that a very simple requirement, providing discount codes, has snowballed into a much more complex beast.  And while your real development team isn’t likely to try to implement a discount code in the imbecilic manner that I used here, the reality is probably closer than you think. Especially in the middle market.  Your understaffed development team probably scrambles to implement a lot of "specials" on an ongoing basis.  Over time all of these little hacks and sub-optimized code processes build up on themselves.  Eventually, you are going to need to fix it.  And that, friends, is the nature of technical debt.  

Almost every major component of every system that you write is going to end up generating some self-imposed technical debt.  And at some point you are going to have to pay that piper.  It's easier to do it a little at time, chipping away at the backlog of technical debt with each release cycle.  When you fail to do so you almost always end up in the dreaded "re-write" penalty box. Complete re-writes are generally a mess of galactic proportions and you’ll be MUCH happier if you choose to avoid them altogether.