Monday, July 30, 2007

The Changing Product Landscape

It is no surprise that we are in the middle of a significant change in the way software and content are priced, developed, and distributed.
  • Google apps, Zoho, Hotmail, and others have set an expectation about the complexity of "free" software.
  • Salesforce.com, Omniture, and others are setting expectations about how complex software served as a service can be.
  • Yahoo!, Project Opus, Blogger, and many more just being conceived are setting expectations about how applications and, more importantly, their data ought to be interacted with.
For product managers of traditional software products, this is scary stuff. People want to be able to interact with their applications wherever they go and expect to be able to interact with the data in many ways, perhaps not even "in" the original application. And expectations are being set that this ought to be free or a standard piece of the software.

For new products, this cannot be overlooked. Product managers need to embrace this and understand how it affects pricing, features, etc. Software architects need to know the technologies. Developers need to be designing for it.

New products that don't have an appropriate answer to these concepts will fail. Note that an appropriate answer might be to not have those features. But if you don't think about it before your customer does and explain why you don't, your customers will just think it is an oversight.

SaaS, Web2.0, and Mashups are changing things in a huge way. Are you innovating or are you looking in your rearview mirror?

Sunday, July 29, 2007

Agile: Why It Scares Management (Part 3)

This is the third installment in my series on Agile development. This will also be the final article on why Agile methods scare management. In previous installments, I discussed the impact of process-driven and command-and-control corporate cultures on development. This final installment will discuss funding, messaging, and sales. In short, it is about the dollars (or euros, pounds, yen, or whatever your currency is).

In order to get a project funded, there has to be a reasonable assurance that it is going to make money. Answers to questions like how many engineers should be assigned, how much effort should be spent in marketing, etc, are determined by taking the feature set and doing research to understand how much are people willing to pay for a set of features. If a development organization turns around and says, "Well, we don't really know what features will be in," to the financiers of a project, that is like saying, "Well, we don't really know how much this project will be worth." Any investor wants to feel comfortable about the investment she is making and the return it will bring.

Once the project is funded and underway, it is time for marketing to go to work because salespeople will not be able to sell a product that customers don't know anything about. Innovation is a current buzz word in the marketing world, leading to what Doug Hall would call a Meaningful Difference. The fear of marketers is that, in an Agile world, they don't know the Meaningful Difference because nothing is "set in stone." The only thing worse than having no Meaningful Difference is to talk about one and then have it not show up.

Continuing downstream from marketing are the salespeople. Studies have shown that salespeople are most effective when they are dependable and honest1. Having a moving target to sell against makes that dependability and honesty difficult to cultivate and keep. Instead, salespeople wait to sell the new product, even though it would otherwise be advantageous to do so.

In the first three articles, I've discussed the very real fears and concerns about Agile development. People who are familiar with Agile development will know that many of the fears are unfounded. In the next several articles, I will discuss how these fears are unfounded, and how, in reality, the things that are most feared can be turned into its greatest assets.

1. "Jump Start Your Marketing Brain", Doug Hall, pg 198

Friday, July 27, 2007

On Innovation

