Thoughts on software estimation
1. Why do we estimate?
Estimations are part of our everyday life. We estimate how long the bus ride to work will be so that we know what time we should wake up. Drivers estimate how big a spot by the curb is to decide if they can park there or not. Engineers estimate how much time they need to get a building done so that they can charge the clients, pay the builders, and so on.
So, looking at these examples, I’d say that we estimate as a means of predicting something that usually can be measured: time, distance, size, etc, without having to actually measure it. We predict because measuring it may not be worth it, or because if we measure it, once we are done, this knowledge isn’t useful anymore.
With this prediction in hand we are able to make decisions. So I think that we can say that we estimate stuff to plan our actions.
2. Estimating projects
Let’s take the engineer as an example, I am not an engineer, but since my father is a builder, I think I can say some things about it. So the engineer has to estimate a building project, probably the differences between a project and another will eventually boil down to the material, the size, the number of builders that will be working, and a few more variables that are likely to be easily quantified. Once the engineer has all the information he needs, it’s just a matter of calculations. There aren’t many different ways of building a wall or a pillar after all. Of course, it is an estimation, so it may still prove itself invalid, that’s why it’s called estimation and not vision-from-my-crystal-ball.
Now, in software development we also need to estimate how long it will take, how many developers/QAs we will need, and so on, but the tricky thing is: how do we measure software? We don’t have materials, area, size. What units are going to be used as input for our calculations to come up with a reliable estimation?
Well, there aren’t any. Software development, different to classical engineering, isn’t measurable, because it’s an intellectual and creative type of work. Writing software for a bank is not the same thing as writing a mobile phone game. While we work in a development project we learn about the client’s domain, their needs, their specificities. And each client has their own details, even if they belong in the same type of industry. This makes all development projects a learning project. If we are learning something, we don’t really have the knowledge before it is done, so our estimations won’t be very accurate.
Not to mention differences of technology, the knowledge of the team members, how to deal with the client people to gather requirements and approve a completed functionality.
If you ever hear anyone saying that software development is an exact science, tell them: “Lies!”. It’s a lot about learning, finding different solutions for different problems and *a lot* of dealing with people, not so similar to the classical build-my-house project.
3. So what do we do?
Well, that’s a good question, since we can’t really say “we won’t estimate this software project”. We still need to plan it, and as we agreed estimations are needed for planning. So, where I come from we don’t estimate how big a software is, nor how long it’s going to take us to write it. We estimate how complex it seems to be, and the most important thing is: this estimations are relative, not absolute. We split the work into “stories“, an independent and small piece of work and assign “story points” to each story, a completely abstract unit of measurement.
If I tell you that I will need 4 hours to wash your car, this is an absolute estimation, since 4 hours is a fixed amount of something that we all know how to measure and have a common understanding of (hours). Now if we agree that a given piece of functionality for your software is 2 story points, it’s relative because it means that it is twice as complex as it is to write another piece of functionality that is 1 story point. But a “story point’ doesn’t really mean anything.
It’s true that there is a statistical co-relation between story points and time, as we can see on the chart below, but this co-relation of how much time in average a story point is worth varies quite a lot depending on the team, the project, the domain, technology and so on. The relativity between the points is still valid though.

