Friday, March 31, 2006

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?

Labels: , , , ,

Thursday, March 30, 2006

Some shots from the last 4 months:

Despite the intense efforts to set up our camp here we have managed to have some leisure time:


This is the view of downtown Vigo and the Ria from my friend Luis’ Surf Shop. Vigo is the biggest city in Galicia and thriving fishing port, business and tech center.

The Xunta (Galician government) has designated Vigo as the I+D+I (R&D) hub for the NW.

We will be moving there soon. It is pretty close to a bunch of quality surf breaks in Spain and Portugal.


Talking of Portugal. This is a view of the fort in Valença. This is the first city across the border in Portugal. Tui (Galician city just on the border) can be seen in the far.



The photographer :-} climbing the sand dunes and rocks around Costa da Morte on a flat day.

Costa da Morte was “notorious” in 2002 because of the Prestige’s oil disaster. Things have apparently gone back to normal.



These are the stairs that take you to the “Alameda” in downtown Santiago. From the top you can see the south campus of Universidad de Santiago de Compostela. It is a nice view.



This is another beach around Costa da Morte that same flat day. Flat in surfing lingo means no waves.



This is me on a cold December morning trying to surf with the monkey suit. This was one of my first surfs with a wetsuit in more than 12 years. It was painful to paddle and move so slowly.

But as they say: no pain no gain.



Lastly, the little fellow, charging towards the drawers...

Labels:

Tuesday, March 28, 2006

The cargo arrived!

Several weeks after their promised date (actually, 2 months) our belongings will arrive on Thursday..

It is going to be an experience to match the actual shipment with the shipping list they used to overcharge us.

On to a more technical subject, I still remember that a few years ago MS adopting a new QA technology/approach. They were going to use more static analysis (SA) based tools internally and these tools would be part of the next VS version (VS 2005)

After the Vista mess, what can the public expect from VS 2005 or Vista?

I am not against MS. First, it's too big and too important to waste time bashing or fighting it.

The outcome of this most likely would be people shelving SA tools. Despite this failure, I think it is still a really impotant technology. It just needs a new marketing/tech mix.

Off to make run for the boxes...

Labels:

Monday, March 27, 2006

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


Labels: , , , , ,

Tuesday, March 21, 2006

Correction: the new engine is faster (25-200 times)

We have been updating the performance comparisons of our new architecture against the competition. As mentioned before, we currently have numbers for the java/eclipse product only.

The performance comparison was to measure how much time would it take to execute a suite that exercises 19 methods of the form:

public XX ReturnXX(XX param){
return param;
}

Where XX is an native type or its equivalent in the java.lang package. We ran one set where every test was a failed one and another set where all were successes.

The idea was to measure how efficient the engines were at handling different amounts of work. A failure should take more work than a success because the engine has to report where the failure is.

The numbers are better than we thought. In the all-failures scenario our engine is, consistently, 25 times faster than Junit. In the all-successes scenario our engine is 200 times faster than Junit.

With the advantage that we can handle all types of access to methods and fields, and strict gui testing.

We will be updating the white paper with these new figures and snapshots of the product, soon.

Well, that's all for now...

Labels: , , , , , ,

Monday, March 13, 2006

A Snapshot of the Eclipse plug-in!!

NOTE: The GUI capture here is
obsolete for a newer version please visit:

http://efekctive.com/picture_library/blogging/devriot-ui-new-linux1.gif




Copyright José Cornado (c) 2005-2006

There are a couple of things to notice, we think:

The user just needs to provide the parameter and expected return
values. The rest is optional information: an ID to execute the test in a particular order, pre-conditions and post conditions of the object under examination, number of times to execute, and load/stress level.

The method shown is private, but our technology can still reach it. It is really poweful and dynamic. One of the advantages of this feature is that your QA investment is immune to Refactoring.

As several people have noted over different lists and forums, Refactoring can (and does) make public or protected methods private.

In this case the QA efforts are lost because Junit, or Nunit for that matter, just can not handle the change. What to do? wait and let the code base grow without testing? risk to lose several weeks of QA development? or just do not use refactoring?

Another is the ability of testing even the exceptions (type and contents) thrown by the logic under scrutiny.

Also, this is the same interface that will be used to handle GUI testing. Nothing to capture :-}

Labels: , , , , , ,

Saturday, March 11, 2006

The new architecture/engine is fast

The new architecture that I mentioned in the previous post refers to our automated testing engine. Please note that:

  • It is a testing engine, not a GUI only testing engine or an unit-testing only engine. It's both, so users have to deal with one test tool only, we hope.
  • It works as an IDE plug/add-in or as a automation server.
  • It does not force Capture & Replay, writing code or scripts on the user. It uses what we call Reduce Input/Output Testing.
  • It is platform and OS independent. For example, the gui tests created under Linux can be executed in a Windows environment.
  • It is language independent.

Now the numbers: the average execution time per test (unit or gui) of our Java product is less than 1 millisecond. Junit throws in the same environment a lower limit of 20 milliseconds per test.

This is a performance increase in excess if 2,000%, so imagine that your QA technology performed 2000% faster?

To put in a nutshell, our goal is to provide a technology that minimizes the users' effort (input), minimizes the post-test creation maintenance (input), and executes faster than any competitor (output) thus making the user more productive.

The .Net version, even though is still under the old architecture, offers similar performance numbers when compared against Nunit.

Well, that's all for now. Hopefully, I will be able to get back to Amber and .Net pretty soon...

BTW, our most recent white paper is this (password: AUSTIN).
(The images are old though. We will update them shortly)

Labels: , , , , , ,

95% Arrived!!!

Well, after going through more moving follies than anyone should write or read about, we are finally in Galicia. For now, we are in small town in the countryside not too far from Galicia's capital, which is Santiago de Compostela.

Our furniture is still on its way "thanks" to our movers which I'd like to call the Keystone Cops of the shipping industry.

In the meantime, I lost my working laptop with my copy of VS .Net which has prohibited me from doing any work on Amber or our .Net technology.

I am doing my best to get a copy of VS .Net so I can resume working on any of those.

As a side effect, I have been dedicating my efforts to re-architect our Java technology (with extremely great resu
lts I might add) and set up camp to write a meaningful business plan; look for financing, technology partners, etc.

Surfing? Not as much as the doctor prescribed but the dosage is going to improve soon...

Labels: