The area of biggest challenge I’ve faced in software development is requirements. Nothing earth shattering there. It’s hard to state clearly what you want and it’s even harder to pick what is most important. In consumer applications, using mocks of the UI (simple to realistic) is an excellent aid in driving definition of the requirements. But no one wants to pick what’s the most important feature they need implemented. When asked for a prioritization, they will group features into “priorities”.

As Marty Andrews wrote, “At this point, the stories have not been prioritised. They have been classified into groups, where the group is named “Priority One”. Whilst this may be a useful culling technique, do not fool yourself into thinking they are prioritised.” Read the rest of this entry »

Hopefully everything went ok.
…Seems to load faster.

I’ve added a couple new items to my fundamental lessons I have learned from working in informational technology article. Periodically, the list gets updated, but I thought I’d elaborate on the two new items.

1. If you aren’t happy with what you are doing, nothing else matters.  All your successes will lack value. 

Saying “this should go without saying” should go without saying, but honestly, this should go without saying.  There are basic needs you must fulfill to be happy:

• food
• shelter
• family

That’s an unordered list.  Employment provides money to make these things possible.  Those three simple items make you happy.  Your job can add to your satisfaction and overall happiness if it’s something you enjoy.  If it isn’t, no matter how successful you are at work, it will always seem like work and there will be no satisfaction.  This will creep into your productivity and lessen your long-term potential and overall happiness.  So, keep your day job, but be on the look for one that may make you more satisfied. Read the rest of this entry »

When solving a problem, if you do not have full context to the issues, your perspective will be skewed to a point where the chances of establishing a clear, effective solution are low.  You might end up “solving a problem” that doesn’t even exist or, worse, is not a problem at all.  This really comes into play when reviewing business requirements.  It’s the teams responsibility to not just read the requirements, but understand the context they were written.  Most requirement documents are fairly light and 2 dimensional.  They assume you understand the motivation behind the requirement… why each one is being asked for.  Perspective and context changes meaning.

When I was a kid, I loved the Garfield comic strip.  Now, not so much.  But take a look at Garfield Minus Garfield.  As the site says:

Who would have guessed that when you remove Garfield from the Garfield comic strips, the result is an even better comic about schizophrenia, bipolar disorder, and the empty desperation of modern life? Friends, meet Jon Arbuckle. Let’s laugh and learn with him on a journey deep into the tortured mind of an isolated young everyman as he fights a losing battle against loneliness in a quiet American suburb.

Now, my kids love Garfield.  But this new missing context Garfield brings a new perspective to this strip that I find amusing.  It really illustrates the point.

Having survived (and not survived) close to 15 “reorganizations” with a resulting reduction in force, I believe they were initiated with good intentions for the company.  The road to hell and all of that aside, several of these were nothing more than exercises in creative accounting.  This year’s ledger will show a reduction in costs while still seeing the same revenue.  They did not take into consideration next year’s financials or growth.  Many were quickly followed by hiring sprees.  I was once told that it was more expensive to find a position for someone in a different group/role rather than RIF’g them and giving them an “opportunity” to find a position within 60 days.

Read the rest of this entry »