How story points relate with one another when converting them to time units. Taken from Story Points explained.
4. Estimating software
So now that we can measure the effort to write software using its complexity in story points, we can start estimating our work. As we already agreed, development is a lot about learning, so we can infer that the more we work on a project, with the same team and environment, the more accurate our estimations will be, since we will know more about such project’s details. That’s why we ideally avoid estimating a whole project at once in the beginning, it’s better to estimate it in parts. For instance, estimating a bucket of stories for each planned release or each planned iteration.
After a few iterations we can get a grasp of an average number of story points that team can complete in a given amount of time. It’s important noticing that any change in any of these variables: team, project and environment may and will affect this co-relation. Once we have this average number we can start predicting how much time it will take us to complete a big set of stories.
Now, that sounds very good in theory, but in real life we usually need to tell our clients an estimation before we actually start working, depending on the contract and the relationship with the client, so… what do we do? This has got to be the one billion dollars question of software development lately. And the more I talk to people about it, the more it seems like there’s no satisfying answer.
5. Contracts
When the client is known and there is already a strong relationship between the parts it is easier to get a flexible contract, usually in a time-and-materials fashion, allowing us to adapt the complexity x time co-relation as the project advances and negotiate deadlines x scope x team variables to get whatever the client needs the most as soon as we can deliver. This really requires mutual trust and collaboration, which agile is all about. But the world is not 100% agile, as humans are not 100% trustworthy, so from what I have experienced these contracts are not the most common out there, specially when we are trying to get a new client to partner up with.
On the other side of the rope lies the least flexible type of contracts: fixed-price and scope contracts. The client tells you: here’s what I need, you tell them: I need X months to get that done, and it will cost you Y money units. Needless to say there’s a big risk involved in this type of contract. If the estimation is too low either you may need to work over-hours to get the work done, or the deadline won’t be met. In the worst cases, both may happen. If the estimation is too high, the client may prefer a cheaper potential partner and leave you. In the case they accept your terms, there will probably be a big waste of money from the client’s part, and time from both your sides (see the Parkinson’s Law). Not to mention requirement changes that, regardless of what the clients say, will come up during the development.
Most of the other types of contracts I have seen lie in between these two types or are a mix of them. Some examples I have seen are offering a couple of iterations to develop a prototype for the potential client, for free. After this prototype is ready, if the client likes what they see, the team will have a much better knowledge to work on more reliable estimations for a fixed-price contract. Another option could be a contract with a fixed deadline but variable scope, where the team compromises to deliver at least X story points. Or fixed scope but variable deadline, depending on what’s more important for that client.
6. Managing estimations
That said, I have had many discussions with colleagues about how to manage existing estimations, mostly in regards of whether we should re-estimate stories or not.
This may become a rather hot debate, but my opinion is that: we should try to avoid re-estimating stories, unless we’re really far off.
I really like Mike Cohn’s take on the subject, I don’t think I can explain it as well as him, so just take a look at it!
The basic idea is that we have knowledge-before-the-fact and knowledge-after-the-fact, and we shouldn’t mix them on our backlog, since we will need a normalized set of data to plan our future work on.
The problem arises when we use estimations not only for planning, but also to charge the clients due to the contract type. In this case re-estimating stories or not may not be an option. If the estimations are not tied with the project costs, informing the client that a given story will take longer than planned may suffice, in this case, since the development is in progress, a timed-estimation may even be accurate enough and more useful.
7. Conclusion
In my opinion, software estimation techniques are quite fair nowadays, the problem is not how we estimate software, it’s how we charge our clients.
Estimations are called estimations for a reason, they are not supposed to be the truth written in stone, and contracts based on that are quite risky.
I have the impression that once we all build a common understanding that software development is not as a classical engineering type of project many things will become simpler, and we will stop feeling that we are working in the software-estimation industry instead of in the software-development one (at least I feel like that at times).
The engineering part of our work is done by the compilers and interpreters, not by the developers.
Testing events on jQuery objects with Jasmine
Recently we had a piece of JavaScript code that looked roughly like this:
myApp.buttonBinder = {
bind: function(button) {
if (myApp.shouldChangeButtonAction()) {
button.unbind("click").click(function() {
button.closest("form").submit();
});
}
}
}
So we wanted to test this using Jasmine.
Our main goal was to test that when the button was clicked the form that contains it was being submitted.
It would be cool if we could use Jasmine’s spies:
describe("myApp.buttonBinder", function() {
it("should bind form submit to button", function() {
var form = $("<form/>");
var button = $("<input/>");
form.append(button);
spyOn(form, 'submit');
myApp.buttonBinder.bind(button);
button.click();
expect(form.submit).toHaveBeenCalled();
});
});
But unfortunately this does not work. I didn’t look too much into it, but I suspect it is due to the fact that when the actual code runs, the jQuery ‘closest’ selector creates a new form object that represents the same DOM element. But as it is a different object the spy can’t recognize that the function submit has been called.
One idea is to instead add a listener to the form’s submit event and check if this listener has been called:
describe("myApp.buttonBinder", function() {
it("should bind form submit to button", function() {
var form = $("<form/>");
var button = $("<input/>");
form.append(button);
var formHasBeenSubmitted = false;
form.submit(function() {
formHasBeenSubmitted = true;
});
myApp.buttonBinder.bind(button);
button.click();
expect(formHasBeenSubmitted).toBeTruthy();
});
});
And voilá! This works!
But it looks terrible, doesn’t it?
Good thing Jasmine lets us extend itself, so we can create a new spy function and a new custom matchers:
// SpecHelper.js
var jasmineExtensions = {
jQuerySpies: {},
spyOnEvent: function(element, eventName) {
var control = {
triggered: false
};
element.bind(eventName, function() {
control.triggered = true;
});
jasmineExtensions.jQuerySpies[element[eventName]] = control;
};
};
var spyOnEvent = jasmineExtensions.spyOnEvent;
beforeEach(function() {
this.addMatchers({
toHaveBeenTriggered: function() {
var control = jasmineExtensions.jQuerySpies[this.actual];
return control.triggered;
}
});
});
And now our test looks like this:
describe("myApp.buttonBinder", function() {
it("should bind form submit to button", function() {
var form = $("<form/>");
var button = $("<input/>");
form.append(button);
spyOnEvent(form, 'submit');
myApp.buttonBinder.bind(button);
button.click();
expect(form.submit).toHaveBeenTriggered();
});
});
Much better \o/
Go learn JavaScript!

