I love the hammer and nail analogy. Why? Because it’s so easy for people to understand what the purpose and role of a tool is. Sounds trivial, but I think it’s very hard for humans to separate the utility of the hammer, the carpenter and how these translate into the utility of the output of their work. It’s way too often we correlate the output of the tool simply with the features of the tool. The technology sector is rampart with this type of thinking. There are literrally
millions billions of dollars spent every year on technology tools that we, as customers, believe are the sole reasons we either fail or achieve to “build our dream house”. Have we forgotten the importance and weight of the carpenter’s role?
Let’s say you decide one day you want to build a table. This table is going to be made using wood, nails and a hammer. All things being equal, let’s say you build this table with hammer A that has a utility of 10. You build a second table with hammer B and it has a utility of 15. You, the carpenter, have now created two tables, table A and table B, respective to their hammers. The tables are identical, but the utility is different. Now let’s say your utility as a carpenter is 5 (we’ll call this carpenter ‘ME’). The value of the tables is now: Table A – 50 and Table B – 75. Now, my carpenter friend (we’ll call this carpenter ’FR’) has a utility of 4 and he builds the same tables using the same respective hammers. He now has two tables at the following values: Table A – 40 and Table B – 60. So we can build a simple comparative matrix now. Table B built by FR has a higher utility than Table A built by ME but it was built by a less skilled carpenter! We therefore logically assume the hammer is the key driver for the overall utility, not because it has a higher multiplier, but because we believe we have better ability over assessing what the utility of the hammer is. We then therefore place much more importance on it.
There is so much discussion about our tools being broken and I believe that statistically it’s the carpenter that is affecting the overall output. Unfortunately it’s much easier for us as humans to draw the simple conclusion – the tool is broken, update my tool. Thus the hammer industry, or rather the technology tool industry, will continually go through cycles. New companies will be created year after year promising the dream house because you bought their shiny new hammer. I don’t doubt the necessity for these shiny new hammers, but I question how much weight we as humans put on them in order to create our dream house. Find a way for me to find a better carpenter, or fix the carpenter, and I’ll have my dream house…or maybe my dream table.
I recently took part in a BusinessObjects BI 4.0 implementation. The first thing you need to do after the server is up and running is to install the client facing tools. With on-premise, non web based (note – part of SBOP is web-based) technologies this means you need to go through the painful process of doing initial installs and patching. It took a solid 4 days just get one PC up to the latest patch spec. YES. 4. FRICKING. DAYS. To be fair, if you utilize some of the web-based features, it’s just a simple JRE install and you’re up and running. But that’s just for one piece of the whole solution set. So obviously my first reaction to this series of events is “Holy Bloatware Batman”!
So how does software become bloatware?
This happens all of the time in Enterprise technology and is no way limited to SAP products. How often do you hear “God Windows is so clunky” or “This thing keeps crashing”? Companies tend to buy on features that can help them do their business more effectively or more productively. Yet, you won’t ever hear an Enterprise CIO say “Well it doesn’t do XYZ but it is the fastest on the market so we’ll definitely use it”. And why not? Because the performance of the application is often overlooked as a major feature of the software. Read Jeff Atwood’s blog article about “Performance is a Feature” if you want to know more of what I’m talking about. I believe this overall concept is some form of Absence Blindess in that we don’t see performance as a feature of a solution unless it is of course missing to begin with.
What I find more interesting than anything is that most people tend to get more mentally frustrated when features are missing than when core features not performing well. A good example of this is Pixelmator versus Photoshop. Photoshop is super clunky. It takes a good minute or so to load up on my Mac. Pixelmator is very lightweight and generally takes 50% less time to load on my computer. I also rarely wait for the functionalities of the program to load. However I miss Photoshop’s Layer Style functionality. So much so that I tend to be willing to just switch over to Photoshop because of that one feature. Otherwise I sincerely hate waiting for Photoshop to load.
Letting your customers outgrow you
The guys over at 37 Signals, owners of the popular Basecamp project management tool, have a good preventative stance on this: Growing In vs Growing Out. They say:
We’d rather our customers grow out of our products eventually than never be able to grow into them in the first place.
Why is this important? Because they are actively promoting their software to preventing it to become bloatware. They realize that if they had more features it will eventually turn there customers away. One way other companies have circumvented this is to build add-ons or apps that are very modular. Meaning the user can add and remove as they go. This is important because the company can focus on the core technology while letting the user chose functionality over performance.
So to the Enterprise technology companies out there I must say to please re-consider your bloatware and stop the feature creep. Why? Because as soon as your products become clunky, you begin to represent what most visionary entrepreneurs see as a “market waiting to be disrupted”. Don’t believe me? Just ask Microsoft about Google apps and SAP about Workday. It may not happen tomorrow but it will happen eventually. My generation lives in a Google world, get used to it.