NOTE: All posts in this blog have been migrated to Web Performance Matters.
All updated and new content since 1/1/2007 is there. Please update your bookmarks.

Sunday, April 16, 2006

Software Engineering Matters

Inadequate attention to engineering creates problems later With the obvious exception of a few bloggers like Markos Moulitsas Zúniga, whose blog Daily Kos receives over a million visits per day, I think most bloggers are happy just to know that someone cares enough to read what they write. In my own case, having spent my career working on software performance, I learned long ago that only a small fraction of the population is actually interested in Performance Matters. So I don't expect a lot of feedback.

All the same it's nice to hear from a reader occasionally, and yesterday was one of those days -- I received a comment from Damith C. Rajapakse.

Curious about why a post on Waterfall Methods would be the one to generate a response, I did some digging. For readers who would like to hear about interesting stuff for the serious software engineer, Damith's blog -- Another Day in Mythical Man Month -- is worth a look. In particular, his recent post on maintaining future web applications (subtitled 'it's time to brace ourselves') is very relevant to my current focus on Rich Internet Applications. Damith notes that while ...
rapid development of Web apps is receiving the lion’s share of attention, maintainability of Web apps (is) hardly receiving a thought.
He warns about three trends that are likely to make Web applications hard to maintain:
  • The rush towards visual programming
  • Overuse of frameworks
  • Overdoing that 'AJAX ' thing
While it's good just to know that someone is reading what I write, it's even better when they have something useful to contribute to the discussion. And in this case I agree completely with Damith's perspective on the issues. Ten years ago, on the very first page of the introduction to my book about client/server performance, I wrote:
In today's world of visual programming, rapid development, and out-of-the-box solutions ... performance is one area of software design that is frequently misunderstood, forgotten, ignored, or postponed, often with disastrous results.
The same can be said of maintainability -- which, like performance, is always less interesting to software developers than creating new application function. That is why your software development process must ensure that characteristics like performance and maintainability are designed and engineered into applications from the beginning. In other words, it is important to realize that good Software Engineering involves a lot more than just programming and testing your code. According to Wikipedia, it is ...
... the practice of creating and maintaining software applications by applying technologies and practices from engineering, computer science, project management, application domains and other fields... Like traditional engineering disciplines, it deals with issues of cost and reliability ...
As I have noted previously, the complexity of Rich Internet Applications makes it essential to actually practice rigorous software engineering, and not just crank out code.

Waterfall Methods: Past and Ever-Present

Waterfall 2006 ConferenceIn my previous post, I commented that adopting a waterfall development methodology was not going to work well when developing Rich Internet Applications, because more agile methods were needed. While writing the post, I did a bit of research into the literature about Waterfall methods, a concept I clearly recall encountering for the first time in 1978 or '79 soon after I joined IBM's DB2 development team in the Santa Teresa Lab.

My own introduction to the Waterfall method was in a talk about its limitations. So it was interesting to read Tarmo’s psycho and techno blog explaining that the very first description of the model by Winston W. Royce in 1970 was also as a counterexample. This point of view is amplified by Conrad Weisert, who claims that in fact there's no such thing as a Waterfall Model!

But despite the fact that (maybe) it should not exist, the Waterfall model has taken root. This is evident from the fact that it merits a place in methodology comparisons and analyses. What's more, despite the many rumors of its demise, especially in the face of today's need for more agile methods, researchers have discovered that Waterfall methods refuse to die:
... in a survey of almost 200 practitioners, accounting for several thousands of projects over the past five years, the dominant process model reported was the Waterfall, with more than a third claiming its use.
Indeed, perhaps the ultimate tribute to the sheer persistence of the Waterfall approach in everyday development practice is the fact that the agile development community recently promoted the Waterfall 2006 Conference. Even if you couldn't attend, I recommend reviewing the agenda and the session descriptions carefully, just to see what you missed. I don't know if or when more documentation will be published, but I'm sure it will be worth waiting for.

NOTE: All posts in this blog have been migrated to Web Performance Matters.
All updated and new content since 1/1/2007 is there. Please update your bookmarks.

Monday, April 10, 2006

Managing Rich Internet Applications [7]

