Polymorphic Rants

Javascript has become in the last years the language for rich web applications,  but still it rarely receives the level of attention it deserves.

Libraries such jQuery boost our productivity but the code we often end up writing tend  to be a big ball of mud, with an entangled mix of presentation logic, busines logic and server side interaction,  all incredibly hard to test and to maintain.

It’s time to move away from this approach and start writing better quality Javascript.

The very first step required to avoid Javascript spaghetti code is start thinking to Javascript as a first class language, and start dealing with it with the same mindset and approach we would use for any server side language.

With this new approach in the same way we identify roles and integration points  in server side code we want to start building abstractions in our Javascript codebase.

With the right abstractions in place we are defining clear boundaries between different parts of the system, and as a consequence our code is simpler, we promote reuse  and the DRY principle, and  we are finally enabling better testing.

Let’s look at any standard Web 2.0 Javascript code from this new perspective: now the DOM and HTTP are two clear integration points.

Our javascript code manipulates the DOM adding  nodes or changing existing nodes content in the same way any other language would interact with a database. Each call to a server over HTTP via Ajax is exactly the same of calling a web server from our server side code.

With these very two first abstractions in mind, we can start rewriting our code, isolating these interactions behind clearly defined objects.

Now the javascript code is not a ball of mud anymore, but a network of objects that collaborate. With these smaller objects  in place we can now favour interaction based tests, moving away from any dependency on the DOM and on the HTTP protocol.

The identified abstractions let me actually mock  and stub things out and test if the different tiers in my javascript code are exchanging the right messages. This separation of concerns keep the business logic nicely isolated from the user interface transformations, enabling also a cleaner state based testing for that specific part of the code (there are no more dependencies on the DOM).

Friday, 20th of November 2009, the 6th Italian Agile Day will be held in Bologna.

It’s a great opportunity to share experiences and practices, learn, discuss and meet other praticioners part of the  Agile community…and moreover it’s free

I’ll see you there !

The beginning of a project is always a hectic period where several things have to be put in place in order to be able to start the actual development from a solid position.

Interestingly enough, I see that what is important to have ready for ThoughtWorkers most of the time is not what has to be ready for other people.

Given that obviously every project is different and deserve specific attention, here is my list of things that has to be ready before the kick off of iteration 1.

Infrastructure

A repository, a Continuos Integration Environment with Cruise (or suitable alternatives) installed and working, a QA environment where we can deploy every successful build whenever we want, a basic build script (i.e. build/run tests/package). Pairing boxes, each one with exactly the same configuration.

Architecture

Just identify the core services/components, there’s no need to go into detail for each one at this time of the project. If we identify what is the main responsibility of a service is good enough for now, the details will be discovered later in the project. If we can easily identify the way services will communicate (web service ? message broker ?) good, if not through good OO principles we can abstract the low level mechanism and reduce the cost of change later, deferring the final decision to the point in the project where we have more understanding of the technological constraints.

Patterns

Pairing and frequent pair rotation will help in spreading the knowledge of the approach to solve specific problems and in maintaining consistency throughout the code base, so most of the time there is no need of defining a sort of “project dictionary” of valid patterns at day 1.
If we’re introducing new approaches to solve a specific problem, it’s important to highlight pros and cons of the approach so that people know what they are doing once pairing.

Most of the time these are probably enough to start Iteration 1.

All the other decisions can (and sometimes should…) be deferred to a later stage.

In a lot of companies  the productivity  of a QA is measured through the number of defects she raised: the  more defects she finds, the harder she works, therefore the better she is.

This approach has an interesting corollary:  if you have really good QAs you don’t have good developers. If your QAs are finding a lot of defects this means that your developers are quite poor and are regularly introducing defects in the code base.

This approach isn’t obviously team oriented: QA and Development are seen as two separate and independent entities that interact through a specific contract.

If we truly believe in collaboration the most important productivity metrics are not related to a specific role/set of skills but to the team capability of deliver quality software in time and in budget.

We need to ask ourselves why the defects are finding their way into the application deployed in the live environment (incomplete acceptance criteria ? not enough analysis or understanding of the domain ? gap in the test suite ?), and fix the issue as a team, not just using that number as the boundary between two streams of work.

Delivering software is a pretty complex activity that requires interaction between people with different skill sets.
One of the cornerstone of Agile Development is continuous improvement, and one of the tool often used to learn and improve  is the retrospective.

