Buy Software Development: Agile vs Traditional

Software development is intellectual services.

Unless you only need little hands to code straight forward what you have precisely (very precisely) specified, you need at some point some intelligence, some expertise, and you'll choose a contractor not only because he is cheaper, but also because you will benefit from its expertise.

Say you are a buyer of a big company, and you have in mind a set of features. Maybe you have a specifications document (given by your technical team). Maybe you also have a rough idea of how it can be implemented, technically speaking.

Say that your goal is to provide your company with the best solution at the best price.

Now, let's compare two very different approaches:

1. Buy traditionally made software

In this approach, you have to specify precisely what you want. Then, you can easily ask several companies the price and the delay for implementing your software. And you can easily negotiate prices because all proposals will contain nearly the same commitment. And if you specify an architecture, you'll have similar solutions proposed.

That's the more comfortable position for you, the buyer. You buy intellectual services (software development) like you buy a product.

Then, the realization will start. And the contractor, if he is professional, will have to deliver you with the minimum software that fits with your specifications and its commitment. The same way you negotiated the price to minimize your expense, he will deliver the bear minimum he has to in order to maximize his revenue.

More than that, if for some reasons, your needs turn out to be a bit different than what you expected first (because it appears that you are not the expert in the field, or/and because your contractor has hidden some lack of your specifications, etc.) you'll have to ask your contractor for a amendment to the contract.
And because your contractor made a price very low on the first package in order to gain the contract and because he is a professional that needs to maximize its profit (like you), you will have to pay a lot for this amendment (and all upcoming ones). Especially if (it happens in most cases) you are stuck to this subcontractor -- because he developed too many things now to replace him with another company.

Obviously, it always happens. Because it is so hard to precisely define what you need. Even, often, what you need is different of what you first wanted (and sometimes also different from what you specified).

Meaning that if you wish to buy software this way, you'll have to engage technical experts first, to precisely define what you need, and then charge a standard IT company (little hands) to execute the exact plan at the lower price. And then, the question is still asked: how to buy expertise?

In the traditional way, the contractor is not exactly playing with you because its goal is not aligned on yours.


2. Buy agile made software

You have needs. And maybe rough ideas on what and how it can be realized. But you know you are not the expert, and you are confident your contractor will come up with a solution you would never have thought about, way better than what you expected first.

Meaning, you'll choose your contractor for its expertise, not for its ability to execute word by word a plan you have written.

A contractor comfortable with agile development methods will answer your RFI or RFP with:

• an architecture and technologies that fit well with your needs;
• an estimate of the work and the global cost of the project, without committing on it yet;
  
• development plan split into several iterations of the same size of 2 to 4 weeks (called prints in Scrum method), with maybe a first special iteration to study deeper your needs, and build up a mock up to validate the solution. Each iteration will end with a delivery you'll be able to use. And this delivery will be tested as it was a final product;
  
• the price for each iteration planned on the project and the price for extra iterations;
  
• the opportunity to stop the contract after each iteration and will offer you to pay each iteration one by one, once completed and accepted by you (the acceptance of the previous iteration being mandatory before starting a new one)

Here's how Scrum method used in my company looks like (features are broken down into a backlog who are managed with Jira):

Each week, you'll have a report on the estimated remaining time to achieve the product that fits your needs, the estimation of the implementation of each feature, and you'll be able to give feedbacks, change priorities of features to implement.
Each sprint, you'll be able to change the features to implement... that is to say to figure out that your needs are slightly different, and change the route of the project.

In one word: you are at the helm. You are part of the team. You are able to see with your eyes if the guys are really working hard or not. You can precisely follow the development and decide the direction to take. You can stop when you want or decide to continue. You will trust and be trusted in return.

In this way of contracting software development, the contractor is playing with you. He will show you everything he sees, and let you take the decisions.

Now, because you are the buyer, you are not very comfortable here, because you simply cannot negotiate the same way you would have done for a traditionally made software: if you lower the price, you will only get less iterations.

The only thing you can negotiate here is the price of each working days depending on the experience, the specialization and the reputation of your contractor.

Meaning that you have to:

• make the contractor talk and write about the solution he proposes in term of architecture and technologies, project organization and development process, so that you'll be able to get a good idea on his experience and skills
  
• interview people who have worked previously with the company (and preferably people who had same needs than you, people who are happy with the job they made and people who are less happy, and understand why)

3. Software services: expertise or simple outsourcing?

Depending on what you want to buy, expertise or little hands, choose how you buy, and to which company.

If you have experts at home (do you really have experts at home in all required fields?) maybe you can first spend a couple of weeks/months/years (depending on the project size) to produce extremely detailed specifications and buy man power (little hands) to standard IT companies, and build a project management/QA team to follow the outsourced team.

In all other cases, you may have to consider the "agile way" and benefit from an expert company which has built its reputation on its technical skills, its creativity, its availability to deliver in an agile manner.

What are you able to do for an iPhone?

