Sam Halperin (a good friend of mine), just posted some interesting thoughts about software development, and I thought I'd reply with my thoughts here.

"Someone once said that the number of bugs in any software system is constant."

That is certainly true, but only because the number of bugs in a non-trivial system is equal to N+1, where N=the number of bugs that you know about. So if you start with N+1 and then subtract 1 from N, the value of N has gone down by 1. But, you still have N+1 bugs in the system!

It's important to remember that this is for non-trivial systems, and is more of a macro perspective than that taken at the lower levels of the software development process. It is absolutely possible to design a function that is bug-free (assuming that the underlying compiler, machine language and hardware that it will utilize do not have any bugs that will directly effect its operation), it just can't have many function points in it.

"When do you throw out a system entirely and start from scratch with a new version?"

Sam asks a good question here and, when something like this comes up, I always like to validate my thinking by finding out what better minds than mine have to say on the topic. In an interview by Bill Venners, Martin Fowler answers a question just like the one Sam asks:

Bill Venners: In Refactoring, you list several problems with refactoring, including situations when you shouldn't refactor. How do you decide when you should start from scratch and throw away existing code versus refactor it?

Martin Fowler: The answer is: I don't really know. If you have no tests and cruddy code, then you should probably throw it away and start again because you'll have to do all the testing, as opposed to if you have cruddy code with many tests. If the code is riddled with bugs, then behavior-preserving transformations will of course preserve the bugs, so that might be an argument against refactoring. I think the answer to your question also changes as your comfort level with refactoring increases. As you become more confident with refactoring, you'll want to refactor something that you'd otherwise want to rewrite because you're more skilled at refactoring.

Martin has an interesting perspective here, and one that I actually agree with... again, as long as we are talking about non-trivial systems. Besides the engineering aspects of executing a good refactoring program within an organization, there is often a financial benefit of not always starting over. However, the comment that Sam makes about the difficulty of taking over a code-base that might not be designed or implemented in a way that is conducive to understanding and refactoring (think about all that spaghetti code that you have run into in life), is a major concern as well. In order to be in a position where it actually DOES make sense to use refactoring instead of rebuilding, you have to start on solid footing.

One other area to consider in this discussion revolves around technology shifts, and their impact on a "legacy" code base. Every couple of years (it seems to be 3 to 4 years), enough of a shift in the technology landscape has occurred, either as a jump or as accumulated organic changes, that you have to seriously consider the potential value of migration to a new platform or approach. This obviously costs money to do, but the risk is that the further behind you get the more costly catching up can be.

This leads me to a topic that I've been thinking about recently, the buy vs. build decision process that organizations are constantly having to answer for themselves. I'm working through my thoughts on that right now, and will be sharing it some time soon.

Labels: methodology, software development

Last week, on his blog Thinking Out Cloud, Geva Perry wrote about how he thinks that we are going to see a wave of innovation surrounding data center infrastructure in his post Infrastructure is Sexy. I have to say that not only do I agree, but we are seeing it in action right now. We have the opportunity to work closely with some of the leading infrastructure hardware, software and service vendors in the industry, and I can tell you without a doubt: the investment wave has already begun and we will begin to see the rewards of that investment in the first half of next year. In fact, I was talking with one of those vendors just yesterday, and I'm excited about what is about to hit the market. (I can't share details though, as I need to respect their NDA.)

In my role, one of my focus areas is infrastructure management software and automation. Given that focus over the years, I've been very frustrated with the level of support provided by the software vendors for service providers (and this includes ITSM applications, in addition to the automation frameworks). While this might have been an acceptable way to focus on getting into the enterprise market, trends in IT are going to drive CIO's to continue to push their infrastructure into service provider's hands. So... it's our turn for some focus from the vendors.

The shift to service providers is due to a combination of cost cutting pressure and the fact that the increase demand for infrastructure has created what seems to be a never ending stream of capital investments required to meet that demand. Shifting spend from capital to variable, with cost drivers linked to real demand, is exactly why cloud computing is exciting. Service providers have an opportunity to provide clients with different expense models by leveraging scale and the laws of averages to drive down the overall capacity requirements across a wide variety of customers.

For us to be effective at this, we have been relying on massive customizations or manual work-arounds when using the current generation of automation software packages. For the next generation of systems, my hope (and I think I may be in for a treat) is that we see more focus on multi-tenant solutions and increased programmatic access into the packages. No vendor will own our entire management infrastructure, because no vendor can really manage all of the different elements that we need to manage. It has remained up to us to sew these things together, using whatever hooks we can grab a hold of and some standards (SNMPv2 as the most basic example). The more vendors understand this reality, the more they will be willing to support our need to put these packages together in unique and scalable ways.

Labels: Infrastructure 2.0

I've recently been tasked with working on a corporate portal strategy, which lead me down a path of thinking about a couple of important questions. First, what exactly is a portal these days? Second, given that definition, what exactly is a "portal strategy"? I'll delve into what I believe to be general answers to these questions, avoiding the particulars of my company's effort.

What is a portal?

