The World According to Tarp...

It is amazing: to connect our Ipod to a brand new Imac we need to learn black magic (it is well documented on the net), to connect it to an XP laptop, it is a snap.

A well known open-source project just got kicked in the rear because of quality problems.

So, MS' QA/QC outspends everyone in the industry to follow XP with a stinker, it is easier to connect an Ipod to XP than to Imac, and the open-source project does not seem to fall too far behind these two.

And then some americans are wondering if USA lost the "financial" leadership of the world.

After two humongous bubbles in less than a decade apart, and over-leveraged consumers (whose spending accounts for 25% of global GDP) isn't that question superfluous?

Patent me up, patent me down...

Well, MS and the FSF are at it again. It is a pretty interesting debate.

Having participated in open-source project and used open-source software, I have certainly enjoyed the benefits of both worlds.

I was reading the argument of both legal experts. On the MS side is nothing new. These are our patents and we want to protect our IP.

On the FSF, is where the legal fireworks are because they have/want to prove that software is not patentable. Thus it should be free.

Their argument is that software is a mathematical algorithm (this is my interpretation, and I am not expert in U.S. IP law) and such is made out of numbers and nobody can own numbers.

This argument kind of equates software to natural resources: air, etc. The problem with this argument, I think, is that one can not find Linux, GCC, or Windows floating in the atmosphere or growing in a field. Somebody sat and came up with the algorithm. And it is for this person to decide what it wants to do with it.

Should oil be free too? Could "joe doe" drill where Anadarko has spent thousands of hours of expertise and hefty amounts of money to find oil for free? At least natural resources are easier to spot.

This seems like going the tragedy of the commons route. Not even China is on that road anymore.

Like the lawyers around here say: "es mejor un mal acuerdo que un buen juicio"...

Insuficient Pleople V6 part 2

A couple of days ago, Fortune published an article that was pretty telling: how big tech companies need to grow.

The article argued that these businesses needed to find ways to produce more products , cheaper than they are doing it now, to sell them in less developed countries. But the first question that came to mind was: aren't they (people in less developed countries) already producing those goods?

So, the article left two choices: find a cheaper place to produce those goods, but then how do they buy the goods? The target customer is the white collar worker/business that has certain purchasing power and disposable income (I do not see, say, people from the favelas in Rio worrying too much about getting the latest Cisco router, they have bigger concerns)

So to sell them goods, the article argues to take the jobs away from them.

This point of view assumes that those countries just live from high-tech. Obviously, this is not true, there are an assortment of other industries in a country like Mexico or Chile.

But what would happen in India, on of the emerging super-powers of the future? Where high-tech is one of the major economic forces?

Where was I?

"Quality is in the process not in the product" This tidbit of info from Deming is truly valuable. How many software shops use most of their budgets in hiring the best and brightest developers but have a much lighter quality control group? Like the 30 developers, 1 qa shop mentioned the other day.

Just from MMM, we know that there is a 30% chance that a change in one line of code will break something else downstream. Let's think about all the changes that occur in a day with 10 developers. It does not matter how good the developers are, things happen. Ask Nokia or MS.

So, it seems that the quality process should be a prerequisite to a good development team, otherwise the effort of that talented team is less than effective: how many companies with truly competent developers release products late that require patches?

The process, I think is what is missing: not a checklist of things that when in place they make a process. Saying that we need a rocket to reach the moon does not make anyone a rocket scientist.

The Keystone cops strike back! (Addedum):

The other tidbit of wisdom that Deming left around to be used was the fact that quality is in the process not in the product.

The Keystone Cops strike back!!

A couple of weeks ago, there was this exchange on one of the usenet forums where the original poster was at a loss asking for help. He was the only and new QA/QC in a software software shop that had 30+ developers.

Tall order. A lot of people chipped in, myself included. But there was one posting that struck me because it was odd. The post argument was that because QA/QC is a "support activity" (that encompases with debugging around 80% of any software project) the solution was for the guy to start his own quality movement in the hope that help would jump in after a while. Apparently, this approach was suggested in a tech book.

If one were to contrast that approach with Deming's TQM (something hard to argue against: Toyota, etc...) is a failed Quality 101. Deming's work proved that quality has to come from the top of the company to be really successful.

So what is a "support" guy to do?

Then the answer came through this posting on GK blog: the fad du jour. It is not a secret that a lot of companies manage by fads. These ones do come from the top.

So until quality becomes the fad du jour (FDJ) and stays that way long enough the "support" guy has to go with the FDJ, or risk being fired, or quit.

And top management will not support Quality until...

The cycle repeats itself: Vista is nowhere to be seen and this is the most visible one. What about the ones that do not get as much press coverage?

Real-Politik plus 150

Reading The Economist's article about MS and the beating that its stock price took, I couldn't stop thinking about the realpolitik that should be going on inside.

