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!  Go have fun!  Your developers will take care of it all!

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.

Tags:

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.

Tags:

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. 

Tags: