Recent Posts

Recent Comments

Top Commentators

Archives


« Microsoft does GWT | Main | Impressions from JAOO 2008 (2 ½) »

Impressions from JAOO 2008 (2)

By Jan Reher | October 2, 2008

By Jan Reher, Senior Developer, Systematic Software Engineering A/S. jan.reher@systematic.com.

Tuesday, September 30, 2008
Lars Bak: Google V8

V8 is the JavaScript engine (JSE) that runs inside Google chrome and executes the JavaScript that provides much of the dynamic contents of today’s web pages. The JSE is crucial for browser performance and responsiveness. Google felt that most JSEs were faulty, and so set out to create an improved one for chrome. Both to make users happier and to make us prefer Chrome, and also to show competitors that they have some catching up to do and entice them to improve.

The talk was technical, clear and inspiring. I think the main message I got was that, despite the current trend towards concurrency, the design principles for data structuring and algorithmics we learned in school still hold true. There is still a lot to be gained by applying computer science.

One of the reasons JavaScript is slow is that it has no real classes. Instead, any object is potentially a collection of properties, and when you write x.y, most JSEs will do a search through x’s properties, looking for y. This takes time. Traditional implementation of OO languages do this lookup simply by adding a statically computed offset to x’s address. This takes hardly no time at all. But since JavaScript does not have classes, you cannot do this static computation of offset. V8 amends this in a Self-like manner by creating classes for object on the fly. This entails a slight startup penalty but after that, member lookup becomes real fast. And the algorithm Lars showed us for doing this is quite simple.

Another performance gain comes from the fact that V8 has no bytecode layer. JavaScript is JIT-compiled directly into native code. This means that porting V8 to new platforms become a bit more difficult but since Windows is still 90% of the market, this is not really important. People sitting on other platforms will have to wait a bit.

A cool fact about V8 is that its JavaScript library is not implemented in the language V8 is written in (C++) but in JavaScript itself. Nice and clean solution. It makes the library immediately debuggable from V8’s JavaScript debugger, and we can load the library incrementally on demand.

User experience has a lot to do with performance. Yesterday, Ben Goodger showed us Google Chrome’s admirable user interface. This talk showed that the people at Google have been as diligent, skillfull, and caring when it came to implementing Chrome as they were when designing it.

Frank Buschmann: Architectural reviews

As is always the case with Frank Buschmann’s presentations, his message was immensely clear.

Why review architecture? In short: To get feedback. As the responsible architect, you need someone to help you find out what works and what needs to be improved. As you are on the project, you are not neutral. You have things a stake. So you need help from the outside.

Reviews are not (usually) about the person or persons responsible for the architecture. But if senior management requests an architecture review, it could be a sign that they have no confidence in you. So you should invite experts to perform the review yourself. Think of it as a safety net, and make architecture reviews part of your culture.

Some places where architecture reviews can help:

When to do architecture reviews? You can do it at many points in time. Many project events should trigger an architecture review, e.g. milestones, phase endings, when problems occur, or when you are envisioning the next major extension to the system.

How to do architecture reviews?

  1. Set the scope. You need to focus. Define a goal and 3-5 key areas that must be investigated. Set measures (these need not be objective but they must enable you to decide whether the architecture is good or bad in the key areas). Decide what sources to draw information from. One is talking to people who knows about the architecture.
  2. Collect data. Design documentation is nice, if it exists. But sometimes the code, demos, and test reports will tell you more about the real architecture, as opposed to the intended architecture. Interviews provide all other information. They tell you what people think about the architecture.
  3. Evaluate. Stick to the original goals and key areas. Produce a report (I forgot to ask whether it should be a written report or an oral one). It must contain concrete recommendations. But do not attempt to take control of the architecture. The architect is responsible for the architecture; as a reviewer, you are merely here to help. Do not intrude. Build a System of Trust [Coplien and Harrison] between the architect and the reviewer.
  4. Report. Focus on the key areas. Report good stuff, too, because there’s a message here: “This is good. We recommend you don’t change it”. Report bad stuff but briefly. Spend 2/3 of the report on presenting recommendations. And present the report to the architect and team before presenting it to upper management. This builds trust, too.

What techniques to use? These come in two groups: Quantitative and qualitative.

Quantitative techniques are nice because they provide hard, objective data. But data need to be interpreted by an expert before they have any value, i.e. can be used to make decisions on. And acquiring quantitative data can be expensive, especially if it involves simulations.

Qualitative techniques rely on the experience of experts. Thus, they can get stakeholders involved, and expose they concerns and gut feelings, which is very important. A great advantage of qualitative techniques is that they can be applied at a very early stage. A major disadvantage is that they rely on having access to experienced reviewers, and that good social skills are required.

There are several named and defined review techniques out there. It matters less that you follow a named technique than that your reviewers are skilled and experienced.

In conclusion, do not fear reviews. Think of it as an aid to improving the architecture. Your architecture.

The review approach can be applied to other subject areas. So if you are not an architect doing architecture, substitute with whatever you do, and invite experts to review it.

Chris Rupp: Requirements by Clairvoyance

So the customer doesn’t know what he wants? Well, it is not the customer’s responsibility to specify requirements that can be handed to the development team. It’s yours. Now what?

Chris’s talk mainly told us that requirements engineering is difficult (I knew that) and there is no simple method that will make it easy (I feared that). She also told us quite a bit about why it is difficult, and that was useful. The talk was inspiring and relevant.

There are three types of requirements. Some requirements the customer can tell you because it is part of his conscious knowledge about what he wants the solution to do for him. These requirements constitute the performance features, and customer satisfaction grows linearly with the solution’s compliance to them. Studies indicate that these comprise about 40% of the complete requirements (I don’t know if this is measured by head count or by development cost, or something else. I forgot to ask).

