Mickaël’s Weblog

I’ve read the post from Eric Lippert on Fabulous Adventures In Coding , describing what’s the “real work” behind 5 minute of development at Microsoft:

One dev to spend five minutes implementing ChangeLightBulbWindowHandleEx.

One program manager to write the specification.

One localization expert to review the specification for localizability issues.

One usability expert to review the specification for accessibility and usability issues.

At least one dev, tester and PM to brainstorm security vulnerabilities.

One PM to add the security model to the specification.

One tester to write the test plan.

One test lead to update the test schedule.

One tester to write the test cases and add them to the nightly automation.

Three or four testers to participate in an ad hoc bug bash.

One technical writer to write the documentation.

One technical reviewer to proofread the documentation.

One copy editor to proofread the documentation.

One documentation manager to integrate the new documentation into the existing body of text, update tables of contents, indexes, etc.

Twenty-five translators to translate the documentation and error messages into all the languages supported by Windows.The managers for the translators live in Ireland (European languages) and Japan (Asian languages), which are both severely time-shifted from Redmond, so dealing with them can be a fairly complex logistical problem.

A team of senior managers to coordinate all these people, write the cheques, and justify the costs to their Vice President.

And I garrantee this is not a joke…this is true. During my short carrier in software development, I’ve seen all size of software companies: from 6 to more than 7000. I’ve seen this only in large companies, so what startup (I guess we can also apply this to Open Source) companies are doing to handle this? They simply dont care and don’t do it.

Jeff Atwood comment also on this in his post Is Eeyore Designing your software saying that startup and Open Source do not have all this development process.

What is the rational for such heavy process? I guess at least 2 reasons: type of customer and sofware development vision.

Some of the large companies are targeting large customer (Fortune 500 for example) to sign for large deals. These customers are world wide companies, so the localization is key to close a deal. The documentation is also important. They also emphasis standards in their selection criteria as 508 compliance for US governement. Thay also have technical schemas as for example allowed operating systems or supported application servers.

The software development vision of large software companies is also an industrial view: be predictible through control and strong processes. It’s very common to hear people saying:

• You can’t manage what you can’t measure.
• You can manage quality into a software product.
• Software needs more methodologies.

These are part of the fallacies highlighted by Jeff Atwood (yes again) in his impressive post on Revisiting The Facts and Fallacies of Software Engineering.

I had a boss who was questioning : “Why building software is no as simple as making a car?”. He was refering to the ability to deliver a product on time with good quality…which is very rare in software delivery. First, making a car is not so easy, but I agree from an external point of view, it seams more predictable et cars more robust than softwares. The main reason is that software development echosystem is evolving a lot and quicker than car making technologies. The tools are always changing, every month some new technologies appears, even languages, methodologies also are evolving a lot. To gain predictibility, large software company are enforcing processes that decrease drastically productivity.

XML had its buzz periode 8 years ago, everybody rush on it to store information. It followed the hype curve, some technologies as RDBMS based on XML simply crashed, other as DTD has been replaced and finaly had been adopted by all the community.

Then it became the obvious solution to many problematics…maybe too much. I talked about this in a previous post on Why not coding in XML? (sorry about this one which in french). Coding in XML is simply a bad idea and BPEL is a good example of that overuse. I share the opinion of Jonas Fagundes when he sais in his post The misunderstood Maven:

“The weakest point in ant IMHO is to use xml to define the targets, for me xml is for data, I never liked programming in xml”

We start to see initiatives that try to readjust this.

Ant is a very good example where I think XML is not accurate. Ant is a tool that replace our old make files. Its aim is to execute commands to build a software (and much more, as deploymeny, test…etc). It is a knid of language, you have commands (functions), properties (variables), and conditional for commands (a kinf of “if” statement). Even if writting ant xml file is quit simple, for complex project with multiple tiers of different kind, and tests…this start to become a mess and you feel the need for best-practices.

I think the xml is not the right support to write code, and some open source projects goes into that direction as gant, Rake and Bake for example…this is the arrival of coding over XML…hence DSL.

Agile methodology are based on the capacity to make the code evolving. Extrem Programing have some principles around that as simple design and continuous refactoring for example. Notice, that the aim is not to anticipate future evolution.

Even out of an agile perspective, this is a good practice to keep code simple, maintainable, easy to make evolve and avoid what I call the Critical Code Mass. This post of Kevin Barnes on The Code Garden is worth to be read and is also talking about code evolution capability.

