In every project, there is a conflict

The conflict

The conflict is between what the developers want to develop and the product the customer wants to have made for him.

No software development project is without this dynamic.

The trick is to harness the software developer’s enthusiasm for developing good software without endangering the overall success of the project.

This requires that you reconcile the 2 parties.

They have similar but not the same goals.

If you pick technologies that can satisfy these 2 goals enough to keep both sides happy you will have a good basis for a successful project.

For the most part, the customer is not interested in the details of the technology.

The customer wants his software to solve a problem, over a particular period of time and by a particular delivery date.

The software developer is in general interested in the customer’s problem but also has a need to create something new innovative and fun.

CV Driven Architecture

CV Driven architecture or Resume Driven Development refers to the idea of a developer choosing the technology based on what would look good on his resume (CV).

This can be in conflict with what would best suit the goals of the project.

There are 2 extremes that must be avoided

Dead end technology

If the technology is “dead end” you will have a hard time finding developers to carry it out or maintain the project.

Most of all, with dead-end technology you run the risk of diminishing support during the software’s lifecycle.

Bleeding edge technology or pattern bloating

If the technology is too bleeding edge or not appropriate for the problem it is supposed to solve, it may be either over budget, over schedule or not fit for purpose.

Similarly trying to put as many of the 23 Gang of Four patterns into the project as you can without a basis in a customer requirement happens more often than you might think.

I have been involved in projects that have been canceled before completion due to overruns.

I have also been involved in several bleeding edge projects that were considered a success.

But you are left with the distinct feeling that they could have been done with a fraction of the effort.

This would have required the developers to be more compromising with their enthusiasm for the new.

Get the balance right

The solution is to keep a balance between the development team and the customer.

Pick the newest technology that fulfills the following checklist.

How well accepted is the technology?

For instance, are there hosting providers acceptable to your client for the technology your planning to use?

You may be in the embarrassing situation of a major rewrite before you can deploy your solution.

This will have an impact on your effort and delivery date.

How stable is the technology?

If the technology, you are using has less than a 1.0 in its title it may not be stable yet.

Chances are it is going to change before your project is finished.

You possibly will have to rewrite the parts that have been “improved” in 1.0, 1.1 and finally in 1.2 it actually does what you expected.

Are there developers proficient in this technology?

How many software developers are proficient in the technology.

If this is a bleeding edge technology, then it could be the case that there are few developers who are proficient.

In conclusion

There needs to be a balance between cool and fit for purpose when deciding on your technology mix.

Similar to architectural decisions there are no right or wrong answers just benefits and trade-offs.