Then the customer has some unconscious knowledge about what he wants the solution to do for him. These are the “self-evident” requirements that are never stated. Trouble is, they are self-evident only for domain experts and you may not be one. These requirements form the basic features and the customer expects them to be there, though he may never notice them until he gets the final solution, and notice their absence, in which case his satisfaction will drop quicker than linearly with the number of basic features he discovers are missing. Chris gave an example: Nobody wants a mobile phone with the keyboard on one side and the screen on the other side but this is probably not stated explicitly anywhere.

Finally the customer has subconscious knowledge about what he wants the solution to do for him. This is where the solution can rise from good to great. Like unconscious knowledge, these requirements are never stated explicitly, except in vague terms like “we want a simple user interface”. These form the enthusiastic features and are about dreams and desires. Customer satisfaction rises dramatically the more enthusiastic features the solution contains. Apple seem to be good at mining our common subconsciousness. Other vendors less so.

Note that a given feature changes type over time, always downwards and sometimes very quickly. So yesterday’s enthusiastic feature (”oh look, I can make the text bold by clicking a button!”) is tomorrow’s basic feature (”what, I can’t do margin notes?”).

It’s all about communication. It’s about humans, words, and mental models.

I’ll inject some personal observations here: The agile response to these problems is to downplay the requirements specification, and deliver partial solutions as you go along. Using them as a vehicle, you can extract knowledge from the customer about what the customer wants. This doesn’t make requirements engineering easy but it does free you from having to shoehorn tacit knowledge into a negotiable text in a requirements specification. Depending on your project and customer, the agile approach may or may not be an option.

And sometimes, circumstances or sheer incompetence will force you to focus on the explicitly stated requirements, and deliver only the performance features, simply to get the solution out of the door. This probably won’t make the customer happy but at least you will be able to close the contract. End of personal observations.

Chris showed us a simply enormous table of named and defined requirements engineering techniques, and encouraged us study and learn most of them (wail). Because different situation call for the use of different techniques, and these have different strengths and weaknesses.

Then she presented one technique, drawn from the field of neuro-linguistic programming (NLP). Its basis is that any spoken or written representation of a person’s knowledge is probably incomplete and faulty. I’ll skip the theory, which I’m not able to present adequately anyway, and just focus on two pieces of advice that come out of applying NLP to requirements engineering. There are more; go read Chris’s work.

One is to focus on the verbs in specifications, and to think about them and ask about them. Ask why/what/when, etc. Do not aim for a complete specification, you won’t get it anyway, any way.

Also look for over and under-generalisations: “all”, “always”, “never”, “any” etc. They often hide important special cases. Also look for places where a generalisation is not there but perhaps should have been, as in “users can request reports”: All users? At any time? All kinds of reports?

Complex processes that people do not really understand tend to be distorted and converted into events, i.e. single words without clear definition. Examples are “backup” and “failover”. These can be hiding all sorts of nastiness. So look out for the nouns, too. Another example is “requirements engineering” itself: an ill-defined word for a complex process, if there ever was one.

Requirements engineering is about communication. And that is not easy. But given time, skill, and a cooperative spirit, we can sort it out.

Jim Coplien: Agile Architecture

As always, Jim’s presentation was fast and furious. A roller-coaster ride full of bumps, tight curves, and the sound of complex topics rushing by. Hang on, if you can! I’m going to need to watch the presentation again in slow motion.

Some highlights (or perhaps more appropriate: some points that I managed to grasp and hold on to):

Agile, OO, and patterns are at their foundations about the same thing: End-user perspective and engagement. They are about creating mental models that capture the user’s world.

Architecture, then, is the form—in the molding sense—into which we pour functionality. Lean architecture is about JIT delivery of functionality. Agile architecture is about supporting change, end-user interaction, and discovery.

In Christopher Alexander’s words, the architecture must support “what happens there”.

We need to think about objects, not about classes. Objects are the building, classes are just scaffolding.

The MVC pattern embodies the OO model through its direct manipulation model. The user reaches into the computer through the View to manipulate the Model. The Controller is there to orchestrate the proceedings, especially if there are multiple Views.

Domain knowledge (often tacit) are the foundations of architecture, not the requirements. The architecture is what the system is. The requirements determine what the system does. (Michael Jackson comes to mind here. No, not him. No, not that one either)

And then I fell of the track. Cope presented something he claimed to be a new architectural model called Data, Context, Interaction. It’s about dividing or describing your architecture in terms of three stereotypes: Methodless roles, methodfull roles, and classes. And then composing them into objects. Use cases appear (?) on the methodless roles. This sounds awfully cool but I think I need to study it some more before I get it.

Jim and friends have produces implementations of this in Smalltalk and C++, with Ruby and Python on the way. It seemed that C++ was the language most suited for expressing the idea, which is lucky for me, since I’m currently on a C++ project and this will make it easier for me to get acceptance for test-driving Jim’s ideas. There is nothing like trying new ideas out on real problems.

Jim reported that they had failed to produce an implementation in Java, and had had to conclude that it is because Java is a toy language. This remark got no cheers at all. A gentleman in the audience later pointed out that his group had done something similar, in Java, and that it worked nicely. And so the language wars roll on.

Anyway, Data, Context, Interaction has these benefits (Jim did not mention any liabilities, which is problematic):

This talk takes my prize as the most difficult and potentially most rewarding JAOO 2008 talk. Perhaps. I’m going to have to study Jim’s material. It will probably be worth it. It usually is.

Category: 2008 JAOO | Tags: , , , , , , | No Comments »

Comments