consultaglobal has posted on innovation and its relationship to solving existing problems. The four-box diagram and related description is a keeper, really identifying the innovators from the followers (those looking forward versus those looking in the read-view mirror, in the post's metaphor).

Across the board, software development is about innovation. Without innovation, you are not differentiating yourself from the market. One of the product manager's responsibilities is to understand the market well enough to know what is innovative, but it isn't just the PM's responsibility. The PM needs to share that vision with the rest of the team, from the software developers and testers through the sales and services organizations to ensure the the innovative vision is maintained.

Everybody in the development cycle needs to feel like they understand what is innovative about their product. If you don't understand it, go find out. Talk to your boss, to the product manager, to the CTO. Talk to whomever you need to, but find out. It makes your job much more fun and far more fulfilling.

Friday, July 20, 2007

Blogging and Comments

Joel Spolsky posted that the comments section on blogs are pretty much useless, given the amount of inane anonymous postings that can occur.

I disagree. I don't see blogging as a way for me to pontificate without any thought to others' views. It is others' views that make life interesting. I blog and I read blogs as a learning process. My blog has my thoughts and opinions. They can be wrong. If they are, I want an opportunity to reshape them.

I like Joel's blog. It is often very interesting. At times, though, he takes himself and what he has to say a bit too seriously.

But there is something to be said regarding getting the <75 IQ crowd to go find something else to do in their mother's basement.

Thursday, July 19, 2007

Agile: Why It Scares Management (Part 2)

This is the second installment in my series on Agile development. In the first installment, I discussed some of the history around process expectations. This time I'll discuss some of the corporate cultures that Agile development upsets.

Corporate structures are command and control based. Every manager gets asked "what is happening, when will it be done, how much will it cost," so every manager expects to be able to ask that question and get a definitive answer. If I am running a factory, I need to be able to answer questions around how many units can be produced, what load are we currently running at, etc. At the executive level, that expectation naturally flows into the software parts of the company.

In the 1970's, there was an effort to put more process behind software development than the "code it and fix it" non-process that was happening. Some organizations were having success with iterative methods, but, in one of those twists of fate, iterative was going to take the backseat for a while. In the 1980's, the US DoD released a software procurement standard1 that was based on the waterfall model. This became the basis of procurement standards worldwide.

One of the key papers2 written in the 1970's that was used in support of waterfall development was written by Winston Royce. Ironically, the paper very clearly states that there is a need to plan on doing the development more than once before releasing in all but the most simple, straightforward systems.

So we have a management structure that expects top-down answers and a historical predisposition towards trying to manage the software lifecycle in a waterfall fashion. Much in the same way as "alcohol may intensify the effects of this drug", putting the two together causes greater mayhem. Many of the managers at a decision-making level in the marketplace today were the same engineers being taught the values of waterfall historically.

In other words, we have a layer of management who was instilled the values of the waterfall method. They were told that they could answer the questions their managers were asking them. And they were ensured that their products could be successful. Now, being on the other side, they need those same values, answers, and success. They want to go with what they know, even if it has been proven unsuccessful and down right risky.

I've discussed a little about how cultural history, corporate structures, and individuals' histories have made the adoption of Agile methods difficult. In the last installment of "Why It Scares Management", I will discuss the financial aspects that scare management. Following that, we'll begin talking about the benefits and how those can and should reassure everybody involved with the development process.

1. DOD-STD-2167, United States Department of Defence
2. "Managing the Development of Large Software Systems", Winston Royce, Proceedings of the IEEE Westcon, 1970

The Millennial Generation, the Internet, and My Kids

I have always been fascinated by computers. By the time I twelve, there were two computers in my house, an amazing RadioShack TRS-80 Color Computer (with 16k memory module) and a blazing Atari 600XL. The Atari was actually mine; the TRS-80 I shared with my brother. Computers have been a part of my blood and my life for nearly as long as I can remember.

Even today, I've got a Linux MythTV media server, a Hauppauge MediaMVP acting as a MythTV client, a fully wired and wireless networked house, and so on and so forth. Even my wife, who hadn't done much beyond word processing on a computer before we met, is now an avid computer user.

It is, therefore, somewhat disconcerting to me that my kids aren't as fascinated by them as I am. I certainly don't expect them to follow in my footsteps (even though I would love to teach them how to code!), but beyond a few websites they use regularly and a little desire to e-mail, there isn't much interest. My oldest is 13 and doesn't know what a blog is.

So, this is where I become unsure. Computers are a significant portion of any professional's life at this point. The Millennial Generation will be much more so. I want to ensure that my children are not just prepared with the knowledge and understanding of the power of the Internet, but that they are honed with that knowledge. On the flip side, I also know the dangers that lurk there. I don't want to unwittingly push them into a jungle they aren't ready to deal with.

The goal is to train them to understand how to take advantage of the incredible power of the Internet without getting lost in the incredible wastelands that populate it as well.

So these are my questions: How much do I push my kids out into the vast jungle that is the Internet? How much do I worry about it? How much do I let them explore it organically?

Agile: Why It Scares Management (Part 1)

One hundred years ago, Henry Ford started his efforts that culminated in the assembly line. I don't think anybody would argue the efficiencies gained by the assembly line. Around the same time, Frederick Taylor was studying workers and optimizing their actions using Scientific Management.

A hundred years of improving process to be able to better analyze costs, risks and delivery followed. Six Sigma is the latest incarnation of that. Any repeatable task can be analyzed and made better. As you make it better, you make it faster and more predictable. A Model T coming off the assembly line every five minutes.

For a hundred years, we have learned if you analyze the process, if you make more definitions, you make the problem more predictable. And for the last 30 years, this is how software has been managed. Analyze the process, define it more, and expect faster and more predictable development.

Process is just the first factor. In part two, I will continue to discuss the reasons why Agile software development scares management.

Wednesday, July 11, 2007

Open Source versus Commercial Software Quality

I was reading through questions asked on LinkedIn and came across this question:

Can we consider that for a given application one will find fewer bugs in open source than in a branded proprietary application? (Link)

A fascinating question with a lot of opinion-based answers. I don't think there are many software products out there that don't incorporate open source in some way, so it seems like an important question to understand.

OSS proponents often use the argument that the more eyes on a piece of code, the less bugs in that piece of code (usually stated as Linus' Law, "Given enough eyeballs, all bugs are shallow."). In fact, this is really considered to be a self-evident truth in that community.

Personally, I don't like "self-evident" truths. I also don't like subjective answers like "OSS programmers are coding what they love, so they make better code" or "OSS projects have many, many programmers and, according to Brook's law, that's where bugs cluster." Give me real numbers, not theoretical possibilities.

The reality is that there is little hard data on the subject. A couple of items I've found:
  • The best data I could find on the comparison of open source and closed source is in this paper published by Stamelos, et al, from Aristotle University of Thessaloniki. It isn't a true side-by-side comparison, but rather a comparison of open source code analysis to the tool's industry "standard" recomendations. The opinion: open source software is better than an OSS detractor might expect, but it still isn't up to the industrial "standard" of the tool. The conclusion: more data is still needed.
  • Michlmayr, Hunt, and Probert of the University of Cambridge discuss open source processes and quality management and their effect on OSS quality in their paper. The conclusion is that OSS presents some significant challenges around ensuring the quality of software produced. Unless an OSS project has a specific focus on quality and process, it likely will suffer in that regard. Once again, this is a small sample set and more data is needed.
My experience with software would lead me to believe the results of the Michlmayr paper. It is difficult to get people to volunteer to focus on the corner cases and the boundary conditions; that isn't "fun." In addition, to polish a product takes a good amount of governance to make sure that fixes aren't introducing more risk than what they are fixing. This also seems difficult to achieve in a volunteer army. Not impossible, just difficult.

The question of quality is but one question is determining whether to use open source or closed source software. Other factors that need to be thought about include support costs (both in terms of finances and time), opportunity costs (or, potentially, wins), licensing costs, and training costs. It is only when all of these items (there are probably others, too) are calculated that you can begin to see the value of open source versus closed source to your project.

I would love to read more definitive research on this topic. If you know something I don't, let me know!

Tuesday, July 10, 2007

What is this all about, anyway?

Another blog. Yet another person, using the ubiquity and economy of Internet publishing to pontificate. Is it something interesting or more drivel? Today, I can't answer that; over the following weeks and years, I hope to do so. And I sure hope it isn't more drivel.

I am a software developer. I mean that in a larger sense than a "coder", which is something I have done, but is only a component of what I mean by a software developer. I'm talking about all of the roles in the software development process, from gathering customer requirements to the UI design process, from architecting and implementing systems to managing those doing these things. I have done each of these to some degree in my career. I am fascinated by all aspects of the software development process, from the high-level business objectives to the low-level determination of quality.

The goal of this blog is simple: get myself and others in the software business thinking and talking about better ways to develop software. How do we make software that is easier to use, higher in quality, and more robust financially? I am expecting this to be a learning process. I will share my thoughts and opinions, my research, and my experiences; you can share yours. Together, maybe we can learn something and make software a little bit better.

Beyond that goal, I also think that part of being a successful software developer is to have a life outside of the code. I'll undoubtedly have something to say about that, too.