You Want IT When?

The second quarter was another successful three months for yuwantithwhen.com.  A number of essays were very popular with the site’s visitors.  The most popular essay for the quarter was “Why It Takes So Long.”  Thanks to Steve Johnson over at Pragmatic Marketing for directing his readers to the posting.   There are often very good reasons it takes longer than expected to deliver a software product, but there are things that we often do to make projects take longer than they should.  I’m thinking of writing the sequel to the essay:  “Why it Takes Longer Than it Should.”  I’m not sure when I’ll pen that one, but it’s in the queue.

(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…)

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.

In February many of the older articles continued to have heavy readership.  I find it interesting to see how the articles of interest evolve over time.  Some of the older articles are the most popular articles for the month when not too long ago it was always the latest articles published that would have the largest readership for the month.  The top 10 articles for the month of February are as follows:

1. “Reflection Unrealistic Schedules“
2. “No Pain, No Gain“
3. “Refactoring Isn’t A Design Methodology“
4. “Danger Agile Practices at Work“
5. “Agile Isn’t a Process“
6. “An Objective Method for Navigating Your Project“
7. “Part 1: How to Manage an Unrealistic Schedule“
8. “Outsourcing Debate - Two Guys Talk it Out“
9. “Monthly Wrap-up - January“
10. “Certifications, Who Needs Them?“

The top 10 countries visiting “You Want It When?” for the month of February are as follows:

1. United States
2. Canada
3. Australia
4. Great Britain
5. Netherlands
6. Japan
7. Germany
8. China
9. Thailand
10. Hong Kong

In February the focus was on critiquing the Agile Methodologies.  I believe the Agile proponents have been correct in attacking some of the traditional software development practices.  I’m sure we share a common disdain for many of the process-for-process sake requirements of traditional practitioners. I think in many cases the engineers working in traditional shops find the practices stifling as well, but they are often powerless to change it, so everyone goes along to get along; apathy essentially sets in.   The Agile proponents need to be concerned about similar behaviors on their projects.  When dogma sets in, momentum often prevents the practices that require change from changing.   A good process is one that changes.  For process to endure in corporate settings, it must change - even Agile.

It’s interesting to read some of the articles from Agile practitioners.  They’ve invented a lot of good jargon to describe what traditional practitioners have been doing for many years.  Refactoring is one of them.  There’s little new here except that the Agile practitioners have given it a name.  Traditional practitioners have always redesigned and recoded their applications where and when appropriate, but there is one distinction between the traditional camp and the Agile camp: the Agile methodologies make refactoring inevitable, while the traditional practices attempted to avoid this with more investment in up front analysis and design.  There should be goals when deciding to refactor.  The goals that I target are to deliver faster and/or to improve the quality (less defects).  It’s always to serve the business needs, never elegance–for–elegance sake. 

In May, I will be presenting at the PSQT Conference in Las Vegas.  The topic of my presentation is “Test Driven Quality.”   If any of you happen to be attending the conference, please find a way to say hi.  I’d value the opportunity to meet some of my readers.

Please keep reading, tell your friends about “You Want it When?”, and Email me if would at “bill(at)yuwantitwhen(dot)com”  to share your thoughts, critical or positive commentary or even topics that you would like me to cover in future articles.

January was a good month at You Want It When?  It had the largest increase in unique visitors in a single month.  Unique visitors for the month of January grew ~75% over the month of December.  The site still doesn’t have a Google page rank yet.  The traffic stats seem to warrant it, but apparently there are other more important criteria.   If anyone has any insights into this, I’d love to hear from you.

I’m using the statistics from my hosting service this month rather than from Google Analytics.  There are differences between the two analytic engines that I’d like to understand better.  The top 10 are basically the same, but in a different order.  I’m guessing this has to do with Java script being disabled on the visiting clients that accounts for some of this, and the rest has to do with Google filtering out crawlers and bots, but I’m not entirely sure.  I figured the best view to present is the unedited view, so here it is.

 The top 10 articles for the month of January are as follows:

1. “Reflection Unrealistic Schedules“
2. “An Objective Method for Navigating Your Project“
3. “The Paradox of Right“
4. “Refactoring Isn’t a Design Methodology“
5. “No Pain, No Gain“
6. “Outsourcing Debate - Two Guys Talk it Out“
7. “Part 2: How to Manage an Unrealistic Schedule“
8. “Part 1: How to Manage an Unrealistic Schedule“
9. “Danger Agile Practices at Work“
10. “Why Software Process Adoption Fails“

The top 10 countries visiting “You Want It When?” for the month of January are as follows:

1. United States
2. Great Britain
3. Netherlands
4. Canada
5. Japan
6. Australia
7. Egypt
8. Germany
9. Taiwan
10. South Africa

