They said it wouldn’t happen again, but it did.  The American auto industry wouldn’t be caught unprepared again when another energy crisis were to hit the economy. Sure, consumers were all too complicit by indulging …

I recall the response from an unsatisfied customer of one company where they delivered a leading edge product plagued with quality problems. This is a direct quote. He said, “I’d rather drive a Pinto that works every day than a Lexus that always breaks down.” For him leading edge was less important than quality, or to put in other way, leading edge features that don’t work is like not having the features in the first place. That’s true for most customers. In software where high quality continues to be uncommon, high quality is a competitive advantage. Yes delivering high quality takes time, but in my experience, low quality always takes longer and costs more. As I see it, focusing on quality is a win-win strategy: it saves time and money, and it creates a positive reputation for your products and your company. Plus, your customers will love you for it.

Project management is a continuous process of planning, executing, measuring, and re-planning. It’s the process of meeting your commitments in spite of all the change and obstacles along the way. It’s a tool for managing change and complexity. It’s hard, and because some aren’t successful with it or don’t do it well, it doesn’t mean that project management is not valuable. Sometimes we blame poor execution on the process or the tools, but too often in software management it’s the skill that is at fault. The difference between the 300 Avg. batter in baseball and the 200 Avg. batter isn’t the bat, the ball, or the rules of the game, it’s the skill of batter. If we can focus on the skill rather than debate the need for the tools, we can progress the practice of software management to higher levels because skills can be improved with practice and education.

Why does it take so long to deliver software products? Many stakeholders ask this question during the course of a software development project.  It’s interesting when the developers ask this question because they know what …

In the business of product development striking the proper balance between present requirements and anticipating future needs is an art, requiring a mixture of experience, talent, knowledge, and vision. It’s essentially a function of leadership, leadership that seeks council and then decides. Those leaders who strike the right balance win and secure longevity in the marketplace. Those leaders who wrongly favor the present are doomed to a regrettable future since opportunity is realized when good decisions about the future are made in the present.

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.

Proper up front analysis and design is required, and yes, sometimes it takes longer than we’d all like it to take. However, when it’s done well, architectures are less complex, not more; quality is higher; time to market is faster, and products and teams are more agile. Proper architectures leverage the resources of the entire organization to deliver solutions to customers.

Change is often good; change is often necessary but only when we understand the value and the consequences of change, can we make good decisions about change.

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 10 lines of code, but the Law of Big Numbers says the density observed in practice will be the expected value.