CareerBuilder surveyed IT managers in the United States in charge of hiring. The job site subcontracted the interview work with these IT managers out to Harris Interactive, which did surveys from November 15 through December 2, 2010.
When the numbers were all tabulated, 42 per cent of the managers contacted said they planned to add permanent, full-time IT people in 2011, up from only 32 per cent who said they would hire full-timers in the IT department a year ago. Sixty-six per cent said they will be increasing the compensation of their existing IT staff in 2011 – the average expected pay raise works out to 3 per cent – and 56 per cent of those polled said they were worried about losing their best employees as the economy continues to improve. Salaries for new positions are expected to go up by between 1 and 3 per cent.
British Gas is suing Accenture. Accenture put in place a SAP based system which led to massive complaints against the gas supplier. It turns out that Centrica, British Gas parent, wrote off about 300 million dollars following errors with the system.
British Gas is seeking a multi-million pound damage for the installation of the billing system, which, “caused huge disruption” for the company and its customers. British Gas claims the billing system was riddled with “millions of errors.” Accenture is claiming this is “inaccurate” because it was probably on one million errors not millions, but who is counting.
A preliminary appeal brought by Accenture against British Gas was tossed out by an English judge. “British Gas is now one step closer to holding Accenture to account for the disruption caused to our customers.”
This lawsuit is paving the way for other “users” to sue its outsourced IT development.
Is History Repeating Itself?
About one hundred years ago blacksmiths were considered a highly skilled occupation and like software development, it was labor intensive. While the blacksmith had been around for centuries, it was the Industrial Revolution that created a rapid growth in employment from 1880 and 1915. The blacksmith was critical to the Industrial Revolution, and the software developer is a critical component of the information and knowledge revolutions.
If, in 1915, someone would have suggested to the million plus blacksmiths employed in the industrialized economies they would be obsolete in less than 50 years, they would have thought that person crazy. The idea of working with metals, fabricating metals, did not evaporate; it was the role of blacksmith that became obsolete. The role of blacksmithing turned into ironworkers, and those blacksmiths that did not learn the new skills of ironworkers were not able to find employment.
Instead of creating everything from scratch metal workers (weldings) began to assemble parts and pieces together. We are seeing this same basic trend in software development today.
As software development rolls down the road of progress, the programmer will become obsolete; and the idea of software developer will continue into the future. I imagine there are those reading proclaiming, “You will always need someone writing code,” and I am sure there were those blacksmiths who could not imagine a world without them, either. It will be a combination of automation and outsourcing that will make the Western programmer obsolete.
The story of the blacksmith does not end with the decline of employment. Today blacksmiths are artists and a novelty profession. The British Artist Blacksmith Association (BABA) continues blacksmithing as an artist profession as well as offering courses on blacksmithing, and they have regular events.. It has nearly 700 members worldwide and their members create brilliant works of art.
 United States Statistical Abstract 1915. Page 233 Table 158