This is the seventh post in a series devoted to the challenges of Service Level Management (SLM) for Rich Internet Applications (RIAs). In these applications, some processing is transferred to the Web client while some remains on the application server. Previous posts introduced the subject and the SLM topics I plan to address, reviewed RIA technologies, introduced The RIA Behavior Model, and introduced and discussed RIA measurement challenges.

RIA Usability and the Site Development Process

Having discussed the measurement challenges posed by RIAs, I intend next to consider the demands that RIA development may make of SLM processes that have been designed and fine-tuned to manage traditional Web applications. I covered some of this ground in a Webinar on How to Overcome the Challenges of Rich Internet Applications. So in this post I will lay out the general framework of that material, using the illustrative figures I created for the Webinar.

Typical customer's experience of usability: availability, responsiveness, clarity, and utility. In previous posts I have introduced and discussed a simple four-part framework for thinking about Web Site Usability. I divided usability into four dimensions, each of which is essential to the ultimate success of any site -- Availability, Responsiveness, Clarity, and Utility.

The graphic presents the four essential qualities in the order of their significance, at least for all first-time visitors to a site.

Interestingly, companies developing Web sites or eBusiness applications tend to approach these four aspects in exactly the reverse order, as shown in the next figure.

Typical usability concerns during site development: utility, clarity, responsiveness, and availability A business goal leads to a design process, which in turn results in an application being built and then rolled out into production. And at each point along the way, people do their best to make the outcome a success. But is that enough?

Well, if you take this approach you may get lucky. But to be safe you really have to take a more systematic approach to Service Level Management, like ITSO.

[On this subject, it is hard for me to be brief, because 10 years ago I actually wrote a 750-page book about it. But here goes!] I have always believed that you cannot separate issues of software performance from the software development life cycle (SDLC). The best way to ensure acceptable performance is to follow the discipline of Software Perfrmance Engineering -- to build in the desired level of performance, just as a mechanical engineer would. The next figure attempts to sum up this idea.

Building usability into a site throughought the software development life cycle. I think everyone can agree that there is an application development life cycle – applications have to be designed, developed, tested, and deployed. People may argue about the details, but for the purposes of this discussion we can set aside those religious debates about methodologies. All I care about here is that each stage of your development process -– whatever it is -- must include a deliberate focus on performance (or SLM), alongside other aspects of site usability.

If you want an application to achieve certain levels of service, don’t expect that to just happen on its own. You have to agree on your objectives, then design, develop, and test your application with those objectives firmly in mind, and measure and manage the application to make sure you are actually achieving your objectives. Of course, there’s nothing particularly radical or new about this idea, but the added complexity of RIA’s increases the risk of failure if we don’t actually follow these well-established best practices.

The RIA Development Process
If you want to implement a really usable Rich Internet Application, you’re probably going to need to beef up your site development processes to get everyone on the same page. That's because up to now the Web Usability (with a capital 'U') profession has concentrated on the dimension I call Clarity.

Their exclusive focus on Web page design and Information Architecture was possible only because the traditional structure of a Web applications was so constrained by the limitations of the Web browser technology they had at their disposal. When all Web applications implemented the same simple thin-client model, they did not have to worry too much about application complexity.

But as we evolve to building RIAs with a separate client-side engine, the site development process must deal with the kinds of complex issues that arise during the design of distributed applications. In the past, Web designers have not had to deal with anything as technical as this. They certainly can’t buy a book on 'Web Usability' and read about these kinds of issues.

Confirming this perspective, I recently heard Scott Dietzen, President and CTO of Zimbra speaking about Ajax at an MIT/Stanford VLAB meeting. To illustrate his statements that 'Ajax is still hard' and 'You can't crank out a good Ajax application quickly' he revealed that Zimbra has had to interview 40 JavaScript developers for every one they have hired. This is telling evidence of the difference between traditional Web applications and RIAs.

The politics of application development. And you really do have to work hard to get everyone on the same page, because typically the people in the various participating departments usually don’t have a clear picture of just how much it takes to build a successful Web application.

As illustrated here, they naturally focus first on their own problems and challenges. The graphic is meant to be a bit tongue in cheek, but it does reflect the political realities of application development.