This post comes late, as I have realized this late myself.
But it is not late enough to be useless, because most developers out there still haven’t learned JavaScript.
If you work with development of some sort, big chances are you work with web development.
If you work with web development, regardless of the technology stack – be it Java, .NET, Ruby, Python, Perl or Brainfuck – your application runs on a browser, and all browsers run JavaScript, so you can’t escape from it. *
That said, once you have learned JavaScript, you will find out that programming in JavaScript is actually fun!
I have gone through this myself as I have seen colleagues going through this too.
Not only you will find out it is fun, you will see how JavaScript is a powerful language that has lots of good things that you will start to wish other languages also had.
Most important of all: your JavaScript code will start to look good.
And once all developers in your team have learned that learning JavaScript is not only important, but necessary, your project’s JavaScript codebase will stop looking horrendous as it does nowadays. It will look good, modularized and testable. And you won’t ever again go “Oh crap, I have to touch JavaScript in this story…”.
Wait, did I say testable? Yes, I did! You can actually TDD your JavaScript code as well as you can TDD your <favorite language> code.
For that I recommend Jasmine, have been using it in our project, love it.
You can even combine Jasmine with Rhino or WebDriver and add your JavaScript tests to your Continuous Integration pipeline. (Your project has a CI server, right?!)
And you know what? Learning JavaScript is EASY!
I believe most developers familiar with any OO language wouldn’t need more than a couple of days to start writing more than decent JavaScript code.
There’s plenty of good websites and books out there for you to learn it, so go on and have fun!
* Ok, actually, you can escape from writing JavaScript.
You could go with GWT for instance. And I remember there were other frameworks that let you develop the whole fancy UI on Java on the server side, sending only few instructions to the client – I can’t recall any names right now.
The thing is: is it worth it?
I worked with GWT for a considerable time in 2009 and, now that I have had more JavaScript experience, I definitely wouldn’t go back to GWT. It just seems like a lot more work to do, not to mention the messy HTML and CSSs it generates.
If you’d like to have your JavaScript compiled from something else, take a look at CoffeeScript
Step-by-step selenium tests with page objects, dsl and fun!
Note: this is a long post!
Not long ago I wrote about functional tests and the page objects pattern in Aqris’ blog. Back then we at Aqris got all very excited about page objects as they were the solution we were looking for to solve our problems on maintaining our functional test code base, which by that time was based on a set of messy helpers that nobody really understood completely.
Before page objects, whenever a developer in our team had to write a test that had to perform an action no other test already performed, he or she would go through that bunch of helpers trying to figure out which one was the helper that should perform such an action. The result of this approach was that the team couldn’t get to a full agreement on what was each helper’s responsibilities. Everybody agreed that the code was not good, but each person had their point of view on why.
We first learned about the pattern here, when reading about WebDriver (now Selenium 2). Page objects came as the solution to separate the different actions our helpers contained in an extremely simple and even obvious way that nobody in our team had previously thought: simply creating a specialized helper for each page of the application.
It is in fact so simple that I still wonder how come we didn’t think of that before… I think that we were too busy trying to figure out how to deal with the helpers we had, and we were too used to have them that way. I guess that’s because the previous project we had worked on (and the first one we had a strong movement towards automated tests with Selenium) was a web app based on only one single page with lots of GWT-based ajax.
Anyway, excuses aside, we started using page objects and it was great! But then other doubts started to come up: how to deal with parts of a page that are common to many pages – for instance a side navigation bar? How to make our tests more readable? Should our page objects use selenium directly? If yes, how to resolve the selenium dependency? Can the page objects just encapsulate the locators for the html elements instead? Should page objects be responsible for the tests assertions too, depending on xUnit’s API, or should they just provide verification methods that would be used by our tests’ code itself?
I think that these are questions that may or may not have a straight correct answer, but here I will write a bit of what worked well for us or for me later on when dealing with that.
To do that I think we can write a test for an imagined scenario.
Let’s try that!
The problem
Let’s say that we have a test case to test the following hypothetical scenario:
We have a hypothetical book store application.
Every page in the application has a navigation bar on the side.
An user goes to our application home page and, by clicking on a link on the navigation bar, she goes to a page to search for books.
On the search books page she fills in a search form, entering “Tolkien” in the author field and “Rings” in the title field, and submits the form.
She is then redirected to a search result page that contains a list of books along with the same search form already filled in with the same search data she had entered – in this case, “Tolkien” in the author field and “Rings” in the title field.
We want to assure that, given our test data, the search result contains the book ‘The Return Of The King’.
We also want to assure that the search form in the result page still has the data she had previously entered.
The code solution after the jump
How to switch off Dell XPS 1340′s discrete video card on Linux
Finally, after months, the discrete video card of my Dell Studio XPS 1340 is switched off on Linux.
The story…
This laptop comes with two video cards and what nvidia calls Hybrid SLI.
The idea is very nice : one video card is integrated to the motherboard and is always switched on.
The other one is a discrete card and is manually switched on by the user when he/she wants more graphical processing power, consuming more power. This sounds interesting for laptop owners, who may want to save the battery as much as possible.
When the discrete card is on, both cards work together combined to provide a more powerful graphical processing device.
Even tough the idea is nice, the implementation is not, and nvidia even gave up moving on with the technology. If I am not mistaken, I read somewhere that they claim the driver implementation to control the devices together is very complicated.
The drivers for Windows Vista and Windows 7 work quite well, and is maintained by the laptop vendors, in this case, Dell.
Now if you use Linux…:
nvidia provides their proprietary driver for Linux, which is very nice, but allows us to use only the integrated card.
At first it was ok for me, as I didn’t have the need to use the power of both cards together on Linux anyway. The problem is: the Linux driver does not switch the discrete card off. Yeap, that’s right, you can’t use the discrete card, but it is always on consuming power. Ironic, uh?! The result is: on Linux my laptop always runs hotter and the battery lasts shorter than on Windows.
I researched for a long time when I bought the laptop, but I couldn’t find a way to get the discrete card off.
One good piece of news is that the project nouveau, an open source driver for nvidia cards, plans to add full support to switching these cards on/off at will. The driver is still under heavy development though… and many features are not yet implemented.
So just a few days I received an update from the sites I have been following related to the subject.
avilella has been running a great blog about switchable graphics on Linux, and quickly updating it on every new details that comes up. The address to his blog is: http://linux-hybrid-graphics.blogspot.com/
There is also a bug report on Launchpad regarding the same problem: https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/312756
On this bug report page they are collecting information about all different laptops with switchable cards, so that they can work on a solution for everyone.
But just yesterday a member from Launchpad named drphd found an ACPI method that can be called on the Dell XPS 1340 to disable the graphic card.
I just made a small modification on the module that avilella posted here, making it specific for the Dell XPS 1340, by using the method indicated by drphd. And, thanks to these guys, we can now switch the discrete card off.
The solution
So, to use it, just download these two files:
Before compiling the module, run: lspci -v
You should see the information for both cards, including the IRQ and the kernel modules related to them.
Now place those two files inside the same folder, cd to this folder and run:
make sudo cp xps_nv.ko /lib/modules/`uname -r`/kernel/ sudo depmod sudo modprobe xps_nv
If you run lspci -v again, you should see the detailed information only for the integrated card. On my machine the output after the module is loaded is:
02:00.0 VGA compatible controller: nVidia Corporation G98 [GeForce 9200M GS] (rev ff) (prog-if ff) !!! Unknown header type 7f 03:00.0 VGA compatible controller: nVidia Corporation C79 [GeForce 9400M G] (rev b1) Subsystem: Dell Device 0271 Flags: bus master, fast devsel, latency 0, IRQ 23 Memory at aa000000 (32-bit, non-prefetchable) [size=16M] Memory at b0000000 (64-bit, prefetchable) [size=256M] Memory at cc000000 (64-bit, prefetchable) [size=32M] I/O ports at 5000 [size=128] [virtual] Expansion ROM at c0000000 [disabled] [size=128K] Capabilities: Kernel driver in use: nvidia Kernel modules: nvidia-current, nvidiafb, nouveau
To make sure that the module is loaded every time you boot your laptop, edit the file /etc/modules and add, in the end, a new line with the text:
xps_nv
As you see, I have the Dell XPS 1340 with a GeForce 9400M G and a GeForce 9200M GS.
But I think that the same solution should also work for people who have the combination GeForce 9400M G + GeForce 210M.
After the module is loaded the laptop runs a bit cooler, it uses around 4W less power and the battery is estimated to last around 30-50 minutes longer.
Remember that every time you install a new kernel you will have to re-compile and re-install the module.
Cheers!
Vim for the win :)
I have been using Vim a lot in the last few weeks, to edit CSS and HTML files. It might seem a bit awkward at first but once you get used to it, it becomes great!
What helps a lot too is to configure Vim properly to make it perfect for use.
Vim and Vi configurations are done by setting variables using :set or by editing the file .vimrc in your home folder.
I will share here my Vim configurations and some of the commands I use more often. It also works as a Vim cheat sheet for my own future reference.
So, my ~/.vimirc looks like this:
set tabstop=2 expandtab autoindent smartindent shiftwidth=2 number
Here’s what each of them does
| Configuration | Effect |
|---|---|
| tabstop=N | Sets the tab size to N spaces. The default is 4. |
| expandtab | Tabs are expanded, when you press tab, N characters will be inserted instead of a tab character (where N is the amount of spaces set for tabstop). |
| autoindent | Will keep the same indentation when you press enter in the end of a line. |
| smartindent | Vim will try to automatically detect indentations. For instance, if you go to a new line and enter a ‘}’, Vim will go back one indentation level. |
| shiftwidth=N | The number of spaces used for one indentation level. |
| number | Shows lines numbers. |
And here are some of the commands I use more often:
| Command | What it does.. |
|---|---|
| :N | goes to line N |
| /foo | searches for ‘foo’ |
| :%s/foo/bar/g | replaces all occurrences of ‘foo’ with ‘bar’ in the current file |
| :s/foo/bar/g | Same as above, but replaces only on the current line |
| :s/foo/bar/gc | Same as above, but prompts for confirmation before replacing each occurrence of ‘foo’. Can also be used with ‘%’ to replace all occurrences in the file |
| Shif + G | goes to the end of the file |
| v | enter select mode |
| << | moves the current line one indentation level backwards; |
| >> | moves the current line one indentation level forward; |
| yy | copies current line to the buffer |
| dd | removes the current line out and place it on the buffer |
| p | pastes the text from the buffer on the next line |
Also remember that many of these commands may be used with a different number of lines.
For instance, pressing 1, 0, d, d will delete he next 10 lines.
Any other cool commands for Vim? Let me know on the comments!
How to center a floating HTML div with variable width
Hi! I know I have been away from the blog for a long time, but I decided to wipe off a little of dust and write some small things that I have been doing here.
Recently I have been working and learning lots of new and cool things, some of them are simple, some are not so trivial, but many of them could be quite useful for a bunch of people out of there, including myself! I mean, I decided to restart writing small tutorials on some simple things that I usually do, like the one I wrote about how to install the new JDK release candidate on Linux.
Ever since I wrote it, many times I had to come back here to recheck one or another detail of some command, when I wanted to install a version of JDK that was not available on the Ubuntu repositories.
So, today I will write down how to center a floating div with variable width…. A what? Portuguese English please!
Nowadays it is very common to see on websites a small notification on the top of the screen, like those:
I first saw these things on Google applications like GMail, but they are very nice anyways, because they avoid the use of (grr!) pop-ups (grr!) when there’s the need to notify the user about something. That’s probably why they are becoming each time more popular.
Anyway, this is basically a div or a span, centered on the screen or whatever other container contains it.
Usually to center something it is enough to use
margin: 0 auto;
But in this case we don’t know how wide the div should be, as it depends on the text it will show, which is dynamically provided by some programming language.
So my notification div class does not have a ‘width’ attribute and is displayed as an inline element:
.notification {
display: inline;
}
In this case setting the margin to auto won’t work, so what to do?
I wanted to center my notification div in relation to the screen, so I created two divs:
<div class="container"> <div class="notification"> Here goes my notification message </div> </div>
And my CSS:
.container {
position: absolute;
top: 0px;
width: 100%;
text-align: center;
}
.notification {
display: inline;
}
Basically we insert the notification div inside a container that occupies the whole area in which the div is to be centered, and set text-align: center.
I know it is very simple but it is not always obvious
Cowboy Bebop Original Soundtrack
Era uma vez um desenho japonês em que a história se passava no futuro e contava a história de caçadores de recompensa a bordo de uma nave chamada Bebop.
Pra quem não sabe, Bebop é uma subdivisão do Jazz, e essa é só a primeira das referências musicais presente no anime.
Misturando batalhas espaciais com artes marciais e faroeste, o desenho trás uma trilha sonora de dar inveja a qualquer trilogia famosa de Hollywood, com forte influência de blues, jazz e rock’n roll.
A composicão da trilha sonora foi liderada por Yoko Kanno, uma japonesinha batuta conhecida por suas criacões musicais para games, animes e filmes. Ela reuniu alguns músicos e formaram uma banda para a criação da trilha-sonora. Batizaram a banda de The Seatbelt (Os cintos-de-segurança), pois brincavam que deveriam usar cintos-de-segurança para permanecerem seguros durante as sessões de jam.
A banda não tinha um cantor principal, mas contaram com a participação de vocalistas como Steve Conte, Mai Yamane, Gabriela Robin (há rumores de que esta seja na verdade um pseudônimo da próprio Yoko Kanno) e outros para as músicas não-instrumentais.
A banda se reuniu mais uma vez em 2004 para criar a trilha-sonora do segundo game baseado em Cowboy Bebop.
Clique em ‘Leia o resto deste post’ para poder ouvir algumas músicas da trilha.