I was doing a web search on some of the search keywords that readers are finding this site by.  When I searched on one phrase, I happened to stumble on an article titled “Agile Isn’t” at http://www.technocrat.com/.  After reading the first few sentence, I said to myself, “Oh no, another programmer who found another process he loves to hate.”   You’ve probably worked with a few of those types who just hate process, any process.  He also happened to be a Microsoft hater, which also turned me off at first.  I’m just not one of those types that find Microsoft can do no right.   Within the first few sentences, this author pressed all my hot buttons.

But as I read more, I found his critique of Agile to be along the lines of someone who actually embraces process, but not bad ones.    While I’m sure to disagree with him on a few of his positions, he has some worthwhile positions to add to the process debate.  Give it a read, and you may find yourself nodding your head in support, and you may even laugh a bit.

I’ve been working on my next article.  I was hoping to post it this week, but the ideas haven’t settled down yet. There are still too many ideas on the subject competing for attention, and as a result, the article hasn’t hit the right tone.  The working title is “Agile Isn’t a Process.”  Hopefully the ideas have settled down by next week, and it’ll be ready for publishing. 

Please keep reading, tell your friends about “You Want it When?”, and please share your thoughts.  Email me if would at “bill(at)yuwantitwhen(dot)com”  to share your thoughts, critical or positive commentary or even topics that you would like me to cover in future articles.

First, I’d like to wish everyone a belated Happy New Year.  I’m starting to get back in to the swing of things, and I’m looking to publish as frequently as I was before the months of November and December consumed my time with other positive diversions.  In some ways I believe the slower pace was actually positive as the readers began discovering the earlier articles that were published, and as I’ve been saying, the most practical and readily usable article published was “An Objective Method for Navigating Your Project Successfully.”  That article was the third most read article for the month of December.   The top five articles for the month of December are as follows:

1. Software Metrics: Making the Case
2. Outsourcing Debate - Two Guys Talk it Out
3. An Objective Method For Navigating Your Project Successfully
4. Why Software Process Adoption Fails
5. Believe Defect Free Code is Possible

The five most read articles of 2007 are as follows:

1. Why Software Process Adoption Fails
2. No Pain, No Gain
3. Reflection: Unrealistic Schedules
4. Part 1: How to Manage an Unrealistic Schedule
5. Danger Agile Practices at Work

We often focus a lot of attention on process and the technical aspects of our work to improve software management.  While those aspects are important, there is less written about the people and cultural aspects that impede our productivity and success.  In January, I started writing about those aspects of the work that we need to address.  Improving process and the technical aspects will only get us so far in improving software practices.  To realize even further gains, we need to address the behaviors and attitudes that also impact the team’s ability to perform at peak.   Please, share your experiences and thoughts.  I’d like to learn of other perspectives on the subject.

It’s been a good six months since I’ve started this blog, and the readership continues to grow every month.  Thanks for your support, and I hope to continue to publish articles on software development that you will find interesting and valuable to your work.

It’s often said, you have to take risks to be successful. Who would disagree with that?  Starting a business is risky.  Investing in the stock market is risky. Going to college is risky.  Getting married is risky.  Few would argue that these risky endeavors shouldn’t be pursued in life.  These are all rewarding endeavors when we’re successful at them.
(more…)

It was worse than I thought.  I figured I’d be able to get at least one essay a week published during the month of November, but that even proved to be difficult.  I’m just juggling too many things right now, but I expect after the holidays for things to relax enough to continue with my goal of publishing at least one essay a week and at most two.

(more…)

The month of October has just come to a close, and it was an interesting month here on You Want it When?  The month started with the first of a series on metrics:  “Software Metrics: Some Background.”   It was a well read article, and I plan to continue with the series in November. 

I got side tracked a bit after publishing the next article, “Reflection: Unrealistic schedules.”  That’s when the site analytics went through the roof.   It was the most read article in the month of October, and it also has the most readers for a single day of any of the articles published to date on this site.  I’m unsure if the readers appreciated my position on the topic, but it certainly is a subject that evokes a reaction in my audience.

(more…)

When re-reading the essay “Nine Steps to Defect-Free Software,”  I stumbled upon a gem of a quote by the author.

In retrospect, virtually every decision against trying for defect-free and in favor of short schedule time was wrong and resulted in longer schedules, more bugs, more support, higher costs and smaller profits! by Terry Colligan, president of Tenberry Software, Inc.

It has been my experience that shortchanging quality has always had a negative impact to the team and the organization that was never worth the trade-off.   How about you?  Has this been your experience?  If so, why do teams and management persist in repeating this mistake? He is also saying that shorter schedules don’t improve project success.  In fact, they contribute to project failures.  That is contrary to the Agile tenent of short release cycles.  What do you think?  I’d love to hear your thoughts.