Tuesday, 30 July 2013

TCO - Total Cost of Ownership


                                                                     


When you go to buy a car, what are the first questions that you will ask yourself? I don’t know about you but my list would be along the lines of, how much will it cost to tax the car every year? how much will it cost to put fuel into it each month? how much maintenance will it cost? how much are the parts compared to other manufacturers?

Software houses are different to car manufacturers because they retain ownership of the software and licence out the use of the software(the car in the analogy) to the end-user. If Ford or GM used the same model as software houses, do you think they would stop thinking about the cost of the car once they had built it?

It seems to me, that software houses, often only look at the cost of production but not at the cost of maintenance and operations. To me it makes sense when designing a new system, to use components that are cost effective, reliable, scalable, have wide industry usage, so it’s easier to find engineers that can use those components.

What happens in practice is quite often the opposite, with obscure, proprietary, once-off components being used and sold as state of the art. We live and learn. Think about asking how many software developers/testers will it cost to fix bugs in the system? How much will it cost to maintain operations, help centres, network latency, failover, etc. And what about training costs for new employees, what about the cost of keeping documentation up to date? Hardware costs, cloud costs for increased network usage.

Okay, so I’m very cost sensitive but don’t just ask how much does it costs to make and hand over the money. That kind of approach just doesn’t make sense yet in software development that is the culture. First to market is often first to failure. So whether you are building software or buying software, it’s not just the upfront costs to consider but those nasty surprises that appear at 5pm on Friday evening when you have your camping gear packed but you’re going nowhere.

Thursday, 25 July 2013

Sins of Omission

One of my experiences growing up was learning the myriad of sins one can do as a Catholic. Frankly the list is huge. One of the sins that strikes me as a catch-all in case they forgot any is the Sin of Omission. So it wasn’t enough that you commit a sin but you advertently don’t do something to prevent another sin that is in your power to prevent. Or as Martin Luther King said
“In the end we will not remember the words of our enemies, but the
silence of our friends”


Now jump into software development. When specifications are created, which we should take in general as a good thing, there is an important aspect to consider. This is to read between the lines, to discover those items that have been left out, like non-functional requirements, concurrency issues, network issues etc.


The list of things that could be left out of specifications is large. Experience helps to spot areas that have not been specified or not specified in enough detail. Requirements lists or SRS documents are good places to start. If possible go back to the source to review those requirements. Never assume just what is on the paper is all there is to do.


Gaps in expected functionality is a big red nose day. Therefore it is good to have requirement traceability. Test cases directly related to requirements are hugely beneficial for testers and developers. There have been many times a developer has been grateful for a testers diligence in spotting a requirement that has not been coded for. Usually have the developer has reviewed the test cases.

Finally, to ensure those items that have been omitted by accident or lack of process, try to review the software as early as possible with the end-user, product architect etc. Don't keep your software a secret until the end. When requirements have numbers and can be traced, spotting those omissions becomes a lot easier. In the end traceability and early views mean you rely less on Hail Mary’s and more on sure things.

Saturday, 20 July 2013

The salesman’s promise, the engineer’s deadline

                                                               


I love salespeople, they are so full of the joys of Spring. They can talk so fluently about nothing when they really should listen. The art of making promises, is the ability to achieve them. Much of the financial crisis is down to financial advisor's selling assets, that were worthless. Whether they understood that or not they broke the world because they fundamentally didn’t understand what they were selling. Does that sound familiar?

Engineers are at the mercy of salespeople. A sales person will promise the earth and two weeks early if the commission is right. Contracts are signed, the expense card going over the bar and the chime of glasses knocking off each other. Is it ethical to sell something you have no control over delivering? Does ethics even come into sales?

The problem then is it becomes the engineers responsibility to deliver on those promises. And what exactly was promised? that prototype technology that hasn’t even been spec’d up yet? that new feature that was discussed in a meeting and all of a sudden is part of the product? If your job wasn’t depending on delivery, it would be funny.

So what can be done with this dilemma? Not much unfortunately. It would be nice if salespeople, engineers and senior management met up once in a while to discuss reality. But may be I’m just being too negative. May be as engineers we need to be pushed? Maybe we are too practical for our own good?

May be we need those visionaries to push our complacency to do those things the right way and achieve those things that are impossible. May be that is why we do what we do, so we can achieve the impossible and quietly tap ourselves on our shoulders and say, ‘Good job’. What engineer in Nasa wouldn’t have choked on his donut when he heard JFK say.

We choose to go to the moon. We choose to go to the moon in this decade
and do the other things, not because they are easy, but because they are hard..

And they achieved that deadline with over five months to spare. To software engineers around the world reaching deadlines set by someone else I salute you but to those engineers who achieved the impossible and landed men on the moon, you are the standard by which we set ourselves.

Wednesday, 17 July 2013

Some laws for IT

 



You will come across several situations over the years in IT where some knowledge about some general laws would help with planning and decision making. Estimation is one of the most difficult tasks facing software designers, developers and testers. In some cases, you may as well ask how long is a piece of string?


This is where Hofstadter's Law is relevant. If you are planning a task it will always take longer than you expected. The planning fallacy is a very important issue that as a software planner you need to be aware of. This is why we have contingency. We have to be aware that there are unknown unknowns, as Donald Rumsfeld pointed out.


To get an understanding of Hofstadter’s law in the context of software development it is good to take an overall view of planning methods and development methods. For project success, iterative/agile development has one of the highest success rates. This is because you plan for what you see ahead of you, not for what you don’t know.


