simondelliott

The hidden cost of planned obsolescence

The postwar American industrial boom saw car sales take off. But by the time of the moon landings the car manufacturers had noticed that their sales were parked in a steady orbit and possibly were about to fall back to earth.

At that time the automotive industry attracted the most brilliant minds, and collectively they could not figure out why this fall in growth was happening. The most popular car manufacturers had complete control over the domestic car market, and yet their sales figures were falling. After some long and hard head scratching they realized that the reason for their poor performance was due to their past success.

The reason that sales had fallen off was quite simply because they had achieved market saturation. Everyone who wanted a car had a car. The only sales that the market leaders were making were due to the replacement of old worn out products.

As we all know shareholders demand growth and the market leading position was not sustainable.
So what was the solution?

Planned obsolescence

Quite simply the cars had to wear out faster so that they could be replaced faster and sales would start to rise again. Instead of engineering components to the highest quality they were machined to an adequate quality which caused them to expire in a known length of time. By today’s standards we consider this an environmental crime, however this practice and this method of controlling a market is a cornerstone of modern business practice.

Times and fashion change. Since the 80’s the ultrapreneurs and brilliant minds have been drawn into the world of computing.  But people are not the only thing that has migrated to the world of computing many of the working practices of the car industry have also made the leap into cyberspace.

How long will my software last?

For the past 10 years computer developers have been toying with the Toyota production system, many of the principles of kaizen are behind google, facebook and other modern world engineering feats.

But automotive business practices have also found a place in the new world of computing. When you look at the releases of windows you will see that closed source companies are clearly using their position as market leaders to make the most out of the principles of planned obsolescence.  All the languages, databases, office products and addon packs that they sell all have a shelf life. The next version of a computer language includes fixes for lots of issues, but in order for it to maintain a market leading position it must also introduce new issues.  This may sound a little unfair to the big software companies but they are not the only ones, planned obsolescence is a part of the very fabric of the IT market. Step back in time just a little further and you will see that everyone is doing the same thing.

It makes good business sense that your software is just good enough – not great, but just enough to last a couple of years before you need to buy the new more stylish, more secure, more better upgrade.

Take software depreciation into account.

The next time you look at new software think about how long that software is valid for and take the upgrade cost into account. Lots of packages offer free upgrades but do they offer free upgrades to the latest version? If you deploy a Windows 7 license what is the cost of the inevitable upgrade to windows 8, 9, 10 … ? Will your servers be running Oracle 11 for ever? How much will it cost you to change your business processes, how much do your people cost you, do you have to train every time you upgrade? Do you have to rewrite your application endlessly?

Comparing open source to closed source

Many governments and enterprises are looking into opensource as a possible route to cut costs. And I have been involved in a number of conversations looking at just how much an opensource alternative really costs.

The reality is that the short term costs are roughly similar. However when you look at the long term costs the equation becomes very different and this is because of the hidden cost of planned obsolescence.

Designed to fail.

My point of view is that it stands to reason that license revenue model software is deliberately designed to fail. It’s just good business.

However the practice of planned obsolescence is not only anti consumer;  wasting their time, resources and money, but it is also anti engineer.  If an engineer makes something using components of a computer language that are designed to fail over time then their products will also degrade, effecting the longevity of their product and the amount of time that their product can be retailed for.

I am primarily someone who makes a living by making and selling software, and for me this is the most compelling argument for using opensource throughout the whole delivery chain.

The reason I support opensource is not because it saves me money … it makes me money.

MVC framework for PHP

I had a lot of trouble a while ago working with the MVC frameworks from other providers, they all seemed a bit too complex.
So … I made my own one.

Take a look I would love to know what you think?
MVC Framework for PHP

I am going t licence this under creative commons, so please feel free to play with this as much as you like.

Future software delivery model

Essentially, big businesses will rent a service, clever charging models will make the services attractive, for example

“If you rent Atos CRM we will reduce churn by …” or “We will give you our manufacturing service for free if we get a slice of the cost reductions …”

