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.

Read the rest of the article →

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.

Read the rest of the article →

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.

Read the rest of the article →

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.

Read the rest of the article →

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.

When I was a child, I had a strong aversion to pineapples.  Just the look of them made me ill.  It didn’t matter whether it was cut or uncut; there was just something about the look that made me believe I would not like the taste.  Maybe it was the color yellow, but there was something terribly unappealing about the fruit, and no matter how much my mom would entice me with declarations of how sweet it taste, I would not try it.

I felt the same way about cranberry sauce too.  It was an emotional aversion; there was nothing logical about it even though I was convinced my reasons were all logical.  Cranberry sauce looks slimy; slimy is disgusting; therefore, it must taste like it looks: disgusting.  It’s a logical inference; though, it has little relevance to how cranberry sauce actually tastes.

As I got older, I became more open to giving foods a try (and other things, of course) that were unappealing to me.  When I finally gave pineapples and cranberry sauce a try, I discovered how I’d been missing out for so long on enjoying a food that was so pleasurable to me.

Much of the software community has a similar aversion to LOC. Many of their arguments against LOC are logical, but they aren’t relevant to the science and practice of LOC as advocated by its adherents.  Sure one can write a line of code with more defects than ten lines of code, but the Law of Big Numbers says the density observed in practice will be the expected value.

Read the rest of the article →

Early in my career I had the good fortune to work under a management team that valued producing high quality applications - ones that rarely, if ever, crash under continual load.   The director of the department believed, not only in words but in action, that a defect discovered in the field is significantly more costly to fix than one discovered in development.  We lived by that rule, and we all believed in it.  

For this product, we did not have a sustaining engineering team to fix and deliver patches to the field because it was simply not needed. Over the course of the seven years of working on this team through multiple product deliveries, I recall only two or three issues from the field that required an engineering fix.   Now think of all the features you could deliver by investing the money saved in a sustaining engineering team into new feature development. That’s what we did.

I’d like to describe the six practices required to produce and release stable applications.  The level of stability that you achieve in your products will correlate to the degree to which you commit to these practices.  The strategy by itself isn’t enough to achieve great results.  Great results require discipline, persistence, and a strong will, and most importantly, it requires a leader and a team that values quality above all other criteria.

Read the rest of the article →

During a presentation on software metrics, I asked the audience to estimate the distance from New York, NY to Sante Fe, New Mexico in Kilometers (they were asked not to participate if they already knew the answer), and I asked them not to do any conversions in their head before giving their answer.  For those of you reading in other countries, we use miles to measure long distances in the USA, so kilometers is a unit that we don’t have much experience using.   The answers to the question were all over the place with most of them being overestimates of signification magnitude, double or more.  Then I asked the audience to estimate the distance again, but this time, they were to estimate the distance in miles - a unit they were all very familiar with.  These estimates were much better with all being less than 20% away from the actual distance.   Some were so close to the actual distance that they were essentially accurate.

Read the rest of the article →

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.

What happened to the software industry?  I hate professional certifications.  It didn’t used to be this way.  Many employers are looking for the certificate du jour on your resume as a filter for an interview.  Having a certification means nothing.  I remember as a child it was a big thing if someone had their black belt in Karate.  It meant they were tough until they picked a fight with the real tough guy who knew nothing about Karate.  Everyone was awed.  “Did you know Johnny beat up Tommy who has black belt in Karate, and Johnny can’t even spell Karate?”

There is a huge difference between what you know and what you can do, and a certificate signifies neither.  It only means you met the requirements for being awarded a certificate.  I went to High School with friends who cheated their entire way through High School.  One was even able to receive a college diploma by cheating his way through.  He neither knew anything nor could he do anything related to that certificate.  However, that’s the extreme. 

Read the rest of the article →