Stephane's thoughts corner…

Stephane Bailliez's thoughts on everything

I recently had to deal with lawyers to get more information about a few legal issues getting in my way. This was a first experience as an individual and was impressed by their billing process. The granularity of time spent working on issues are reported with a 15min granularity. Initial meeting is billed. Phone call is billed, etc…

I’m wondering what it would be like if software companies were billing the same way. Very often you spend an insane amount of time on actually figuring out what the customer wants, and this time is never billed. It encourages lazyness on the customer side, as he is often dealing with several companies at the same time and he’s just spending time and getting information and does not actually think about what he really wants. The first question a lawyer ask after you have exposed your point is:

what is your objective ? Is it this or that or something else ?

In my previous company, I have seen such process last for about 8 to 12 months. Meetings were done on average every 8 weeks or so, it was hard to get replies in a consistent way, meetings were so distant in time that it was actually counter productive and the scope was so huge that you could not get anything concrete done. Not mentioning the absence of adequate people to expose functional or technical issues. So needless to say that you spend a lot of money in such useless meetings.

I believe that if every company were billing like lawyers do, decisions would be made way more faster and things could actually be done ! Because the problem, especially in France, is mostly cultural. People are not encouraged by the systeme to take decisions. Due to social benefits, a culture of risk is not part of the equation. So when a decision is made, it is when there is no choice anymore and there is no more time in your hands…which is not really appropriate for software engineering,because you have then all the ingredients to a recipe for disaster.

That said, my bill is huge. Bloody lawyers.

Microsoft seems to step frankly into the Process Management with the advent of Visual Studio Team System. They have created a development process called MSF – Microsoft Solutions Framework, which has 2 derivatives

• MSF for CMMI Improvement, which should help achieve CMMI Level 3 compliance
• MSF Agile, whose analogy is obvious with the Agile Manifesto and that can adapt to any process through role distribution (Architect, Business Analyst, Developer, Project Manager, and Tester)

Ultimately, as there is no one-size-fits-all process that is the magic bullet for any organization, not many assumptions have been taken and you can perfectly define your own methodology with your own templates within Team System. As it is recognized in a MSDN article:

Microsoft currently has an established development process called the Microsoft® Solutions Framework (MSF), which is currently in version 3.0. MSF has not been widely adopted across a broad base of developers even at Microsoft, possibly because it is viewed as difficult to learn and use

Mainly, without delving into details (which seems overhelming), VSTF has the following capabilities:

• Gives you a set of document templates (word, excel and project files).
  It gets you started for all stages of the project from business requirement to project closure reports.
  Project methodology can be based on MSF Agile, MSF for CMMI or eXtreme Programming
• Integrated Nightly Build into Team Foundation Server
  This looks similar to CruiseControl, AntHill, Beetlejuice, Continuum and all the like
• Integrated Unit Testing in Visual Studio Team Test
  This looks similar to JUnit framework integrated into IntelliJ IDEA or Eclipse for example where you can generate a test case skeleton and you write your test methods.
• Work Item Tracking
  This features integrates with Microsoft Project or Microsoft Excel

The thing is that everything is fully integrated within Team Foundation Server. For example you can define check-in policies such as:

• Work Items – a checkin must be associated to an existing work item/task
• Testing policy – Unit tests exist and are working. They also be associated to work items, further defect reports and fixes can also be associated to a work item
• Code analysis – The code meets coding standard
• And any custom policy

Of course, your Process Development portal, fully integrated within Microsoft Sharepoint allows you to have all the metrics/graphs associated to your projects.

When I see how most shops get out of their mind to deliver a simple product in several months and a couple of developpers, there are obviouslly a lot of lessons to be learned in project management and portal like this are a necessary step.

However, it is not a magic bullet and you should carefully analyze all figures that it gives you back. Plus it is definitely not something you get up and running in 2 days..and ‘ZAAAM’ productivity and quality is increased by a factor 50. Just like any process, it will take you months if not years depending on the organization culture and inertia. After all CMMI feedback already says that a CMMI step takes about 18 months.

18 months seems mostly in par with my own experience of implementing automated unit tests, coverage, metrics and daily builds with everything built from scratch in an existing organization with bad to no practice at all.

Big negative point. You must nearly get the whole Microsoft suite from A to Z to get the best of the process management portal. Looks like though there is a converter for example to have IBM ClearQuest as your bug tracking system… says a lot though about the type of organization they are targeting. What about Bugzilla and Jira ?

I was asked recently by a person with zero knowledge of the software industry to explain what lies behind the title of a J2EE architect and to explain what is opensource.

Defining what is behind a J2EE architect has been discussed at length not so long ago in a JavaWorld article Hiring the phantom Java architect and the associated TSS thread.

In the software industry, defining the responsabilities behind a title is a challenge in itself and you may get as many definitions as you have people. In an IT company working contract, the responsabilities of a software engineer (I’m assuming that a software engineer is related to all people working directly in the software industry) is often defined as “assignements can be anything, can happen anytime, and can be anywhere“.

Having such a non-clear cut definition of a job title obviouslly does not help our industry much. If management is not aware of the basic requirements of software job in terms of involvement, it obviouslly encourages acting more as a meat seller than a knowledge seller. Been there, done that.

In the software industry, the DIY (do-it-yourself) , NIH (not-invented-here) and ‘Reinvent the wheel’ syndromes are well known classic management pathologies.

To some extent it’s in your best interest to leverage other people’s work and look at what has been working or not in other (similar) organizations.

Imagine an IT company of about 41 people with about 25 consultants and a 55% employee-turnover looking for VCs.
To “handle the future growth and help communication flow”, and after extensive thoughts, meetings and weekend meetings, the CEO, CTO/co-CEO and CFO it have decided to have the following meetings:

• Weekly Executive meeting on monday morning from 8AM to 1PM
• Weekly Executive/Senior project managers meeting on monday at 7PM
• Monthly project manager meeting on wednesday from 7PM to 9PM. All questions to be adressed must first be sent to the preceding Executive/Senior Managemers meeting.

Now, when reading this, I feel like: “don’t people learn ?”.

Set aside the fact that the schedule is simply and completely insane from a social and efficiency point of view, this is at 180 degrees from running effective meetings. There are tons of books and articles on this topic and very large organizations with more than 100 times employees are doing their best to get away from these kind of ‘waste-of-time’ meetings by:

• Meeting only if necessary
• Having an agenda
• Keeping the meeting short: at most 45 minutes
• Starting on time and ending on time
• Issuing minutes