Services will be made of applications, but not as we know them, the apps will be clever mashups of different features from other applications and web services,

This whole layer will be very confusing with millions of interdependent services and features,

Ultimately a small number of massive massive cloud vendors will provide the hosting, there will be alternatives but they will be a bit flakey,

A rainy day for cloud puns

You IT and Computer professionals out there better watch out, your land is about to be invaded … by the amazonians.

On Tuesday I went to the Amazon Web Services startup event in the wonderful British Museum, for a five hour cloud computing pun festival. Here are some of the shocking attempts at humor that I recorded, more out of a perverse curiosity rather than recording the humor for posterity
Where do you go after the Planet … the Cloud
The Sky is the limit
You’ve got Clouded vision
Flying through the Clouds

The event was excellent, well run, great content and good bunch to network with. And because there was no alcohol I didn’t make a complete chump of myself. What I think Amazon have done that truly amazes me is how they have hooked up everything you need to make a media product with the existing amazon market place and sales tools needed to derive a revenue from it. Whats more they have codified all the processed necessary to make it happen.

There was an interesting audience make up of around 1000 in total, I counted down my row and worked out these percentages.

• 20% Suits
• 20% Business casual
• 10% Casual
• 2% Female
• 3% Bald
• 5% Flamboyant media types

Whenever I try and make, or launch something I dread the endless conversations with the operational team (Luddites more resistive to change than a glacier) to persuade them to commission a new box or worse still … change an old one. Well amazon have really thought about this, and have provided both a web UI and an API to do it. This means that I can get development code into production faster, and If I can do that … it means that I can either demonstrate that an innovation fails or derive revenue from it with a smaller expense (my precious time).

I do have a concern that this inevitable migration to large cloud providers will ultimately create an even larger dependency on a shrinking set of suppliers. In the end this is anti consumer, maybe its time for a state run or even UN owned cloud?

Note:
For those of you who are into sustainability, when someone asked the question “Will Amazon be using renewable energy sources for its servers” there was a big laugh and a stumped speaker.

What the heck is cloud computing?

This is my definition of what cloud computing is …

To define the cloud computing … it is
“Any feature that is delivered over the Internet where both the developer and user of the feature is abstracted from the infrastructure that provides it”

The early adopters of the internet almost exclusively used it for chat (mainly for swapping home made starwars scripts)
“The cloud” is the architecture notation of  “a cloud” to represent the Internet.  The use of the name is a nerdy in joke amongst web architects. In technical meetings  over the past 5 years the answer to the question “where does [insert nameless feature] come from” has been “the cloud”.

People who don’t understand computers are in the majority and the cloud takes away all the pain of nerdy computer boffin nonsence such as flexibility, encapsulation, cost reduction, backup, DR, scalability, etc … When you put it on the cloud It becomes someone elses problem.

Remember Steve B’s famous Key note speach “Developers, Developers, Developers”.
This is why kids make facebook apps instead of java or .NET programs. when you develop against the cloud, its alot easier.

Sam the architect learns about passwords

What the hell is cloud computing ?

The first common use of the Internet was essentially chat (IRC) and sharing homemade starwars scripts. Then came the world wide web and it was the world wide web that was static.

“The cloud” comes from the architecture notation of using a cloud to represent the internet. The use of the name is a nerdy in joke amongst web architects.

In technical discussions over the past 5 years the answer to the question
“where does [nameless feature] come from?” has been “the cloud”

What most people miss when thinking about the cloud is …

The people who don’t understand computers are in the majority and the cloud takes away all the pain of nerdy computer boffin nonsense such as “flexibility”, “cost reduction”, “Disaster Recovery”, “Scalability”, etc … these concepts are inaccessible and alien to the lay man. However many lay men are very creative have some good product ideas some of them are even good programmers.

When you put “it” on “the cloud” all the pain and trouble becomes an SEP (Someone Elses Problem)
This is why kids make facebook apps instead of java programs.