You know it: I've one of the first generation of iPhones in my pocket, a colleague of mine at Joost brought me back from the US. Of course, it has been unlocked so that I'm able to use it without giving 50€ to Orange each month during 2 years (+ several hundreds of euros to buy the device), that is to say without giving an arm for it!



Coucou to friends who are still working on Joost!

s/skype/Skype/

I just discovered that my skype client (2.7.0.330 on Mac OS X) accepts Sed replacement commands ! And surprisingly enough, it doesn't work on Windows or Linux Skype clients (at least versions used by developers of my team). But on windows, the Ctrl-Z works, and allow you to re-edit your last post (and doesn't work on Mac...).

So, to sum up:

- Mac users are considered by Skype as Computer Geeks or Software Developers, and have to use the s/.../.../ syntax in order to edit their last post

- Windows users are considered by Skype as... windows users ;) and have to use the well known Ctrl-Z command to edit their last post using their mouse

- Linux users are considered by Skype as perfect people that don't need to edit their posts ;)

Don't vote

Today, my day started with this:



While watching the two first minutes, I was so excited by this idea: what kind of people would possibly understand from these two minutes that these actors are telling them to not vote?

Would it be possible that one can understand "don't vote", while others understand "vote"?

Would it be possible that this video (the 2 first minutes) encourage people who actually understand the sarcasm to vote while it discourage others?

Don't vote

Well, the rest the video is more explicit and more conventional... and of course is emphasized by the first 2 minutes.

A brilliant video made by brilliant people, definitely.

Happy US iPhone freed living in France

So, yes, I use my iPhone (1.1.2 Out_of_The_Box) with french operator Bouygtel, and VoIP with Free and FON wifi spots :)

Many thanks to Geir and Friday's hero: Geohot (I used this directly on 1.1.2 firmware)

Create your application for iPhone/Facebook/Android

Do you have to create an application for iPhone/Facebook/Android ?

If your target is the B2C market and you reckon on early-adopters and geek people to talk about your project and make Buzz all around, you MUST create one application on these platforms. Just because it is where you need to be visible.

And the argument saying for example that iPhone is like no people is using it regarding the market share is a wrong argument. These people (including me) do have an iPhone (maybe 50% of them do?), have a facebook account, do tweet, will run Android soon, and will post an article to their blog embedding your application if you make it possible.

-- ahem, I've no iPhone for now, and of course would like to (message, message) ;)

Ah, and of course, your application must be free, fun, even useless, but nice, and will not necessarily help you earn some money, but will higher your buzz-meter and expose you to scalability failures eventually - in that case I can help :)

Goojet launch

Goojet, a little French startup in which Anyware's team and friends of mine are involved, is launching today in beta.

Goojet aims to revolutionize the way you interact with Internet from your mobile phone.

All the best to Goojet!

Natural desire of rewriting software

The decision of rewriting the code of a significant part of a system is usually taken by an experienced developer, by itself, because "the code sucks". And usually without any real business consideration.

The consequences of such rewrites are often disasters, making the company loose time and money, and even worse, breaking teams.

The more interesting and surprising thing is that this behavior is more often observed with talented developers (skilled, experienced, seniors ones) than with others less experienced developers.

The way I understand it is:

1. They see as an evidence how to code software in a better way.
2. They like simple, brilliant, but "simple to use", software. (I do too). And as a result, they tend to less tolerate complex, not easy to use code, and easily feel that the code developed by other people sucks. Plus, they don't want to rely on other people code, especially if it's "hard" to integrate or will make them write some "ugly" code.
3. They are more subject to the NIH (Not Invented Here) syndrome. In some way, they would like all the software be written by themselves, if they had time to.
4. They see what to do in a global and precise view, and then underestimate the time needed to achieve their development (and test it, and document it, and QA it, and deploy it, and debug it, ...).
   

If you are a good developer, and willing to re-write any significant code by yourself, please refrain your nature desire. And ask yourself: what benefit for the company? For the business? Does your action will reduce the time to market of the product? Does the company will earn more money? Could you be more useful by doing some other more urgent stuff?

Maybe the code you want to replace is not perfect (even yours will be found perfectible by other people). But maybe it fits the company needs. At least for now. Maybe there's more urgent stuff to focus on. Maybe you will make the company loose time and money while you rewrite this code.


I have experienced this more than once on different projects. What I can say is that the more complex a project is (technically speaking) and is involving experienced developers, and the more I have been facing this NIH (Not Invented Here) syndrome that makes people reject the code written by others, and rewrite applications.

More than that, I've been facing talented and respectable developers that refuse to have a look to systems written by their colleagues, and don't admit they need their features, and only want to code everything by themselves - they will then recode a large part of the system without having noticing it.

Worse than anything else, I've seen teams replacing teams in order to rewrite everything from scratch as a remedy to a malady... and finally fail, making the company loose time, money and talented people.


If these words are ringing a bell in your head, please comment :)

Note: these words are not directly related to any project I may talk about in this blog.