Disposable software – it’s cheaper to rewrite your app than fix it

On the internet, the fastest possible solution is often the best.  It’s too expensive and slow to design a system to be adaptable to unknown future requirements. If you have an agile enough implementation process, new solutions can be adopted when new requirements are known.

Today large software developers are binning entire desktop applications:

  • Google withdrew their much loved Picasa photo manager on 15 March this year in favour of their internet services.
    Unfortunately a local application with astoundingly fast image browsing can not be replaced by a website yet – especially as this website is almost entirely unavailable in my current country location.  Good news is digiKam is becoming a good replacement*.
    Also did you know there was a Google Wallet card?   – not any more, it’s going!

But it’s not just Google who decide to throw away their products.

  • Apple discontinued both OSX photo apps Photo and Aperture in 2015 to replace them with a dysfunctional half-implemented new “Photos” app.  The 2 apps “Photo” and “Photos” together with the functional downgrade continue to confuse users.  As does using one brand name “iMovie” for an app that has quite different functionalities depending on whether you use it on iphone, ipad or mac.
  • Microsoft on the other hand have the opposite reputation:  building ever more bloated software to maintain backward compatibility. MS are trying to change that, for example finally stopping Internet Explorer development and launching the new Edge browser (though there is still reused code underneath).  Bit late too – Google Chrome, Firefox, Opera already run on multiple devices and can synchronize your browsing…   so why something different and less standards-compliant just for Windows?

My school taught that if something is worth doing, it is worth doing well.
But now a ‘fit for purpose’ quality metric is important to ensure a balance of quality, cost and speed which is appropriate to the problem at hand.
This isn’t new – Quality was recognised as one of the variables in Rapid Application Development over 20 years ago by the Dynamic Systems Development Methodology.

So what about getting back to Rapid Application Development?   Accept that the application will be thrown away and make it easier to replace rather than over-engineering it for future potential enhancement.

Software developers are always supportive of building new applications rather than fixing existing ones, and motivated staff make for good results!

Seriously though, the best thing to enable Rapid development is a well engineered and light framework with a DevOps automation process around it:  within that the individual apps can be easily developed/maintained/removed/replaced as needed.
This is why frameworks such as WordPress become so successful.



Photos the good news

Use digiKam, it’s free open source software with professional level features.
At the same time, it’s almost as easy to use as Picasa – certainly easier than Gimp.
DigiKam runs it’s own catalog and has full capability to read/write metadata in the image files.
There’s also a powerful batch processing engine: for example for internet photo publishing you should set up a batch process to rename, resize, watermark, add metadata, compress your photos before uploading to the internet….



Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s