Context it!!

We have done a little backtracking with regards of the original way we planned to handle assertions. Interfaces and abstract classes will be handled the same way: context strip.

Here is goes another snapshot of the work-in-progress:

Busy Signal!

So I was working rewiring the GUI engine while it occured to me that the cell phone providers could have improved their support for the CDC platform and there were more emulators which support it (and java.awt.Robot which we do not need to run inside phones/pdas but it would nice to have)

The surprise is that they have improved their support of CDC but not so deeply. And from the answers, it seemed to be a weird question.

This is the type of things that I do not understand: with everything converging into everything, PDAs as powerful as older computers. Why are they waiting? Do they want to fall into the same trap the PC software fell?

I know of big blue companies that have teams of people tapping on PDAs to see if the app works as expected. After a while who is going to change that process and miss a deadline?

Ahh, the return of the keystone cops...

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