One of the hardest things to do is to discover the simplest solution to a problem. To often software developers come up with the most complex solution instead of the simplest one.
The simplest solution is the solution with the least amount of functionality to solve the problem. This makes the solution simple to design, simple to code, and simple to test too. Another advantage of simple solutions it is easy to document and communicate.
Software companies are being held accountable for problems in its software projects, misrepresenting what a software product does and being deceitful project timelines. A British judge also said the Red Sky software development company should have better understood the requirements of its customer. An earlier court ruling found that EDS misrepresented project timelines and was what its software product actually did. It sounds like the end of vaporware.
Red Sky sold hotel management software to London’s Kingsway Hall Hotel but the Hotel found problems with the software immediately. Kingsway Hall complained and called customer service and got customer no service instead. The software company knew of problems with its software and failed to disclose those problems because it wanted Kingsway to buy its software. It is simple as that. The question remains should a software company disclose known issues to its customers. It turns out British courts are saying yes. Red Sky should have told its customer of problems with the product when demonstrating it and chosen more demonstrations for it that more closely matched the customer’s own business requirements, the Court ruled.
Does any other industry believe or think they should not be held accountable for product flaws that may cause its customers harm or injury. Red Sky tried to rely on a clause in its standard terms and conditions which said that the only remedy available to customers if the software did not perform as advertised was to make use of its maintenance and support functions (a.k.a. call customer service).
Clause meant that Kingsway could not sue it for a refund on the software or for the additional costs it incurred as a result of its failings. The High Court disagreed and said that Red Sky’s clause was unfair under the Unfair Contract Terms Act. It said that this Act applied and protected Kingsway because negotiations between the companies had been one-sided on the issue of liability. His Honor Judge Toulmin also said that the software was not up to the tasks that Kingsway needed to use it for, and which Red Sky should have known were part of Kingsway’s needs when buying the product.
This decision is on the heels of an earlier decision. The High Court ruled that EDS had lied about its software when selling it to BSkyB and awarded interim damages of £270m (about $400 millions) against the software supplier – ouch! The court also agreed that EDS had been deceitful in pursuing the contract, finding that the information technology company had deliberately misrepresented how long it would take to complete the job. BSkyB Wins Legal Victory Against EDS -
http://online.wsj.com/article/SB10001424052748703906204575027303086931726.htmlHigh Court rules software liability clause not ‘reasonable’ http://www.channelregister.co.uk/2010/05/12/red_sky_liability_ruling/
Software Psychologist – help software organizations over come its fears and phobias.
Software Psychiatrist – same as a software psychologist but they prescribe drugs.
Software Archeologist –dig around looking for project artifacts.
Software Paleontologist – dig around for looking for evidence the project actually existed. They also theorize what killed projects. It turns out most projects commit suicide.
Software Actor – they don’t actually do any project work. They just act like they are working. Software Actors attend a lot of meetings and repeat what others say. Software Theologist – pray for project success.
Software Plumber – unclog software projects. This is not a glamorous job and it requires cleaning the project toilet.
Software Janitor –pick up after everyone else.
Software CSI – study the forensic evidence to determine if a project was murdered or committed suicide. By the way most projects commit suicide.
Software Entomologist – collect all types of bugs found during the project.
Software Zoologist – studies all kinds of animals that work on software projects
Software Tap Dancer – dances around difficult project issues
Software Linguist – helps translates the native tongue of a software developer into English.
Read more at www.RebootRethink.Com
My friend Grant Rule posted an interesting question on LinkedIn. He asked, “What is the purpose of software?” To me the answer is obvious and the purpose of software is to solve problems. Too many software applications are being built without a clear problem to solve. Too many in the field of software development focus on what the technology can do.
Let me make an analogy for you. I travel a lot internationally and I went to my bank (Bank of America) and asked for a line of credit. The banker said,” of course we can give you a line of credit” and then she asked, “what problem you are trying to solve?” I explained that I travel a lot international and run up large expenses. The problem, in my mind, was the time between when I was paid by a client and I had to pay my credit card bills. The solution, in my mind, was a line of credit. Notice I had the problem and solution well in my mind. Then said asked me if she could offer a potential solution. She suggested, “Why don’t you ask your clients for a percentage upfront to cover your expenses?” It turns out I did not need a line of credit at all. I have taken her advice and it has worked well.
To many “customers” of software applications do not know what problem they are trying to solve and therefore cannot offer a solution. Tom Kelly (The Art of Innovation) points out too customers do not have the ability to articulate what is wrong and especially what is missing. So if the purpose of software is to solve customer problems, and customers cannot articulate what is wrong and what is missing, then exactly who is suppose to articulate the problem and potential solution?
Anyone who has ever chugged along trying to their teenage child how to drive a stick (manual transmission) can appreciate the complexity of the task. No doubt It is more complicated to teach a teenager (or anyone) how to drive a manual transmission than an automatic transmission. The reason being is in an automatic transmission much of the complexity of driving has been hidden away and is not seen by the driver.
The complexity was not just hidden it was transferred. It was transferred from the driver to the transmission because an automatic transmission is more complex than a manual transmission. An automatic transmission is more complex (and expensive) to design, build, and maintain too. As software development matures we see much of the complexity being hidden from users. As an example, look at the complexity of booking a hotel reservation or airline reservation. Most of the complexity of has been nicely tucked away. It cost a ton of money to hide all that complexity and functionality. Once upon a time it took a trained travel agent to book an airline flight. Nowadays just about anyone can accomplish this task.
My teenage daughter drove to school today chugging and grinding the gears. In due time she will learn to drive a stick shift. The same is true with software development. We are chugging along and grinding the gears trying to transition from internal applications (exposed complexity) to customer self service (hidden complexity)
Like a lot of people I put my resume on job sites. Yesterday I was sent an automated human resources message. It read, “A job opening matching your profile for a position of Sr Principal Agile Coach has just been posted in our Career Section.” There is nothing in my resume that shows an interest in becoming an Agile. I thought well, perhaps, the human resource bot searched the internet and got a lot hits on David Longstreet and Agile (there are over 500). Perhaps it was my article, “Agile Methods and Other Fairy Tales” that got the bots attention.
Perhaps it was the fact that those professionals in Agile wrote that I was a troll or “a so called international consultant.” As an FYI, when anyone starts a sentence with “a so called…” what follows is not going to be a complement.
I decided to apply for the position to see what happens and I will keep you all informed.
For those who want to read my ideas on Agile (and for those HR bots) you can see them at http://www.softwaremetrics.com/Agile/