In a context where the collaboration is not effective, people tend to look for local optimization instead of seeing the big picture, and you have things such  the “QA retrospective”  or the  “Developer retrospective”.

In this scenario a “QA retrospective” (as the Dev’s one, or a BA’s one)  is probably more harmful than anything else; the specific issues that will be identified won’t address the whole activity of delivering software but will only be focused on that specific step (“we need x to do y”).

But what is the impact of that step in the overall process ?

How that step fits into the chain of event that will take a business idea to be delivered as a software artifact (hopefully in a timely and quality fashion ) ?

Don’t get me wrong: it’s definitively through specific improvements that you improve your overall process but if  don’t frame your changes in the big picture, it’s more likely that your changes will impact your process in the wrong direction and actually cause an additional waste.

Each attempt of optimization should therefore start from the clear analysis of what is wrong from a high level point of view and only then it’s time to shift our attention to the specific details of each step.

Walking in an office and just looking around for 10 minutes is enough to have a feelingof the level of communication in the environment.

When:

• co-located people communicate mainly via IMs, mails, or comments on online collaborative tools instead of face-to-face conversation
• a heavyweight tool is the preferred way for driving the work flow instead of using it only for backup and tracking
• on the whiteboard you can read the outcomes of the retrospective of 7 months before

There’s definitively something wrong.

What about your team ? How many of the above bullet points are you ticking off ?

Here on InfoQ some interesting thoughts around Seniority and Authority in an Agile team.

For the third year the European Summer School of Agile Programming(Essap) is a great opportunity to learn more about Agile Methodologies.

Here the website of the school: check it out.

For the last two weeks I’ve worked with EasyMock and coming from a JMock background it’s easy to make a comparison between the two libraries.

I have to say that I’m less than impressed by EasyMock: the whole concept of the two different states (recording and active) for the mock library looks unreasonable.

Let’s look on how we can create a mock with EasyMock:
MyInterface mock =EasyMock.mock(MyInterface.class);
//expectation
mock.myMethod();
//activation step
mock.replay();
//actual call to the mock
mock.myMethod();
//verification that the method has been called
mock.verify();

There’s also a more DSLish style of defining expectations, that I personally prefer (it differentiates clearly the definition of the expectation from the actual method call).

EasyMock.expects(mock.myMethod());

This style is the only one available when the expectation is more complex:

EasyMock.expects(mock.myMethod()).andReturn(true);

But what if I want to define that a certain method will be called on the stub, no matter how many times ?

I can either use a different way of creating the mock:
EasyMock.createNiceMock(MyInterface.class);

or using the DSL way:

EasyMock.expects(mock.myMethod()).anyTimes()

I think that having two ways of defining the same expectation pretty confusing, specially when you’re using the API for the first time.
What I’m looking for in a mock library is the possibility of defining the expectations in a concise but expressive way (DSL please…) and then inject the dependency in my main object. Period. Done.

JMock2 is pretty close, but I have to admit the the inner class notation with all those curly brackets around is not helping.

A fellow ThoughtWorker have just released Mockito: it looks like it’s taking the best from EasyMock and JMock and put in a single library..will it be true ? I’ll give it a try and I’ll let you know

I’m just back from the ThoughtWorks Immersion in our Pune office and one of the most interesting concept that came back to London with me is lo-fi.

Yes, lo-fi: nothing about planning, TDD, gummy bears and other fancy core agile things.

Just about being lo-fi.

This has actually been a core concept for me in the last years, but hearing it from the trainers has been a pleasure confirm.

What do I mean with “being lo-fi” ?

That concepts are trillions of time more important than the way we capture the them.

Write your stories on cards, play with them, move the cards around, rip them off if they are useless.

Design, architecture and layout of a UI can be fleshed out on a whiteboard and captured with a photo; big flip-charts are working lot better of mails and Word documents for defining agreement in the team.

All these lo-fi techniques help you focusing on the values of what you’re doing: if after a design meeting you roll out a lovely UML class diagram  you will be a bit reclutant to throw it in the bin if in the next meeting the team decides to take a different solution just because ittook you a decent amount of time for creating it with all the necessary details with Visio).

If you’re able to work on your ideas and not on the artifacts you will keep your process light and flexible as you need, able to quickly adapt to changes and decided improvements.

And if at the end of your process (but only at the end !!) you really need to formalize all the outcomes, do it…but keep in mind that from that point in advance you will be naturally less open to changements.