February 2008


On LinkedIn someone asked this question:

How do you deal with the project requesters that are asking you for a project estimate before you get all your questions answered? Would you just ignore them and loose the project or go ahead and earn a client?

This is indeed a problem all of us in the software development business face. The question is indeed what to do in such a situation and it boils down to following three choices a service provider has:

  • rip the client off – add all the uncertainties, add the industry standard 25% and produce a bid – then do it as fast and cheap as possible and profit – that’s probably what _most_ companies do,
  • risk your money – to win the bid do all the above but not add 25% but rather subtract it, so that you’re cheapest thus winning the bid, then kick the project as fast out of the door as you can compromising on everything your client being ignorant in technology won’t be able to tell – namely quality (do spaghetti code, do it ugly, test only positive paths and forget unit testing etc.),
  • tell the truth. That is – the client he won’t get anything solid with what he has, just lies, assumptions etc. However, for whatever amount he can spend he can get the most important features he needs with solid quality. If his site would be a success he can add nice-haves later on. Ask the client to make a list of them, discuss them, tell him that in one short iteration one or two will be up & running. Be honest and cooperative. It’s not a guarantee of success, but well… this is what this option is all about.

Everyone who is approached by such a client makes this choice. The problem is that typically such clients don’t like the third option, so they fall for the people choosing the other two. The results we all known – poorly designed sites, unmaintainable code or – worst – lost time and money.

What we follow is of course the third option.

Another project that we have been working on is now available for preview. This time it is a simple tool for managing the Scrum process called “Banana Scrum”.

You can log in to the preview installation by following this link and using the name “admin” and password “test”. You can play with the application as much as you want – it works on a copy of the test database that is regularly refreshed, so you can move and delete and edit whatever you like.

This project was born out of our frustration with ScrumWorks. It was the application we have used for the most of last year, because it was the only free and decent Scrum software around when I went looking for it in January 2007. However, it had many serious limitations, exorbitant pricing for the “Pro” version which added basically access rights for user (not needed for small teams IMHO) and was done as a Java app – a design decision I couldn’t understand, since there is absolutely nothing in there that could not have been done with an interactive, AJAX web app.

That is exactly what we did – our little Banana is done fully in Ruby on Rails, works great with most browsers and supports interactive features like in-place editing, drag and drop or a nice, interactive burndown chart. As of now it is pretty useful and – as it supports multiple projects – we use it for our own work.

We hope to add more features soon and possibly some day make it available to the world. If you’d be interested in trying it already – drop me a line.

As for the name… well, there was a competition in the team and Tomek Paczkowski won it (and a bag of bananas) with this proposal.

Yesterday we have decided to publicly show “Sprinters Search” – a research project we did at Code Sprinters in the recent month. It is a meta-search engine that attempts to provide the user with a short definition of the search term followed by unaltered results of a regular, traditional web search.

This project is a result of an idea that came to me last year. It occurred to me that today people are frequently using search engines not to find a well-sorted list of pages on something they do know, but rather they want to learn what a word or a name or a phrase they picked up somewhere (in a conversation, on the Internet, on TV etc.) means, what that is. Said well sorted list of pages helps only partially in getting the definition people are after. An attempt to provide a very succinct and correct description as a result immediately would be much better. Such a result could be followed with a traditional page list if the engine’s guess was wrong or the user wants to research further.

I thought that with lots of structured information now available on the Internet building something like that should be quite possible. After all, when current search engines were invented they were designed to parse just general web pages with no structure to them at all. Now we have all kinds of data and content bases that provide good quality information in a structured way. It seemed quite possible, so we gave it a try.

And here it is our fully working attempt at demonstrating that it is indeed possible. The aim was to provide – in most cases – a correct definition of the search term upfront, on the top of the page, possibly with an image, so that the user doesn’t have to scroll down or click through to get the definition he needs. I’d say for an early beta our meta-engine does pretty well – thanks in part to simple yet ingenious algorithms applied by Pawel Stradomski who designed that part of the code.

Of course, it is still just a research project. To make it robust and scalable resources we don’t have are be needed – much more computing power and fast storage + more time to fine-tune the algorithms. So for now we’ll leave it as it is – a good demonstration of our capabilities.