It is good that you deal with each problem as it presents itself and do not waste time planning for the unexpected that may never happen. This is what often occurs when you use the waterfall approach. Estimation is easier when you build in small attainable goals, adjust project scope to deal with issues as they arrive and build on success.


This brings us to the next law, Brooks Law. The law highlights that ‘adding additional people late in a software project makes it later’. This happens when you are nearing the end of a project. Let us assume that approximately two-thirds of estimated time is completed, when it seems like your team won’t meet your deadline.


It occurs to you or someone else,usually senior management, that more people or inexperienced testers on the project would do the trick. This is where you need to know about Fred Brook’s Law. He wrote a book called the mythical man month. Steve Job’s explain’s it quickly. Just bear in mind that there are exceptions to every rule.


Think of Brook’s law as a good starting point. You can mitigate against the pitfalls, rather than being ignorant of the law and just throwing people at a problem and expecting a result. As a test lead beware of managers bearing gifts, i.e. extra staff, that later turns out to be more trouble than it was worth.

Finally be aware of the Pareto principle, also known as the 80-20 rule. This is where 80% of the effects come from 20% of the causes. This is particularly useful in software risk testing. Remember when you are developing or testing that the most important part of the work will be in twenty percent of functionality. Focus on the really important stuff and the rest will get sorted in due time. There are many other laws out there. If you have any favourites let me know.

Friday, 12 July 2013

The answer is in the forum

There is only so much one can learn from a technical book. In any software development office you will see large volumes placed on desks. Those books obviously aren’t bedtime reading. They are for reference but how often do you use them for problem solving as your first port of call? For many software developers and technical professionals the first port of call is the online forum.

There are dozens if not hundreds or thousands of forums out there. Obviously quality is important. Quality only derives from the user base and the level of interaction. What you will find is that forums are engaging with social media, so expect to login with one of your social network accounts and have conversations online with twitter. Even with social media,forums are virtual interactions. Maybe you should attend some real forums.

For example, you could attend the Intel Developer Forum. If you are an apple developer you will want to go to apple's developer forum and and online videos if you can’t. It's worth attending forums to get face to face time with your peers. It's a great way to challenge yourself. If you want a really good time you could start saving for Dublin's web summit in Ireland for an excellent summit and a great social dimension as well.

Of course if you have a special interest you could begin your own forum. There are many forum tools available to be able to do just that. What is important in forums is that you aren’t just an asker. Forums require people to answer questions, so do your bit to help others. Please send us your favourite forums and why they are.

Each language or discipline has it’s own group of forums that developers frequent. For example if you are a php developer Phorum prides itself on being the original PHP and MySQL based Open Source forum software which opened in 1998. There is also the php developers network which covers more than just php.

For particular languages, skills you might need to go to a site that is specific to that language, for example, JQuery, the forum at jquery.com is the place to go. There are general sites as well. You could use the DevShed, Dream in code, Daniweb, or Codeguru.

The question I have is whether forums allow people to get quick answers to problems without doing real research to find out for themselves i.e. actually using a book to get a solution? May be it is a case that searching for a solution in a book is just too difficult and ultimately books can’t address many unique individual problems that only forums can address through group collaboration.

Monday, 8 July 2013

The sow's ear

Software quality isn't a fluke, it is not a magic potion, you can't create a quality product using incomplete, inconsistent, or ill conceived requirements. It can't be created by a superhero in a company. It definitely can't be created by omissions in the design, requirements or functional specifications or agile backlog. Software quality is hard earned.

The space shuttle Challenger blew up on January 28th 1986, 76 seconds into its flight. This wasn't a software failure but a management, engineering and quality failure. There were some software aspects to the problem but they were not critical to the overall failure. Even though engineers voiced concerns, management proceeded with the launch. There are lessons to be learnt from that day for software organizations.

The main lesson here is that a failure begins from the starting point. If there is not enough robust processes in place to take into account not just software failure points but also peoples and teams failure points then it is only a question of time before errors are introduced into the system. In a lot of software, errors are manageable but in others it can be fatal.

It ends where it begins. If it begins badly, it will end badly. If your design process is brilliant but your development processes are immature then this is where your end begins. Therefore expectations need to be set accordingly. Quality is frequently beyond a tester's reach because it is a management and team objective not just a tester's job. To make quality outputs you need quality inputs. Like that old idiom, 'You can't make a silk purse out of a sow's ear'.





Saturday, 6 July 2013

What doesn't kill me

Nietzsche said 'What does not kill me makes me stronger'. Well if developing or maintaining software doesn't kill you, does it make you stronger? Software development has been a discipline now for about fifty years. What have we learned? Well what I have learned is that writing code is easy, writing code for someone else is supremely difficult.

This blog is about lying on the software couch to explore the inner thoughts of all those who have bought, designed, coded, tested, project managed, made operational, upgraded, maintained, and replaced software. Even those who have sought their money back. Good luck with that.

I also want to offer my condolences to all the people that software has inadvertently killed, maimed, bankrupted, prevented access to their money or allowed their money to be stolen. I want to say sorry for all the hours people have wasted trying to rebuild systems, data, lives after a virus has decimated their existence.

Software is both a giver and taker. When you sit on the couch you have to respect it but you can also blame it for all the problems in your life. Like any good psychiatrist will say, 'Leave your past on the couch but your cash on the table on your way out'. And if they don't say that, its what they are probably thinking.

I hope together we can analyse the truth about software, all its intricacies and maybe create a new roadmap for the next fifty years...