Traditionally, within an organization, groups become important and gain budgetary weight if their size increases. It is a matter of visibility.

This is important because the leader of that group, say the VP of engineering in a software company, will get stock options or bonuses depending on that visibility.

People are rewarded by the responsibility and visibility they seem to have, not by the improvements in their groups. So, for a Director of Quality Assurance of Acme Software, having lots of people is the way up.

And for this Director, becoming more efficient by testing more with less people is not a particularly enticing proposition. Especially if the credit for that improvement goes to someone else.

If on top of that there is a chance that in the past, some releases were less than acceptable and the CTO or VP needs to do some cyb'ing, what we have is the makings of a royal mess: The VP/CTO trying to cover her/his back, the Director of QA protecting the turf, and a product's quality going down hill.

It woudn't surprise me that something like that is going on inside MS.

_________________

Well, we have reached 150 downloads of the white paper.

This number is more than we expected, and we appreciate the feedback we've gotten.

We would love to see more feedback. Please feel free to email me directly with anything, we mean anything, you have to say about the paper.

http://efekctive.com/blogging/wp/quality_advantage_V2.pdf

Who needs a cheaper, faster way of creating software?

Last week, I asked people from different groups on the web to give me their thoughts/opinions on the white paper. There were favorable opinions, not so favorables ones, and suggestions.

But the thing that struck me the most was when it was argued that the difference between software and the Ford example is that Ford and the assembly line tried to produce goods with least amount of difference between them at a maximum rate and at a minimum cost. I do not understand how this does not apply to software.

The argument went on to saying that software is different because it is an intellectual effort. The logical continuation of that argument should be to figure out which parts of software development are intellectual: design, writing code, code reviews, all yes. QA? just the test creation.

How much intellect is needed to: pick up the latest build, install it, run the tests, and report the results to the appropiate personnel as fast as possible so problems can be addressed promptly? Not much. It is know-how easily transferable to machines.

Furthermore, even the creation of the vast majority of the tests can be automated with the technology available today. It would be a matter of some unorthodox thinking but in theory is possible.

The way I see it is: machines are really cheap today, if we are able to push the bulk of the less valued added tasks to them, software companies will be able to free resources to high value added tasks. But, hey these are just my ramblings.

I need to get back to the code and the hardware emulation layer...

Bibliographic Sources and other tidbits...

Thanks all for the feedback so far. It has been useful and it will be reflected on the paper.

One person asked us to let people know the sources we used in our research. Well, they are listed at the end of the posting.