Back in the late 1990's, I was never a fan of the term portal. If I was handing out awards for "buzzword of the year" back then, the term portal would have been a gold metal winner. For a few years the word seemed to decrease in usage (with the notable exception being the product vendors that focused on "portal" platforms). This was a bit of a relief for me, and allowed me to focus my buzzword angst on other targets. When I joined my current company, I was happy to be using the term "extranet" to describe the project that I was running. Things changed again when we purchased another managed services provider, and our leadership began to use the term portal anew. For the last four years, I've had to get over my issue with the term and come to embrace it as a good description of the integration platform and web application delivery tool that we have developed.

When trying to pin a definition on a buzzword, I always like to get the crowd-sourced opinion. A quick search of Wikipedia for the term "portal" returns the expected disambiguation page, but from there you can find two links related to this topic: Enterprise Portal and Web Portal. The enterprise portal page defines a portal as a "framework for integrating information, people and processes across organizational boundaries". The first line of the web portal page says "A web portal is a site that provides a single function via a web page or site." That's certainly a non-intuitive statement (and not one that I agree with). I couple of sentences later, it states "Portals present information from diverse sources in a unified way." Now that's a much more logical description. The key words seem to be "integrated" and "unified".

So, given my past experience and what the masses have to say about it, I've boiled it down to a couple of key aspects:

1. Web-based - It's got to use HTTP as the primary mechanism of accessing the system. I only say this, because there really isn't another protocol as widely adopted that caters to the application and content use cases that get associated with the term portal.
2. Integrated applications - Especially with in "Enterprise" portal solution, but even in several consumer portals on the Internet (such as iGoogle and Live), integration of different applications into a single interface is key.
3. Personalized and Customized - Personalization and customization are two keys to a successful user experience with a portal. While they aren't required, I'm adding them as key aspects because of their importance to the success of the system.

What is a portal strategy?

This is where I think that the conversation gets tricky. If we exclude any talk of a consumer oriented solution, a corporate portal strategy could really be one of three things:

Customer Portal Strategy - This is basically an extranet-style solution. The strategy around this should focus on the following:

• Consolidated experience across multiple lines of business (if they exist)
• Contractual, billing and operational transparency
• Self-service support
• New service purchasing

Internal Portal Strategy - If the customer portal strategy was an extranet, this is the intranet side of the solution. Strategy points for this:

• Operational Efficiency
• Infrastructure / Development Cost Reduction (Common Platform)
• Employee Satisfaction
• Knowledge Management
• Collaboration

Web Strategy - If you get rid of a log in prompt, the customer portal begins to look more like your corporate marketing website. Strategy points for this:

• Corporate Web Presence
• Search Engine Optimization
• Brand Protection / Reinforcement
• Web Analytics

Where they intersect - There are a couple of strategic areas that these three ideas have at their intersection:

• Customer Acquisition, Retention & Up/Cross Selling
• Intellectual Capital / Property Management
• Common Technical Architecture
• Governance & Standards

So to answer the question (What is a portal strategy?), I've come to the conclusion that it's something made up of most of the elements listed above. We will see how this plays out in the next couple of months (and as we engage with different leaders in the interactive industry), and I'll certainly write again if my perspective changes.

It's been almost a year now, but I'm finally making progress on the second floor middle room that we gutted again. The wiring is done, the rusted out heating duct has been replaced, the bay window is insulated now, the closet has been re-framed and the wallboard is all up. Now I just have to get through getting all the drywall compound applied and sanded before the one year mark! In all fairness to myself (hey, it's my site), I did get distracted with some other house work over the summer... but I'm back on track and focused on wrapping this room up.

Posted by Picasa

Labels: home improvement, personal

I just published a couple of photos from our September trip to Barcelona on PicasaWeb here.

I really like the wacky parts of a city... In particular those that make an interesting photo to share later.

Apparently people in Barcelona require reminders not to step out into traffic or they might die.
And on the beaches... the problem people seem to be the Brits and Americans.
While not in Barcelona, our trip to see the Dali Theatre and Museum in Figueres was definitely a highlight.

Posted by Picasa

Labels: personal, travel

I was thinking about what a nasty little web (pun intended) of connections I've created recently with all the social media sites. For fun, I spent a few minutes diagramming the connections last night. The hardest part was laying out all of the lines and bubbles to make sense of the connections.

One thing that I considered after the fact was how I work with the tools. For example, I find it kind of amazing (even being a technology professional) that I can be anywhere in the world with cell phone coverage, and send a text message that gets propagated across several sites in one shot. The text message goes to twitter, which then gets pulled into FriendFeed and Plaxo. From FriendFeed, the message is then forwarded as my status to LinkedIn and Facebook. My website also shows that message via a FriendFeed gadget.

The interconnections in the web definitely represent something more powerful than what is accomplished with just one site. This is where the real power of the web is these days.

Update: Jon Udell has an interesting post about a similar concept. While I just marveled at the current state of affairs, John describes some goals that he wants to see fulfilled.

Labels: personal, social media, web 2.0