Skip navigation.

Design & development

Software Performance Engineering

design & development | performance testing
Trying to make some suggestions for Building Responsive and Scalable Applications panel I contemplated for a while on this topic.

For a long time we have Software Performance Engineering addressing these issues. As it described in the books and papers of Dr. Connie Smith and Dr. Lloyd Williams, it looks rather as a methodology for me.

The short and the long of IT: two videotaped presentations

context-driven testing | design & development | development methodology | functional testing | test automation

Since the middle of the year, I’ve presented and facilitated about 12 hours of sessions at 2 traditional and 3 open space conferences, plus a Googleplex visit. Two presentations are now on video, both filmed on the other side of the world from my usual location of Melbourne, Australia.

A lightning talk (at the functional tools workshop held before Agile 08 in Toronto, Canada) called Shades of Green discusses how the “green” passing tests of functional automation may not be as green as they seem. Note the static pose to stay within camera range, compensated for by the wildly waving arm. And yes, the audience was not limited to a leg and a foot.

An order of magnitude longer at around 50 minutes, a Google Tech Talk (filmed at the San Francisco Googleplex) called 80:20 Rules! Building Software Smarter looks at formal and informal ways to get significant improvements in creating software, including various puzzles and questions for viewers. I had looked at some tech talks by other people I know, and they had been watched around 1000 times over a year or so. It looks like I may hit that mark only a few days after the video was posted which is great. I hope my talk inspires people to build their software smarter. Can I turn “shades of green” into a similar talk? Probably not!

ISubmitBlogPosts - a nice twist on Apps Hungarian Notation for Interfaces...

acceptance testing | design & development | java

I've been pairing with Andy Palmer over this last week. I have to say it's been a lot of fun... and I think we've learned a lot from the experience. One of the things I learned from Andy this week was an innovative use of Hungarian notation for interfaces... Andy told me about Udi Dahan's presentation on intentions and interfaces (PDF)

Pitfalls of the "Waterfall" Approach to Performance Testing

design & development | non-functional testing | performance testing | performance testing patterns
Looks like the pre-production validation approach to performance testing becomes typical for large corporations (if there is any at all):

-get the system ready
-develop all scripts requested (sometimes offshore)
-run them all together
-compare with the requirements provided
-allow some percentage of errors according to the requirements
-involve the development team if requirements were missed

The P28 virtual fence: Borderline success or virtual vaporware?

design & development | perspectives | reliability testing
I’ve already noted some of the issues around the virtual fence here. In May 2006, George W. Bush called it “the most technologically advanced border-security initiative in American history”. In a flash of originality, the 28 mile virtual fence in Arizona was called Project 28, or P28 in Chertoff-speak. Micheal Chertoff has now accepted the fence system, on the basis that “all of the defects” in the prototype project were either “cured” or “immaterial.” He also said “In some form or fashion, technology is going to be virtually every place on the border, but it’s not necessarily going to be in the configuration of P28,” The chair of the House Committee on Homeland Security, Representative Bennie Thompson, sees it differently, “The poorly structured contract that prevented the line Border Patrol agents from pointing out obvious flaws and caused an overreliance on contractors has resulted in a system that has been described as providing ‘marginal’ functionality at best,” I wonder if he was tempted to say the Border fence had borderline functionality. [grin]

The technology stack on top of each tower looks impressive . The project is anything but impressive , with many of the issues typical in the IT industry: badly underestimated effort, not involving users, and not enough testing, While there was evidently a push for reuse of existing systems and components, it caused many difficulties: trying to base the system around a law enforcement dispatch system (!) that couldn't scale, trying to use off-the-shelf components that weren't designed to integrate, and a lack of standards for the sensors. The builder of the system, Boeing, has only taken 3/4s of the $20 million fee, granted a $2 million credit, and apparently paid $40 million to get this far on a project that will now finish in 2011, not the end of this year (which was already a year and a half past the original schedule). That will only be phase one!

CMG Opens Its Content to the Public

architecture | availability testing | databases & SQL | design & development | non-functional testing | performance testing | performance testing patterns | performance testing tools
The Computer Measurement Group (CMG) is making its conference proceedings from 1997 through 2005 available to the public. I believe that CMG holds the best practical conference in performance analysis, capacity planning, and related areas. In addition to the areas listed below, I'd definitely add performance testing. Here is the official mail CMG sent:

Education

architecture | design & development | non-functional testing | performance testing
With great interest read Who Killed the Software Engineer? (Hint: It Happened in College) by James Maguire as well as the original article Computer Science Education: Where Are the Software Engineers of Tomorrow? by Dr. Robert Dewar and Dr. Edmond Schonberg.

Performance Requirements

architecture | design & development | development methodology | non-functional testing | performance testing | performance testing patterns
My performance requirements paper was published in the January issue of Software Test & Performance (pp.18-24).

It was simple: I just sent a draft – and now I am reading it printed. With a new name - or even two: it is referred as You Can Gauge Performance Without Requirements in one place and Gauging Performance in The Absence of Measures in another. Not to mention other minor improvement.