The Marketing plan is coming along. The branding chapter of TAOTS has been quite useful lately. That together with the refresher course I am taking at IGAPE (which is the local governement economic development arm, more on Spain's daunting-for-the-non-initiated political and geographic map later)

It is an interesting group of people: the woman giving the seminar is from Vigo, lived and worked in Madrid and London and came back to Galicia. There are a couple of guys from the Mediterranean coast who are on their way to open an B&B/pilgrims refuge in one of the most beautiful places of Galicia (in Lugo Province just on the French Route of "Camino de Santiago")

When I have better details of the B&B, I will forward them.

Perspectives on Business Innovation, Issue 1 "Five Myths that Slow Down Software Development" by Cap Gemini Ernst & Young

Valuation: Measuring and Managing the Value of Companies, by McKinsey & Company Inc., Tom Copeland, et all (I would recommend just the first 2, maybe 3, chapters, the rest is kind of repetitive)

What high tech can learn from slow-growth industries, The McKinsey Quarterly.

"A Better Bug Trap" in Technology Quarterly, The Economist.

Good Ol' Bean Counter, where art thou:

There is this study published few years ago by Cap Gemini Ernst & Young which states the following: 65% of the in-memory image of a software program belongs to software developed by a third party.

Put this figure together with the NIST stats (80% of a project is testing and debugging) and the magical number is 52%. Any software project could use up to 52% of its resources (time, people, etc) executing somebody else's software.

And doing the marketing research update for the BP, I ran into Mercury's QTP 8.X.

This tool allows users to continue using capture & replay through another layer of indirection (their ActiveScreen feature)

So a capture & replay user just interested in:

button1_clicked(because is the only logic that she/he can modify)

has to wait for the tool to execute who knows how many screen repaints, OS and specific tool calls (all of which are third party) to get to the real test target:

the fabled "button1_clicked".

How many more tests could be executed instead? Aren't we always short of time for quality? Are we using the time we have wisely?

On the same token, if we could get rid of the extra layers of indirection. Could we test everything all the time?

The Mythical Man Month considered this not economically/physically feasible. But back then the computing power was in its infancy and most of the production of software was done manually. Is it possible now?

Software Development & Europe, a mirror

I am about to hit the BP again but could not stop thinking an exchange that I had with someone on usenet. This person who also teaches proposed that automated testing is not relieable and the only solution is manual testing (not exactly with these words but that's the only conclusion that could be drawn)

But when confronted with the economic reality of the fixed physical throuput capacity of humans got into trouble: what to do with a growing codebase? was he going to force people to move their hands and eyes faster? So his only solution is to use more inputs to produce the same good?

This is bad lesson in economics 101. It should take less inputs to create a good over time. That is in essence efficiency.

This is the same approach as "pair programming": adding more people to see if they make it work. If recent ship date delays are a guide, adding people to a flawed process just does not work.

So here we are several years after the tech bust we are, in short, running to stand still:

Manual testing advocates think they can get it right after 25 years.

Traditional testing tool companies have "somewhat fixed" the problems they created (quoting a Forrester report) But what about non PC gadgets? Can they run inside a Pocket PC?

An XP advocates think that the solution is to add more people to:

1. Ask developers to write their tests, as if they had time to write their own code.
2. Ask developers to add special code so they can write their own tests.
3. Ask testers to write code that is going to become useless in the next round of refactoring.

And then came France and its PCE (first employment contract, or close enough) the students and the unions kept the PM from turning PCE into law. The PCE was an attempt make France's laber market more fluid and create jobs.

PCE is not a law which may have been a bad law but France and Europe in general need something along the changes that are needed in the software industry:

The population is growing old, so more immigration or more natality is needed.

In 2004 just Spain had positive demographic growth.

According to the OCDE, just 2 european universities are among the top 20/top 50 in the world. The rest are in USA, Japan, India, etc.

These two are english. According to a survey published recently when Europeans emmigrate, they mostly choose England because of the jobs and pay.

With China and India growing into world powers, what is Europe going to bring in the future to the table of big decision makers?

Education? Job opportunities? a healthy work force?

Anyways that business plan is waiting...

About the Keystone Cops, The Cart and The Horse:

The vast majority of the software projects that I have seen, in one way or another, always made me think of the Keystone Cops (the early 20 century comedians) trying to compete in F1 with a car with square tires.

It doesn’t matter how hard the Keystone’s try to push, or how many of them are pushing, the car will not run at all or fast.

If the tires were round, the requirement of Keystones will be less and there will be a chance of winning the race.

Now let’s go back to software. What happened during the last 20 odd years?

People trying to reach first mover advantage set up companies that could not maintain that advantage. In other words they set up themselves for failure in the future: near, medium, or long.

Everything needed to be fast: quality? Effieciency? Next release. But once the ball got rolling, who was the one to improve the process when there were two more deadlines in the coming months?

So the sound marketing principle of “It is cheaper to keep an existing customer happy than acquiring a new one” went down the drain by consistently having quality problems.

The MS case is interesting because they are the ones who tried to use the 1:1 ratio or something close to it. But these inefficiency problems are everywhere.

I guess this event it is going to put a new twist in to outsourcing. Why look for cheaper labor, in the hope to increase the head-count, if increasing the head count does not solve the problem?

I do not have anything against outsourcing. But does it make sense to outsource a flawed process? Do we need more people or a more rational use of all the resources at hand?

The economic impact of delayed schedules and bad quality software (lost sales and extra expenses) should be measured not only for MS but for the whole industry. I guess the figure would be mind-boggling.

On to other things: I just found a beta version of VS .Net 2005 (a year to use after installing) Hopefully it would work still, so I can go back to our .Net engine or Amber.

I was just checking the new Junit release (4.0) It’s looking like Nunit but in Java.

But the same flaws remain in both: why would a user care about anything else but the input and the output of a test? Why expend so many resources executing the inner workings of these two when so much logic under test remains unexecuted in gthe overall process?

More Evidence...

Earlier last week, before MS announced delaying the initial release of Vista, there was this exchange in one of the Google groups about ratios, developers to QA and others.

One of the postings stated that MS currently uses a 1:1.1 developer to QA ratio. I knew that in the past they used a 3:2. I replied that it seemed like an aberration. It was the equivalent of Henry Ford packing the plants with workers and ditching the assembly line, I stated.

And voliá! two days later Vista is delayed for the consumer market. Who knows the state in which the corporate clients will get the other version of Vista.

This event reinforces the main points of our white paper: it's not a matter of how much money or people you throw at this problem. It is a matter of reformulating the problem to solve.

Anyways, there are a couple of screenshots (towards the end of this posting) of the Eclipse plug-in that I wanted to share with you, the intention is to compare DevRiot with Junit in terms of speed. This plug-in also complies with J2ME CDC.

So imagine that you could automate all the GUI/unit testing of your logic on any of the cool Nokia gadgets, or a PC running Windows or Linux?

In addition, my wife gave me as a present "The Art of The Start".

Hopefully, I will learn something :-}



Copyright José Cornado (c) 2005-2006