Random carp

Well, Keynsianism took 30 odd years to fall on its face, and now Chicago School/Neoclassicalism has followed suit, mysteriously also about 30 years after it took hold.  Maybe there’s a longer term economic theory cycle at play here….

What’s next, now?  We have New Keynsianism, so will we now get New Chicago (promulgated by Dr. Theopolis, I presume?)

Apple pulled off a real coup with the App Store.  Getting the wireless providers to get out of the way and allow an open development model for the iPhone is something near a miracle.  The phone vendors (Nokia, Ericsson, etc) and environment vendors (Symbian) have been trying for years to make that breakthrough in North America.  The wireless carriers playing gatekeeper with apps has prevented the cell app market from being just as vibrant as the computer software market.

Now, though, Apple has decided to play the role of gatekeeper.  Apple, please stop it.  The way to compete with apps that are similar to yours is to make yours better.  Or buy the better ones.  The way to compete isn’t to deny apps placement in the store.

That’s the pressing problem, but the next issue is really opening up.  Developers need to be able to run wide betas with apps.  If you want apps to be 100% done before they hit the app store, then you need to create a “Use at Your Own Risk” store to let developers get proper testing done on their apps.  Even better would be to make ad-hoc distribution much easier.  Let us distribute apps from our own websites.  Yes, that would compete against the App Store but iTunes should have taught you that that’s not a risk — stores are something you do better than your competitors.

I’ve been thinking about the structure of software organizations, and particularly the roles and what specific value they add.

Developers

At the most basic, if you don’t have these you’ll never get a product out.  It may not be exactly what customers want, and its quality may have issues, but you’ll get something out.  Because most developers nowadays came out of developing the entirety of their own software rather than formal education programs, they actually have a much broader set of skills than pure development.  Scratch them and you’ll find many have decent design skills, decent business analysis skills, etc.  This is not true for outsourced developers, as the home computing infrastructure and culture of hacking isn’t there.  The good developers will be working in the industry already no matter where they grew up.  Really good developers are also good product managers, since they make the right decisions because they understand the customer.

Product Managers

Product managers can improve the alignment of the product with what the customers need.  They can’t get a product out the door, so that’s not a good benchmark to grade them against.  Bad product managers can worsen the alignment with what customers need, though, if they are focused on marketing or Gartner points instead of understanding and fixing the problem the customer has.  Ideally they have strong, functional business skills so they have a intuition about the way software can aid the customer. When you’re trying to judge Product Managers, you have to focus on their ability to improve the match with what customers need, not what they want.  Good product managers are good private investigators — they know what motivates your customers better than your customers do.  Really good product managers can educate the customer to see that what they, the customer, wants may not be what they need.

QA

As their name may suggest, QA adds quality to a product.  By unburdening developers from the QA process, they can also increase the code that gets developed in a time frame.  The delta over developers alone can range significantly, from almost nothing to quite a lot.  They not only add quality to the code, but can also do a good job of initial user interface testing, as they are often a closer representative of the end users than many coders usually are.

One thing I’ve found strange over the years is the lack of awareness of economics in software. Especially the concept of satisficing.

Satisficing is an interesting idea, since it’s common sense that’s not all that common. In a nutshell, it’s the idea that the ideal amount of work you do to solve a problem is the minimal amount of work to satisfy the goal. Any work beyond that is “extra”.

You see some of this thinking in some of the agile software techniques, but it’s odd that it’s not standard thinking in commercial software development where “extra” work has a significant impact.

In commercial software, you have two constituencies that have to be satisfied. With new customers, you have to do enough work to make those customers happy enough to buy. Existing customers are slightly different in that you have to do enough work to keep them satisfied enough not to leave. You gain some leeway because of the opportunity cost to the existing customer for leaving.

Product management often makes a stab at figuring this out, but oftentimes the work to figure out what is actually the minimal saleable product doesn’t happen until the effort to fit the product into the development cycle begins. So instead of figuring out the minimal saleable product, the decision that’s being made is what will fit a timeframe, which may in fact be larger than it needs to be.

Figuring out what’s minimal is a difficult problem, since you don’t really know what it is until you’ve sold the product to a profitable number of customers. The minimal product is the one that encompasses the union of the features that those customers use. Each additional sale potentially increases that set of features. So, the common up-front guess is the collection of competitive analysis and RFP “bullet point” features.

Understanding that the minimal set of features is your target, not what will fit, is a good start.

In upgrading Wordpress today I again ran into the bane of software, bad upgrades.

The Wordpress upgrade failed with an “out of memory error”, which is bizarre since my site isn’t that complex.

Updating php’s settings to allow more memory did allow the upgrade to proceed, but it’s pretty poor that it failed with the default php memory setting (which is fairly substantial). You would think that the upgrade would have been tested with the default php settings.

Upgrades seem to fall into the same category as QA, in that doing a good job requires a different mindset than that of “regular” development. Writing a good upgrader is a meticulous process, which increases in difficulty as the configurability of the app increases. When you’re creating new software, the problems you’ll encounter are of your own making