Tag Archives: software

Good vs. Better

Despite my desire for an Android phone, (puns are never quite as good, when intended) I actually quite appreciate the Apple iOS and its consumer based products. I am not the sort of consumer with an insatiable appetite for the latest piece of technology. This timing was not right for me to buy a replacement for our “go-anywhere” laptop. When the time comes to replace our current run-of-the-mill laptop, I would seriously consider an Apple iPad as a worthy replacement. Of course, new technology will come along before then, so it is far from a guarantee. But, it is hard to see any other manufacturer making the concerted effort to produce a slicker device in the category.

Apple advertising pitches the iPad as a revolution. The revolutionary part is not the form-factor, nor the hardware, but rather the care-factor that went in to developing the device. Prior to this device, using a computer was akin to travelling to a foreign country where the residents spoke a foreign language. Sure, you could get around but it was a slightly difficult experience. If you went to the trouble of learning the environment/language, you got more out of the experience. The iPad was more like travelling to a neighbouring country that speaks the same language. The learning curve is almost non-existent.

This salt-pan-like learning curve enables people to feel an immediate mastery of their environment. It is empowering, which in turn leads to favourable experiences. One of the aspects I admire about the iPad is the quality of the default applications on it. Too often in the computing industry, the term “quality” is approximated to “lack of defects”. Quality should extend to usability and fitness of purpose.

The derogatory term “gold-plating” is levelled at some developers. For those unfamiliar with the concept, it basically suggests that a developer spends too much time perfecting some piece of code. After all “The perfect is the enemy of the good”.  The longer your software takes to develop, the more funds it requires. Prior to the software generating income, this is a financial burden. Therefore, it is important to avoid “gold-plating” – especially for “version 1” programs, but avoiding gold-plating is not an excuse to turn in poor work.
Apple have shown that going to the extra effort to produce good quality software can be financially rewarding. If people like your product enough to pay for it, then making software that more people like has an obvious incentive. If you work in a large corporate environment, turning out systems for internal use, the benefit is not as immediately obvious. If you think about the cost to your business in terms of lost productivity and training programs, you can start to appreciate that easier user interfaces save money, even if they do not generate it.
Making better software is hard work. A lot of effort has been expended in terms of producing systems that lead to less defective software. Revision Control Systems / Unit testing frameworks / Continuous Build tools / Static Code Analysis tools and more all aim to reduce software bugs. Can you name one automated tool that provides any support for developing better User Interfaces? I suspect a lack of these tools is due to the required level of intelligence needed to produce meaningful analysis of a user interface. Writing software that analyses UI suggests that the software understands what the UI is. I am no expert in the field of artificial intelligence, but I would suggest we are not quite at that level yet!
Having decided that human intelligence is needed to design User Interfaces does not mean that automated tools cannot assist. The “usability” of clickable targets are affected by things such as their size and location. The usefulness of text is reduced by overall length (Oh the irony in this blog post!) Modal dialogues provide “speed-bumps” to the user’s “work-flow”. Such aspects are quantifiable. Maybe such tools that measure such things already exist, but they certainly do not attract the attention of the programming masses.

Apple is leading the way in terms of “user-focused” software and there is nothing wrong with having a market leader that is doing a “good job”. Here is hoping that others will help raise the overall standard further by continuing to compete with Apple’s products!

Getting serious – Improving Software

A while back I read “Geekonomics – The Real Cost of Insecure Software” which discussed at length the problems associated with buggy and insecure software.  Whilst stopping short of stating it, the message seemed fairly clear that David Rice believed the answer lived in holding software companies liable and the abolition of adhesion contracts as defined by End User Licence Agreements*. 

The book left me with the impression that Rice felt all software developers were solely interested in making money without respecting their customers.  The computer programmers I have met have all had a conscience.  None of them would purposefully release software which they felt was dangerously insecure or buggy.  Don’t worry, be crappy, may well be a catch phrase for the industry, but I believe its intents were based on the fact that most programmers are “worriers”.  “Natural programmers” concern themselves over a vast amount of details.  They think of boundary cases and follow predictions through to see where this takes them.  Without some cap to how much thought they can apply, chances are they will achieve nothing – forever theorising on the possibilities.  It’s been said before… “Leading Programmers is akin to herding cats”

There’s often been debate about whether software programming could be called engineering, craftsmanship, artistry or something else.  Despite people’s best intentions, software has a long way to go before it reaches the stages of engineering.  You trust that your car is not about to combust as you travel the freeway and no matter what your innate fears may be, you’ve never got in an elevator honestly believing that it may just break and plummet  down to the basement.  Would you trust any software running on a PC with your life? (Would you be willing to bet your life on your word processor not crashing?)

There’s nothing particularly wrong with the tools used to develop software.  The common languages in use today are capable of providing stable reliable software.  (Even if their End User Licence forbids their use in a nuclear power station) The chances that compilers produce the wrong executable code are extremely slim.  So, most of the mistakes made in software, are at the “highest level” – the level where most of us live in our software careers.  Whilst there is no doubt that there are some very clever developers working on the various common computer programming languages, virtual machines and software platforms, they are still human and capable of mistakes.  Which leads to the obvious question: “How do those people get their software right, even though they will make mistakes?” 

During my time as a Development Lead, I tried to refine a process that would minimise mistakes making it into production code.  Most of those processes revolved around the concept of having more than one set of eyes look over the problem.  The truth of the matter was that I never reached 100% success rate and that I was never going to.  David Rice was correct in the fact that in most cases there is no compelling reason to strive for zero errors.  In fact, the opposite is true: “There are compelling reasons not to strive for zero errors”.  Most of these are monetary…  If you never release software for fear of it having bugs, you will never have an income.  That is not what would be called a sustainable business model.

Software practices such as Test Driven Development and peer reviews are improving the accuracy of software that is written.  Ultimately I believe that the number of times a given code stream is executed will largely determine the accuracy of the particular piece of code.  It is by no means the only metric for determining the likelihood of having bug free code, but most other metrics express reliability based on code quality.  Even the worst written code can be “bug free” and sometimes it is this code that has given years of faithful service.  As in testing, Quantity trumps quality, and cares not for well written code!   For this reason, code re-use should be at the forefront of your programming consciousness.  Most engineering disciplines rely on using as much tried and tested techniques as possible – thus reducing the risk of the unknown.  So, if we ever want to describe our discipline as “Software Engineering” and keep a straight face, we need to act in an appropriate manner. Use the code that has gone before you, contribute only to future code what you cannot already find.  It is a well worn saying, but one the industry seems yet to fully embrace…

* I’m only too well aware that getting your thoughts across by writing words is open to interpretation that can miss the mark.  Maybe David Rice was being more open-minded than I have portrayed him!  You will have to read the book and make your own mind up!