Monthly Archives: May 2012

Skills Management #4: CSC Belgium case


CSC Belgium provides IT services and custom software development. They make a point to tackle challenges and succeed thanks to the developers they employ. The management of their skills is then a part of their assets.


We continue to schedule meetings with key people at companies developing software in order to observe and learn how they currently manage the skills of their developers. Three weeks ago, Martin and I went to CSC Belgium to meet Yves Jonckheere, Senior Consultant and coordinator of the development center. Here are some of his insights and challenges in skills management.

CSC Belgium

Honestly, before meeting its BeLux managing director, Philippe Jaeken, we didn’t know much about CSC. We quickly did our homeworks to learn more about them. To summarize, CSC seems as big as IBM from our point of view. On their website, they explain what they do as “we do amazing things“. After reading about the kind of projects they have led, and more so after meeting them, we can believe that. Precisely, CSC Belgium provides customers in the industry and government with solutions crafted to meet their strategic goals and enable them to profit from the advanced use of technology.

Currently, CSC Belgium employs about than 500 persons. They manage several projects in different technologies such as .Net, or Delphi, but their main focus is Java EE, that they use in many projects for different customers from federal administrations or ministries to insurances and banks.

Developer profiling is not an option

When they discuss with their customers, CSC needs to know exactly what the developers can achieve. They even provide the developers’ resumes to their customers. But having up to date resumes in not only useful for sales, it is also an intern knowledge base to know who to call when they needs specific expertise.

Practically, a competency manager keeps tracks of the developers’ skills and their participation to projects in a database. The tracking is based on their resumes, each person being responsible to keep his own up to date. The competency manager is then a contact point for all project managers needing a specific profile, or specific technical skills.

While the  competency manager is in a central position, he’s not the only reference. There are the common de facto hub persons who are there from a long time and a kind of living references. Developers naturally turn to them when they’re looking for an expert on some topics.

Java Community

The human hub is a natural strategy of skills management but it is a kind of single point of failure. That’s why CSC has developed an official hub: the Java community. The community allows developers active on very different project (and in different location) to meet with others using the same technology.

The community is composed of the developers themselves. It is led by one developer in charge of the organization of the events, during which developers meet and exchange knowledge. They are usually organized around a few topics presented by the developers. They are also the prefered moments to detect possible synergies between the different projects and teams.

Personal Development

The community is very adequate to initiate knowledge transfer, but it is not a training program in itself. It doesn’t allow a developer to completely develop a new skill. To support the personal development of developers, CSC has put in place a whole strategy composed of training, coaching and assessment.


Each developer has the freedom to follow a few days of training around the topic of its choice each year, in compliance with a general personal development plan. When some projects require very specific skills, an ad-hoc program is then organized for the developers assigned to those projects.


By CSC, everybody is followed by a coach, a person outside of its direct hierarchy. A coach follows several coachees in a same time. It is a person of reference with whom the coachee can discuss about its personal development or any other topic (technicals or not).


Twice a year, an assessment of the developer work on the project is done by his project manager. The coach get the results of the appraisal, and can then setup with the developer a set of actions to resolve any lack of knowledge (for example by setting up a training plan).


CSC wants to develop further their current skills management and provides to their developers a way to keep track of their evolution in order to:

  • increase their learning capacity,
  • make it easier to keep the resumes up to date
  • improve their coaching follow-up,
  • increase the knowledge transfer between the developers, and
  • improve risk mitigation.

Those challenges are totally in the philosophy of the company and its motto, as doing “amazing things” requires investing in skilled and motivated persons.

We would like to extend our thanks to Philippe and Yves for their insights on CSC Belgium skills management.

A word for those bad applications : let them live


Before rewriting even an obviously badly written application, be sure that a) you’ll do it better (this time), b) there is a real ROI to do it and c) it is the best usage of your time.

You know them, I know them

Those applications are all too frequent to be missed. You stumble upon one or two at each company that you arrive, whether as a user (as a developer, it is difficult to not “snoop inside”, even when we know it would be bad) or (worse), as a maintainer. The most typical case is for me custom-made internal applications that probably solved a very simple problem once, a long time ago. They may have been a smart replacement for an Excel sheet becoming unusable (“oh, let me just one day, I could make something far better than that”).

An example

This is not exactly one single application, more like a combination of some that I had the bad idea to find on my way, and that summarize for me the “bad application” case. This application is a web face-on-database, and was initially developed to solve a problem in a single service, which happens to be a part of IT. One of the reasons those things tend to appear in IT services is that those guys have (for better and for worse) the capacity to develop them themselves. If you are another service in a large company, the cost of the formal development demand would probably kill those infant-application long before the first line of code – which is sometime a very good thing.

Over the years, it did grow a bit, adding some features, and started to be used outside of the initial group. In the same time, following the organization changes, it did pass by half a dozen different hands, the initial sponsors (and developers) being long gone to other departments or companies.

Of course, you are not specially aware of all this history when you find yourself the brand new maintainer. What you will spot however is the technical nightmare. Among others, expect:

  • Outdated documentation – if any

  • Creative database engine (MS Access?)

  • Inconsistency all over the place (case, foreign key naming, plural usage, etc.)

  • Large unused parts (but which ones?)

  • A lots of web page with embedded SQL, and not a single line of reuse/import/include

  • Usage of very low level API (cookies, string manipulation)