Several groups contribute to the success of any site, and each group thinks that their contribution is the most important! Apart maybe from those who work in IT, who tend to complain that they could deliver much better service levels if only the developers would hand them more robust and stable applications to manage.

The four dimensions of usability are equally essential.These attitudes are not just the result of people having an inflated sense of their own importance. Most people honestly don’t understand just how much work the other players have to do.

This is already true today, and with the added compexity introduced by Rich Internet Applications everyone will have even more to think about. This is likely to increase their isolation from the other participants, unless the development process requires close cooperation.

So the first lessons your development processes must drive home are that all participants play an equally vital role in delivering a usable application, because all four dimensions of usability are equally vital to the success of the application.

The Importance of Being Agile
Building successful RIAs will also require more communication. We’ve been talking about the importance of SLM within the life cycle. But the problem with describing the software life cycle using a list activities like the one in the third illustration above (introducing the development life cycle) is that such lists tend to imply a step-by-step process –- a waterfall methodology –- in which we must complete one activity before moving on to the next. That approach to the development process is certainly not going to be an effective way to develop Rich Internet Applications.

The RIA Behavior Reference Model Previously I introduced the RIA Behavior Model shown here. Consider in particular the grey boxes along the top, representing the application's design and usage environment, or context. As I wrote at the time:
A user's satisfaction with any application depends on ... how well the application design matches their needs at the time, their way of thinking, and their behavior when they are using it.

Their experience of response time depends on the combined behaviors of the client and server components of the application, which in turn depend on the application design, the underlying server infrastructure design, and of course the user's Internet connection speed. The most effective RIA will be one whose creators took into account these factors at each stage of its development life cycle, and who created the necessary management processes to ensure its success when in production.
Now imagine trying to focus on any one of the four aspects of usability without paying attention to the others. It can't be done. Application utility is tied to user behavior, which is driven by the clarity of the site, the design of the client-side engine, and the responsiveness of interactions between the client engine and the server components. And the design and implementation of those components will ultimately also determine application availability.

Keeping all four dimensions of usability in focus throughout the life cycle. Since the four dimensions of usability are so intertwined, I conclude that to ensure a successful outcome, we must adopt a development process that keeps all four usability goals in focus, all the way through the life cycle. This approach is called agile software development.

Agile methods use an iterative approach to design, development and testing that keeps all the different participants ('stakeholders') involved -- marketing or business owners, Web designers, application developers, and the IT staff who understand what it takes to manage a site in production. They all have to communicate and share their different areas of expertise throughout the process.

An example of a customer-centered design methodology In the Web design literature, methods similar to this have sometimes been referred to as customer-centered design. For example, that terminology is used in The Design of Sites by Doug van Duyne et al (see Chapter 1). However, Customer-Centered Design: A New Approach To Web Usability by Kreta Chandler and Karen Hyatt, while interesting (see Chapter 1), does not have much to say about the development process.

My graphic here is based on Chapter 5 of 'The Design of Sites', entitled 'Processes for Developing Customer-Centered Sites'. That book, having been published in 2003, is not about RIAs. Nor does it mention agile development per se, which is hardly surprising considering that the agile manifesto was crafted during the time when van Duyne et al were writing their manuscript.

However, it does suggest the kind of iterative approach to the development process that I believe is essential when developing RIAs. Chapter 5 concludes:
The principles and techniques of customer-centered design and iterative prototyping are embedded in every stage. Many firms have similar processes, though the stages and deliverables might have slightly different names.
Another book I have recommended previously, Usability for the Web by Tom Brinck, Darren Gergle, and Scott D. Wood, is structured around the major stages of an iterative development process. In Chapter 1 they write:
At each stage we want to cycle between refining our design and evaluating our latest refinement, iterating until we've achieved a level of usability that we're satisfied with before continuing to the next stage. Evaluation at each stage allows us to incorporate user and client feedback loops to optimize the design.

At each evaluation, we determine whether our design is adequate for continuing on. We do this by establishing benchmarks, or target usability goals.
These ideas did not emerge for the first time with the advent of the Rich Internet Application -- they are merely descriptions of good development practices. But the added complexity of the RIA model makes it essential that we actually put these kinds of methods into practice.