Wednesday, March 07, 2007

The Iron Triangle states that in software development, there are 3 constraints:

  1. schedule (making dates)
  2. software quality (how many/few bugs there are)
  3. features (how many new features you can pack in)

“You can have two,” the saying goes, “but not all three.” (In my experience, you’re lucky if you manage to get one.)

I spent some time googling for good studies or writeups of how to do software development when schedule was the choice. And found very little help.

Caught in the Triangle’s Trap

Most people’s trick with introducing the Iron Triangle is to deemphasize the importance of schedule in people’s minds. They’ve taken for granted that the software is going to have a bunch of whiz-bang features (otherwise, customers won’t buy it), it’ll be bug free (otherwise, it’ll get a bad rep, and customers won’t but it), and, of course, it’ll be on schedule, cause we gotta know when it gets released!

The Iron Triangle’s job — in these situations — is to get those people to prioritize those 3 things, and make sure schedule is last. Think of the possible combinations:

  1. Features and Quality: customers will buy it because it’s useful and doesn’t break. They had to wait 3 more months than they originally thought to get it.
  2. Features and Schedule: customers like the features, it was delivered when you told them it would be, but only 50% of it works.
  3. Quality and Schedule: there’s nothing new for customers to use in the software, but what’s there is solid, and it was given to them when promised.

Clearly, anyone can tell you that the first one is the one you want: customers need something to buy (features) and those features need to work (quality). In comparison, when they get those things (schedule) doesn’t matter too much. If I get a car delivered to me on time (schedule) that doesn’t run properly (quality) or doesn’t have a steering wheel (feature), it’s useless to me.

When Schedule Does Matter

Of course, schedule does matter, a lot, in the software world. Oftentimes, it doesn’t matter most to the customer: it matters most to the organization putting out software. Customer’s don’t always really need the software when they think they do; oftentimes they don’t even care.

On the other hand, if you get a reputation of always slipping your date, as a software worker, you’re in bad shape. (Given that customers don’t care about schedule as much as we think they do, I’m not sure why we care about it, but we do.)

As such, schedule is always at the top of the list, despite the fact that features and quality should be there. No literature admits this: they all go over the happy path.

So, long story short, how to develop software when schedule is the #1 priority. I suspect it’d be all about how to cut back on features and quality and still get your customer to want and like the software that’s, at least, delivered on-time, making sure you’ve impressed your bosses with your scheduling wizardry.

 

3/7/2007 9:22:33 PM (GMT Standard Time, UTC+00:00)  #    Comments [2]  |  Trackback


Software development can be a tremendously rewarding, enjoyable career.

Are you really passionate about software development? Be honest with yourself.

A desire to outshine a teammate isn't passion. Nor is a motivation to impress the boss. Neither is a combination of the two worn as a magic defensive cloak against downsizing spells. These are second-rate, artificial passion substitutes: Mixed into the recipe, they yield sub par results, often leaving a nasty aftertaste of burnout and dissatisfaction.

Instead I'm talking about a bona fide interest and enjoyment of the craft and challenge of software development, even outside of career or job security issues (though it benefits the same). This isn't a job ad demanding that you're "passionate about business reports!", but rather is just a moment for sober reflection on whether you're over-clocking life, or running idle instructions in a tight loop.

1. Be Marketable - Keep Up To Date Skills and Network Contacts

No matter how much you love your current job, you should keep your CV current, and you should always keep up-to-date on industry opportunities. Know what skills are in demand, and try to gain experience in them (even if it means pursuing formal or self-training during your own time), and attain a level of comfort that you could transition to a different opportunity with minimal discomfort.

MANAGERS: You should do everything in your power to make your group feel confident in their abilities -- ensure that everyone gets a chance with marketable technologies; encourage the pursuit of desirable certifications; and build skills through internal resources, workshops, and seminars. Unless you're running a sweatshop, this is unlikely to lead to a feared exodus of employees, but instead will empower and motivate your group to more openly contribute, and to demand more of each other.

2. Be The Master of Your Domain

The next time something seems mysterious or unknown, take the time to properly investigate it. Classic lack-of-control approaches such as hacked workarounds or "reset the server daily" lead to a feeling of losing control, reducing job satisfaction and adding to the natural daily frustrations.

MANAGERS: Identify and investigate "easy-outs" proposed by your development team. While most software has faults, and products and technologies often work differently than we might imagine, many times such excuses are due to a lack of investigation and analysis. Even when things don't work as advertised, which is frequently the case, formally investigating and empirically determining behaviours is vastly superior to each developer endlessly fighting with and then hashing out strategies on a need basis.

3. Accommodate Your Financial Needs

If your financials are out of balance, it will unavoidably sour your mood during the workday, making you resent your employer and your workplace. When life goals exceed the income of your position, immediately begin investigating alternatives (be it asking for a raise, looking for a more senior role in your organization, or seeking employment elsewhere). No motivational boost or cool company games room will overcome this basic life need.

MANAGERS: Be aware of the goals and needs of your group. Sometimes someone's needs grow beyond the possible return of a position, and it is important to appropriately communicate this (rather than giving vague hints of unseen raises and super-bonuses at some future point).

4. Have A Life Outside of Work

There will be periods when everything seems to go wrong in the workplace. Having the cushion of achievements outside of work can avoid it spiraling into a workplace disaster, keeping spirits up through the tough times. Often non-work experiences benefit the workplace as well.

MANAGERS: There is a world outside of work.

5. Properly Manage Expectations

Plan for the long term, realizing that promises that aren't delivered on will cause you great workplace unhappiness later. Manage expectations to ensure that you can satisfy your "customers" with reasonable effort, and with a reasonably high probability of success.

MANAGERS: Never demand unrealistic deadlines, and question employees when provided with the same. Encourage your troops to be more reasonable with their promises, especially to stakeholders outside of the group, and they'll have a much greater probability of meeting external expectations, leading to increased motivation for everyone.

 

This is an amazing, expansive career full of incredible innovation and endless opportunity. Ensure that you don't diminish your enjoyment through simple mistakes, such as pigeon-holing into a position, or endlessly setting up yourself for failure.

Control your destiny.

3/7/2007 8:15:00 PM (GMT Standard Time, UTC+00:00)  #    Comments [0]  |  Trackback


The 60 gamer points for 1000 death match games and 1000 dark ops games for xbox live really need to be won.  Should I play 40 hours of gaming or spend 10 hours to build a robot to do it for me.  I didn't do this, Diego Knyte did and he called it the xBot.  Since all one needed was the start button and B button, he needed a few random erector parts, 2 rotational solenoids, and some electronic parts.

3/7/2007 7:28:47 PM (GMT Standard Time, UTC+00:00)  #    Comments [0]  |  Trackback