It is just more fun ! big organizations need to face up to this and work out how to commercialize their offering, with this new way of abstracting computer pain.

Essential reading list for the architect

This is the message in it hardcore engineering form.

Lots of small changes on the inside make a positive effect to the public impression
http://www.refactoring.com/

Enjoy doing it and apply it to a team, structure process and control, shared goals
http://www.extremeprogramming.org/

Clean, simple and disciplined.
http://en.wikipedia.org/wiki/The_C_Programming_Language_(book)

Use technology to work together
http://subversion.tigris.org/

You operate in a political world, it is only victory if everyone wins
http://www.chinapage.com/sunzi-e.html

Use convention over regulation
http://rubyonrails.org/

A good experience comes from both form and function
http://en.wikipedia.org/wiki/Helvetica

Architecture principles

To ensure the objectives and expectations of the project are achieved, try and use these principles in the design decision making processes.

• Re-use: Components of the platform that are already in place (e.g. components exiting in the manufacturing chain, etc.) should be re-used where possible.
• Integration: into existing infrastructure: The design should not adversely affect the existing infrastructure, networks or business procedures.
• Cost: To deliver a cost-effective solution which presents future opportunities for re-use and increased scope of operation.
• Openness: The design should be compliant to open standards where applicable in order to support flexibility and a modular architecture (reducing risk and cost of change).
• Performance: The performance of the design is important to the success of the service; it is a key factor to user satisfaction. The design should consider performance in the functional and technical design of each area and component.
• Robustness: The design should ensure service availability in the event of key component failure, the design must also offer a sliding scale of redundancy.
• Operability: The design should support robust and efficient operations management.
• Scalability: The design should be able to support short term increases in load (planned and unplanned), and long term growth in application resources.
• Presentation: The design should be documented and presented in a manner that is comprehensible to all stakeholders.

It is anticipated that requirements may change, evolve or even be de-scoped from the project brief stage to the point of implementation, however you must always endeavor to ensure business objectives are met from an architecture standpoint using the above guiding principles.

Justifying ROI on a wiki.

How to help your boss make a decision to buy a wiki or
Which line do the curly braces go on?

We used to have a big problem with quality, simply put we spent most of our time fixing bugs on old code rather than innovating new products, the problem was code standards.

My team was in 3 countries and we had 3 different sets of coding standards, any collaborations were plagued by technical differences in the code. I wanted to merge the codebase for the main products from all three countries and there for had to get the team to agree to a new set of standards.

I took the traditional approach, got one dev team to make a word document, distribute to all the parties etc … we held meetings to discuss feedback, had reviews and revisions of the document.

After about 3 months we managed to get agreement, and some people started using the new standard ….

However within another 6 months there had been so much change that the standard was out of date, and only a few were following it. Obviously my management team and I tried using the stick, but it just made everyone hate the standard even more. The code was not getting any better and the programmers were still behaving as little teams, rather than as a whole.

So, I copied and pasted the coding standards into our “trac” wiki, which is a free product. I told every one that they must follow the standards, but I also told everyone that anyone could change them. If there was any disagreement then I would make the decision. Over the next couple of months they deleted about ½ the standards, then they had a big row about a whether the curly braces were on the same line.

The end result was that all the developers subscribed to changes of the standards and took an active interest in a) whether they were good and b) how best to follow them.

The difference between wiki and the old “document and versioning” approach was that it allowed standards compliance responsibility to be devolved to a level in the product development team where something could be done about it. I was freed from the mindless task of telling developers to implement the standards, the code was significantly better, there were less bugs and the whole company started making the same products faster.

The investment in installing the wiki (1 day) me adding the standards ( 1 day) the huge row about the curly braces (a lot) was far far out weighed by the reduction in testing and fixing time and the increased revenue by having a better quality product that consumers loved.

About two years after that we started using the wiki for far more important things such as interface specifications, functional specs and architecture documentation.