It's been a while since I've done one of these.  I wish I could say that it was because the bucket was running low, but it's not.  Unfortunately, most of the examples that spring to mind lately are a tad too personal to vent them in public (right now), but here's a solid, non-offensive practice you can implement to insure the complete and utter failure of your software development company.

"I need subcontractors.  Lots of subcontractors."

So you have some money in your pocket, and you want to spend it on software development.  You have a few options:

1. You could buy the things your in-house developers have been pestering you about, like chairs that aren't broken, monitors that don't flicker so badly that they cause seizures, and "workstations" that you didn't buy surplus from the government five years ago. 
2. You could hire additional developers.
3. You could actually pay overtime for those "rare" weeks where there seems to be more to do than the team can accomplish during a 40 hour week.
4. You could maintain the status quo a little longer.  If things are tight, the extra money can be used to maintain existing staff and resources for longer.
5. You can bring in consultants and subcontractors.

Let's weigh the pros and cons of each.  With option 1, the developers get better equipment, but how's that going to make you money?  It's not.  The quality of the equipment has absolutely nothing AT ALL to do with developer productivity.

With option 2, you would be bringing on more people, which means you would be spending more money (and that's good, because you have to spend money to make money). 

Concerning option 3: HAHAHAHAHAHAHAH, yeah, overime, hahahaha, right.

Option 4 is just dumb.  Money is like a hot potato, you want to get rid of it as quickly as possible.

Option 5 sounds interesting.  Again, it would involve spending lots of money, which automatically guarantees making lots of money.  This is actually a better choice than option 2 for two reasons: consultants and subcontractors are (usually) more expensive than direct hires, therefore the quality of their work will be superior.  Second, because they are more expensive, you will spend more money faster, which means you will make more money and get rid of the hot potato sooner. 

So, let's go with option 5.  You want to find the most expensive subcontractors or consultants that you can.  It doesn't matter if they are not experienced with the type of software you are building, because consultants are expensive and therefore always contribute a lot of value.  Be sure not to pay any attention to things like previous projects, or even whether or not they are familiar with the tools and languages that your company uses.  Code is code, after all, everything just works when you pile it all together.

Once you have brought consultants on board, it is very important to let them drive the process.  It doesn't matter if your developers have an existing "methodology" (whatever that is); just do whatever the consultants say!  Remember, you are paying them more than your developers (hopefully more than all your developers combined), so they are smarter than your developers. Be sure not to try to give the consultants any firm deliverables or requirements.  You don't want to chain these people down, you want to hitch your company to them and let them pull your software development up to the stratosphere of success!

Concluding Remarks

There are situations where consultants and/or subcontractors are very, very useful.  For example, maybe your team needs an installer for a project, but no one on the team knows anything about installers.  Instead of investing effort in mastering a technology that you may not have much use for, it may be better just to pay someone else to build the installer for you. 

However, there are many times when bringing in consultants is the completely wrong choice.  For example, you don't have much need for them early in a project.  The early stages are to figure out roughly what you're actually going to build, and consultants (unless they are experts in whatever market the project is targeting) aren't going to contribute much.  You also don't want to bring consultants in unless you have a very clear, specific need for them.  Don't bring them in to do general work that your own developers can do.  If your developers are overworked, bring on additional full or part-time staff, not a long-term consultant or subcontractor.

If you do decide to bring a consultant in, agree on specific deliverables and hold the consultants to them.  Charging a lot of money is not an excuse to under-deliver.  If things aren't working on, cut ties as soon as you can.  Be careful with how any contracts are worded, too.  You don't want to get tied in to a relationship that isn't beneficial to your company.  Keep the scope small, focused, and specific.  Do that, and you might be ok.  Do it not, and you are probably going to have problems. 

Oh yeaaaaaaah!

It's Friday, and even though I'm busy as all get-out (which is actually related to today's HTRASDC article), I'm going to bestow  the greatness of my writing upon your face.  Enjoy!

Do everything at the last minute

Failure to plan == planning for success, or at least that's what I've heard from this homeless guy that I pay to wash my car every other week.  If there's one thing I know for sure, it's that planning is a complete waste of time.  As we have established, your software developers are lazy slackers.  They're not doing anything constructive, so it's no big deal if you want to spring something on them at the last minute.  They'll actually appreciate it, because random surprises like that keep life interesting. 

So, let's say, hypothetically, that you find out that there's a business opportunity that requires your company to produce some deliverable in order to get money.  Let's say that the deliverable isn't really due for about three months.  That's great!  You can let your developers keep being lazy for 11 weeks, then spring the deliverable on them at the last minute: "Oh, by the way, I committed us to this deliverable that's due next week; everyone will be working overtime and coming in on the weekend."  'Nuff said!    Your developers should be more than willing to sacrifice whatever plans they had.  If they're not, that means they aren't as committed as you are.

Just because you are demanding that your peons work insane hours to meet this deliverable that you committed them to doesn't mean you have to mess up your plans.  It's Friday!  Shouldn't you be bluegrass concert or something? 

If something goes wrong and the quality of the deliverable is not up to your golden standards, or if the developers somehow miss the deliverable, the blame rests 100% with them.  You told them about the deliverable before it was due.  There is simply no excuse for them not completing it perfectly on the timeline that you agreed to without consulting anyone.

INTERJECTION: This is where I would normally go into detail about why this is a bad idea, but our boss just called and gave us ANOTHER deliverable that's due next week.  That's on top of the other one that was just sprung on us earlier this week.  He's known about these things for 2 months.  He now expects us to work all weekend to get these cranked out.  If we need him, we are to call him; he'll be at a bluegrass concert.

Damn, we're at part five already?  You might think that I'd be running low on material by now, but fortunately I have witnessed a horrifying number of ways in which people have tried to run a software project, most of which ended in disaster.  This week we're going to touch on something that I'm still dealing with at least once a week...

The OMFGWTFBBQ Method of Bug Triage

Because the people working for you are software developers, the people working for you suck.  You know this is true because I have a blog and I just wrote this.  Because the people working for you suck, they are going to write sucky software that is filled with bugs and things that have made a horrible abomination out of your grand vision.  It isn't your fault that they couldn't understand your requirements; you gave them brand new ones to work to every day (a strategy we'll talk about in a future post), so they should have been able to easily translate your brilliant idea into perfection.  They failed because they're not passionate!  They wanted to take baby steps and build things slowly and incrementally, but that's a recipe for mediocrity, and you're not mediocre!  You're special!

Anyway, so they've actually managed to stop playing solitaire (or whatever software developers do when they claim to be working) and produced a system.  Even though writing software is so easy that you're 14 year old nephew can do it (he did a web page for your shuffle board club, and that's just as complicated), your developers managed to screw it all up, and there is something that isn't working exactly like you pictured it.  The *only* way to react is to panic and call an immediate meeting with everyone in the company.  Be sure to include people that have nothing to do with the software, like your wife and any nearby hobos.  Make as big a deal about the issue as possible.  It doesn't matter if a button is left-aligned when it should have been right-aligned, you must demand that the developers immediately stop what they're doing and work on the problem.  Accuse them of not listening to you and ignoring your issues, too, because that will help motivate them.  I mean, you just told them about it, why is this bug not already fixed?  Storm out of the meeting and stay in as fowl a mood as possible for the next three days.

While it may seem like a lot of work, you actually have to repeat this process every single time you find a bug, no matter how small, otherwise the developers may start to become independent and try to "prioritize things by how severe they are".  Your button alignment issue is every bit as important as that little "data corruption and loss" bug they made up.  Try to do this every day, if possible, by creating a OMFGWTFBBQ "Issue of the Day".

Why this is a TERRIBLE IDEA

Despite what you may think, we (developers) do actually listen.  If we don't fix your bug right away, there's probably a really good reason for it.  It could be that fixing the bug will cause some other problem that we haven't figured out yet, or that there are other more urgent bugs that we need to fix first, or that it's a complicated bug and is taking a while to fix.  Freaking out about every little bug and making an inquisition out of it stresses everyone out, wastes time, and lowers morale (which is actually a bad thing).  Instead, report the bug to the team and try to go on with your life.  The fact that there is a bug in the system doesn't mean that someone was screwing around or that someone doesn't respect you (or that they're not passionate about what they're doing).  Believe it or not, building software is HARD, and we do make mistakes from time to time.

It's Friday, so it is time for part 4 in the series that Time magazine calls "... a breakthrough in blogging."  Ok, they didn't say that, but I'm sure they would if this series was actually a breakthrough in blogging. 

Practice Dragon Management

Dragon Management is a brand new approach to managing your peons that is guaranteed to bring you riches while keeping the office a barren wasteland of productivity and sorrow (because we all know that productivity is directly related to pain and suffering; that's why they whipped the slaves that were building the pyramids!)  It's the best thing to happen to software development projects since the UML and Rationale Rose!

The idea behind Dragon Management is to become like a mythical dragon, swooping in when least expected and laying waste to everything the peons have tried to build (because it sucks anyway).  Getting started is easy, just follow this simple procedure:

1. Disappear and disengage from the project completely, for weeks at a time if possible.
   It doesn't matter that you're the project manager/owner/whatever, you don't really need to do much aside from collect your check.  In your absence, the peons will have no choice but to step up and do your work for you, like planning, identifying business requirements, etc.  Do your best to have no interaction with the team at all.  Don't answer E-mail, don't answer your phone... if you do this correctly, they should wonder whether or not you've died.
2. Wait for the team to make progress and become organized.
   At this point, the peons should be well on their way to building something (that will assuredly suck because they are nowhere near as brilliant or as dedicated as you are).  They probably  have something that they call a "plan" (whatever the hell that is), and they may no longer describe their work environment as "a hellish wasteland of poor management."  They may still try to contact you during this stage to keep you updated on what they're doing.  Remember to ignore them!  Give them no indication that you still even exist.  Like the mythical dragon of old, you want them to begin doubting that you exist at all.  That sets the stage for...
3. BURNINATION
   Make your triumphant return to the project with a vengeance.  You're going to borrow a page from Trogdor the Burninator and burninate the place to the ground.  That "plan" the developers created or this "methodology" that they adopted?  Throw it all out the window!  All the progress they've made?  Tell them to scrap it all because it is wrong and it sucks and they suck and make them start over.  You may notice that one peon (or perhaps a council of peons) has stepped in to the power vacuum that was created in Step 1 and tried to "keep things running" in your absence.  Burninate these people with extreme burnination.  If they're not crying, you aren't burninating hard enough.
   For the next few weeks, be sure to drastically alter everyone's focus and the project requirements ever single day.  We'll talk more about this in a future post.
4. Go to step 1.
   At this point, the office should once again be a barren wasteland devoid of all hope and happiness.  This is *exactly* what you want!  Now the peons can be productive (because sorrow is to peons what Brawndo is to plants).  It is now safe to completely disappear again.

There you have it.  Stay tuned for upcoming Dragon Management seminars, books, and more... Success stories may be a while.  Apparently everyone who has tried this is too busy cashing their Internet Success checks to tell us about how well Dragon Management works.