At this point, it is just screaming “Rewrite !”, and your first report on the application shows a list of problems, and the benefits of rewriting it from scratch as soon as possible. Added bonus: it does not look so complicated, so it would probably not even cost much time.

Not so fast

I’ve been through there, you probably have too. The problem here is that technical debt, while being something too often underestimated, is not by itself an argument for rewriting an application from scratch. The two good questions, once the initial appraisal is done, are:

Will the new solution be much better ?

Maybe you think “Of course it will! We know exactly what it needs to do, and by starting over, we can have clean design allowing for evolution!”. You may be right, but you may also just have started a costly rewrite that could give birth to yet another bloated application. Doing better the second time is possible, but it is far from being automatic. In most situations, it will depends on the sheer size of the application (rewriting big applications is not easier than writing them – actually, as they are already running, it may be harder) and the availability of good information on what it is supposed to do (you do not want to rewrite based on the use cases that are in the code, and it is probably hard to read anyway).

The big rewrite scenario typically means choosing between rewriting the whole application before doing a “big bang” replacement or do it bit a bit, both alternatives being grim in their own way:

  • The big bang means a long period with the old and new application being maintained at the same time (each patch done on the production needs to be applied to the new system), without any new feature (which will not please the users). At the end, the deployment of the new system becomes something very complicated and risky, especially regarding the high expectation that the users will certainly have after having waited for so long.

  • The “replace the pieces” is a technical challenge in itself (make something new on the basis of something old is never simple) and the users will have to use parts of both applications during the whole rewrite period (losing whatever piece of consistency that may have been there). At the same time, each migrated component will require to be integrated in the blended system, and those successive operations will surely left traces even after the removal of the last part of the old system.

What is the ROI ?

As a developer, this is a question I got several times from my management, and that used to make me quite angry to justify, especially when the case was crystal clear (like, doing Unit Tests). Looking behind, not only do I understand the question, but I think it should probably have been asked more.

We are not doing software for the sheer sake of it (even if it may be enjoyable). We make software to make life (or business) easier. This doubly applies to rewriting, as your new application needs not only to work: it needs to work better enough to justify its added cost on a already running (and paid for) system!

The deciding rule should be the rewriting ROI, with indicators such as:

  • How many bugs are we getting on this each month? What time is spent fixing them?

  • How much is the application evolving? Do we get new features on a regular basis?

  • What is the mid-term plan for the application? Will it be replaced, stay there, or be used more and more?

Remember that for each point, having ROI in the new application is not enough: the difference between the current costs and the projected ones for the new application needs to be big enough (however good your new design may be, you’ll have bugs and code smells).

Finally, even if a ROI can be found, do not forget that one possible alternative to rewrite would be to buy an application to replace the old one. If the use cases are common enough, it probably does exist (every company and department thinks its needs are totally specific, and in most situations, they are wrong.).


My message and experience on this is not that we should never rewrite, but more that we need to make those kinds of choice with a product view, not a technical view. And this means in some situation to learn to live with the crapware that works good enough. It allows to concentrate on other, more important issues (that is: issues bringing more business value). Remember, development time (yours, your team’s, your company’s) is not an infinite resource: use it wisely.

Let them live, you have better things to do.

Solving the founder’s dilemma

Remember this tweet from not so long ago:

“The entrepreneur’s dilemma: Maintaining friendships. Building a great company. Spending time w/family. Staying fit. Getting sleep. Pick 3.”.

I think I solved this dilemma almost without thinking about it. May be not completely, but mostly, with a single simple act.

Our current time schedule is (roughly): spend two days a week doing consultancy (we’re bootstrapping, so we need to get the cash flow from somewhere), the rest (which may be between three and five days) are spent on Sybil.

The time “on Sybil” itself means many different things, from (obviously) coding to customer development, via meetings with advisors, presentations or events preparation, networking, interaction with a designer, administration and I forget some.

All the points are important, all need to be given the proper attention and time, all of this in a mere 7 day-week.

As we do not (yet) have the money (nor, more importantly the necessity) to have dedicated offices, we tend to work from my home (I had more space to begin with). This has a very simple consequence:

As my girlfriend work out of town, we tend to wake up early, so by 7:15, I’ve taken my breakfast and are ready to “go to” work. One volley of stairs later (probably around 7:15:12’’), I’m at “my office”. When I begin to feel hungry around noon, I’ve already more than 4 hours of work behind me. The lunch is something that goes pretty fast when you just have to eat, and want to go back to work (which, as a Founder, you should). At the end of the “office day”, around 6:30 PM, the “work clock” is already around 10 to 11 work hours.

The best part is that, by stopping at that hour, I’ve still the time to go fetch some food and fix the dinner.

I’m not saying that I’m not spending evenings or weekends on Sybil, but as long as you are not an heavy sleeper (truth be told, there is an unfair advantage be able to rest in less than 6 hours), you can still get a good amount of work done, spend some time with your family and even keep some social life in a single day.