You Want IT When?

When I review the articles published to this site over the last quarter, there is a dominate theme for the quarter.   The theme deals with the mistaken trade-offs of delivering products faster.  Our culture has become increasingly impetuous.  Many buy homes without saving for down payments.  Many lease to drive cars that would be, otherwise, too expensive to purchase outright.  The investment community has become increasingly speculative where promising high risk investments are outrageously favored over modestly priced companies with strong balance sheets, good earnings, and promising but modest growth rates.  Parents purchase new vehicles for their high school children instead of teaching the lessons of working and saving to get what they desire. Executives destroy the balance sheets of great companies to satisfy Wall Streets expectations for quarterly earnings.  Political candidates maliciously and falsely tarnish the character of their opponent rather than invest in the hard work to make the case for their policies and leadership.  In software, many start coding before completing sufficient analysis and design, and many accept requirements change without fully analyzing the impacts. Society increasingly mobilizes to satisfy its desires and needs quickly; however, satiating too quickly comes with grave consequences as we are seeing in our economy today.

(more…)

The first quarter of 2008 has been a terrific start of the year for “You Want IT When?”  The site continues to attract new visitors every month at an increasing rate.  One article, in particular, enjoyed tremendous popularity when a popular member of dzone bookmarked the article “A Strategy for Building Stable Applications.”  Consequently, the article enjoyed tremendous popularity for the month of March, pushing it to the top read article for the entire quarter.

(more…)

Achieving Agile goals of delivering faster and responding to change quickly is best achieved by designing an architecture that leverages those goals, I reasoned in an essay titled “Agile Isn’t a Process“.  Being agile is about leveraging the entire organization and business partners to deliver solutions to your customers. Agility is best achieved when solutions require less IT involvement, not more. 

While having a good development process is important and necessary, the Agile process is not well suited to developing agile architectures; an emergent, iterative approach does not offer much when the requirements for solving the problem require an investment in up-front analysis and design. Some would call the investment big, but I would call it proper.  In this essay, I’d like to offer a real world example to support that original thesis.

(more…)

The price of gasoline is changing.  It’s been increasing for quite a few years now.  From an economic standpoint, it’s not very good.   Scientists say the Earth is warming.  Global warming will make the Earth less hospitable to many animals, maybe even to man.   Not all change is good.

Change is a fact of life in the technology industry, and most changes have been wonderful.  The internet is revolutionizing many aspects of our daily lives for the better.  We have cell phones, Blackberries, and iPods that have improved our ability to communicate and enjoy our leisure time.   The gaming industry must change just to remain competitive, and the gaming experience has improved dramatically over a short time.   Change is often good; change is often necessary.

(more…)

I’ve been reading a few essays on blogs that say the aim should be good enough.  It’s hard for me to get excited about good enough.  It’s not very motivating. Think about it.  Can you get excited to get up every morning and say, “I can’t wait to go to work today and do a good enough job?”  How uninspiring?

Picture this.  You are a member of a new project team that is planning to build a new product that competes with Yahoo, Google, and Microsoft.  The manager calls a project kickoff meeting with the software development team.  To motivate and focus the team, he outlines the strategy to the troops.   He exclaims, “I don’t want you to get carried away with aiming for perfection.  Our goal is to develop a good enough product to begin to win market share away from Yahoo, Google, and Microsoft.”  It’s like some Dilbert cartoon. 

I didn’t get into the software business to build good enough products, and I’m pretty sure most people in this business didn’t either.   Could you picture yourself interviewing with a company, and the interviewer says, “Our software teams aim to build good enough products.”  As you shake hands and begin to exit the interview, you ask yourself, “I wonder how many people they hook with that line?”

Think about it.  Has Apple dominated the MP3 space because they decided to build a good enough product?   Has Apple actually aimed to build anything that you would consider good enough?  Is Google dominating the search market because their search is good enough?  Is the huge demand for the WII game console the result of a good enough product decision? 

Who get’s inspired to buy good enough?  What kind of demographic is that?  If you’re aiming to sell your products in the local five and dime store, good enough is all that’s required.  The commercial software market is extremely competitive.  Good enough won’t cut it for very long.

People who advocate good enough contrast it with perfection, but there is another choice: excellence.  Choose to build an excellent product.  Choose to build the best product. Not only will it be good for the bottom line, you will find that you are attracting the best talent in the industry.  Moral is high when individuals and teams are aiming high.  The best talent doesn’t aim to be good enough; they aim to be the best.  Aim to be good enough, and those who aim for excellence will leave your company and your products in the dust.