All this is about complexity of code, but this does not means thousands or millions lines of code. Of course, having a very tricky algorithm written with a too large code base will create difficulties when an update will have to be done: a new developer will need time to explore this code before doing the change (maybe even do some prototypes). Even the author himself of the code maybe request additional time to test the change before checking in.

The Critical Code Mass can also be achieved on a very small code base, for example, when the algorithm have kind of magic: few lines of code, but it is not obvious how it work and even why it is working. Implementing a change can also be a challenge.

I think it is really important to take care of this Critical Code Mass if you do not want to let your program behave like a black whole. This evolution of the code is silent and do not appear suddenly. If all the development team is not aware of this and do not pay attention to avoid it, the projects evolutions will become more and more difficult and long.

My recent post on BDD was a little bit light and requires some deeper thoughts.

BDD versus TDD is part of hot topics that introduce too much pation too often…so I will bring my 2 cents.

The video that I mention is the post raise key points to my mind about BDD vs TDD:

• They are both Test first approach
• They are not incompatible and are not adressing the same kind of validation
• To some degree, BDD tries to validate behaviour and TDD tries to validate sate,
• They are both about validation,

Finally, I don’t think they should be opposed, and the pasion around this topics seams, to me, due to mis-understanding about the wording. What is sure, is that they can be used to express the validation of some code before writing it.

They are not incompatible: you can validate a controller for example using TDD or BDD. The test won’t be the same, they will introduce/guide different code to the end…but both will validate that the code works as it is suppose to. Some will rightly argue that you will use Mocks if your controller interact with a class that send SMS for example, and you do not want to pay for the SMSs that you are sending during your test. But using Mocks does not meant your are doing BDD: you can use stub and validate the state of the stub instead of the call to the Mocks.

I think most of the discussions are to some extend steril as both approach are usually both valide. Nevertheless, I found this video very interesting on the rational behind TDD (or BDD) and where it goes. I personnaly dislike the idea of 1 class = 1 test class (same for methods). I think that the grain and organization should be different. The validation that makes sense, is to validate a feature that represent added value for the end-users. This is were is the true BDD. To me BDD just extends TDD (as “test first”) by making the relation between code and feature. Decoupling code and feature is the best way to get better tests as they are close to the features. When I say better, I mean easier to maintain, breaking only when one feature breaks.

“Reusablility is just a welcomed side-effect.”

I agree on this assumption, and reusability should definitly not be a graal or a goal…simply something to have in mind when designing.

There are so much more realistic concepts as Separation of Concern and Single Responsability for example. How many times a componant or a (set of) class(es) that were supposed to be reusable and finaly completely rewriten as soon as they are reused.

This week, the team get a training on Scrum. The goal was to introduce more agility in our development methodology. After this training, managers decided to use Scrum as Agile methodology, starting in 2 weeks for our neqw internal release. That sounds good.

The team is about 18 developers and QA engineers. Scrum recommende to have about 7 folks per group. This imply to split the team into smaller groups. The current oganization is really not agile; this not so suprizing as we kept the same organization for around 11 years and we are Agile practitioners only for 3 years. So the team in splitted into 3 blocks: QA and 2 development groups (business and platform). My concern is that we keep the same organization on re-grade the existing manager as ScrumMasters. I think this is faking Scrum for 3 reasons.

First, teams are supposed to be cross-functional, which is not the case today.

The ScrumMaster is supposed to be a facilitator/moderator and contribute to the features development as the other members of the group. The existing managers do not have such contribution. More over the ScrumMaster is not supposed to have any authority, which makes very difficult the association of manager and ScrumMaster roles for one person.

And last; self-organization of the team is a fundamental of Scrum. I do not see any of that in a re-organization fully handled by managers.

I hope we will go throw a different path: let the team re-organize itself by involving every members and do not fake Scrum.

We are doing daily stand-up meetings in our team. This is one of the agile practices that has been setup (we are doing also test-first and time-boxing). These agile practices have been introduced progressively as the company decided to go on this path.

The initial goal was to improve internal communication inside the team on the project. I’m not satisfied with the result regarding our goal. Of course, every one is a little bit more aware of what’s going on in the project, but the organization of the team impact strongly the results. The team is in fact a composition of silos, and the daily stand-up is just an enumeration of information on really different areas. Finally there are very few cases where appears some shared information (I mean, information that is useful to more than only one guy).

In a certain extend, it does not provide the feeling that we are all on the same project. At least, folks have a rough view of who is doing what…which is not bad.

Today, Jeremy D. Miller have written a post that exprerss exactly my feeling:

A team building a feature is far better than a group of individuals doing tasks