A tribute to our feminine volleyball team who won the French championship!

May 27, 2011 1 Comment

Earlier this year, we decided to sponsor CGI volleyball team. I have personally played with this group for almost 20 years, the CGI name surviving the absorption of the former company by IBM more than a decade ago.

This association has 4 volleyball teams playing in the FSGT league, a championship in France that gathers sport teams usually coming from Corporations. This year was a revival for the group, with many new members joining the association and it was actually the first year that a CGI feminine team joined the league.

The weekly championship takes place at local level but there is a national competition which gathers the best teams throughout the country.

Not sure whether it is the players’ quality or the brand on the jersey that made the difference (I like to think it is both as SoftFluent strives for excellence :) ) but they certainly dominated their league in the national championship, winning the semi-final and the final in Bordeaux without even losing a game.

Next year, they will compete at the "top level" of the French championship, with the opportunity to qualify for a world’s championship of these Corporation leagues in Brazil.

So thank you girls for defending the colors of our brand, you are the best and deserve all the kudos. Good luck for next year, it will be much tougher!

image

From left to right: Véronique Bruneau, Isabelle Lubas, Paola Gava, Alexandra Ferreira, Marie-Mélodie Baralle, Marie-José Duque-Ribeiro, Florence Dejean & Frédérique Sandro.

Missing on the picture: Nathalie Vivier, Bénédicte Deflesselle and Iris Mazzacurati.

Filed under News Tagged with

The “No Services on Entities” dogma

May 20, 2011 Leave a comment

Today, we would like to open a new category on our blog under the topic “Trendy patterns that can kill you”.

Since in the field, we observe a lot of confusion in the interpretation of key architecture concepts and their translation at implementation level, we decided it would be worth sharing our point of view with others.

We are aware that some of these interpretations tend to be “broadly accepted” by the community at this stage, and this is why we call them “trendy”, but we still think that these interpretations are often irrelevant or simply useless, at least on the .NET platform.

An important point is that our opinion is anything but dogmatic, and we might even change it over time if we get convinced that it provides a tangible benefit in some scenarios, but we have selected patterns that – to date – have done more harm than good to the .NET projects we know. In the end, everyone will make its own opinion and base decisions for his projects depending on objectives and constraints.

Let us start by the “No Services on Entities” dogma.

What is it?

Many architects argue that no service should be implemented directly on business object classes. Instead, the recommendation would be to create another kind of classes dedicated to implementing the services and consolidate appropriate methods, possibly across several objects.

What is the driver?

The arguments usually emphasize the separation of concerns, and the fact that services cannot always be clearly attached to one specific object.

Why don’t we buy those arguments?

First of all, with a cumulated experience of hundreds of projects, we never faced a situation where the service could not be relatively naturally attached to a business entity.

And the reason is quite easy to understand, a service is not different from a method, except that it is exposed to the outside world. So if you are used to object-oriented programming design, you should always be able to find the relevant class to support the behavior this service is about. Second, separation of concerns is not a goal as such.

It is interesting to separate elements that should not be too closely coupled, either because:

· Those elements can be used separately and separation could then improve reusability (a driver or a plug-in for example)

· Those elements have different evolution cycles and they will not evolve at the same rhythm (business rule intensive components or web user interfaces that need to be frequently revisited for instance)

In our views, and as explained above, a service primarily exists to serve as an interface to external systems, and .NET provides you with all the relevant mechanisms to create interfaces for your objects which need to be exposed as services.

If you need to create interfaces, just do so, once you do have at least two implementations or if you are sure you will have more than one. Do not do it before though, as you won’t be able to change it once you have created the "contract". We will comment further on interfaces in an upcoming post.

Why is this harmful?

We truly believe that adding layers and complexity that are not strictly needed is always harmful, as the biggest challenge of this industry is to deal with systems that are already getting more and more complex, just by technology evolution.

A second argument is that it greatly reduces code readability. It is not easy to find a name for these classes that will support services. In fact they usually end up with names such as SomethingManager, and it does not map to any concrete object, contrarily to what object-oriented programming was primarily designed for.

If you struggle naming your entities, properties or methods, give yourself more time to design, since you are probably on the wrong path. And it is likely that it’ll give a hard time to the ones who will maintain your code in the long run.

The .NET Framework itself is heavily object oriented and does not follow any complex service pattern. If it did, it would simply contain 40,000 classes instead of 20,000.

Filed under Software Development, Trendy patterns that can kill you Tagged with

Why Model-Driven is the solution to the evolution challenge

May 12, 2011 1 Comment

The only viable route to manage obsolescence

What is the evolution challenge?

Technology innovation is going fast, and this pace of change is accelerating as the world goes global and the competition gets fierce. A lot of announcements are made every day by technology providers and it does not look like this motion is going to slow down. The multi-layer style of software development has increased flexibility and capability, but has also strongly increased the complexity of software development. With the multiplication of platforms and devices, such as cloud platforms or new mobile devices, and the growing needs to connect to collaborative social networks, we can be sure that this complexity will keep increasing in the future.

At the same time, for several decades now, businesses have developed significant operational IT systems, going further and deeper in features supporting their business and vertical sector. This means the legacy is way more important than it was years ago, and it is most of the time increasing. A recent study by Gartner showed that what they call the “IT Debt” is growing at a worrying rate.

In all businesses, there is a high pressure to lower costs, while providing new services to remain competitive in a more complex environment, and at the same time bearing the increasing legacy burden mentioned above, with its set of obsolescence constraints. Some systems even run totally unsupported which might become a critical issue that will force a reengineering at some stage.

For enterprises which need to maintain and improve the systems supporting their businesses, this is a quite unsolvable challenge, at least by keeping the same approach that was used in the past.

What is our proposed solution?

In our view, it is not a solution to just apply past recipes of redeveloping the applications at each new technology wave. In fact, we do not see any client managing to do it and except for very few extra-rich exceptions, no enterprise can afford such a cost. And even if you were very rich, it would probably be a better option to spend your money on increasing your business.

At the same time, maintaining very old applications tends to be field reality, but one can legitimately wonder how long can this still be sustained without a major crisis. And such a “status quo” strategy, which is obviously less risky in the short term, is probably a sure path to death in the long term. Because once a competitor in the same vertical has been able to deal with it, it will be too late to start a reengineering which will take a long time to achieve. Competition will have killed you during this period.

This is why we think that there are 2 critical areas that any enterprise organization should be working on proactively:

A. Set measurable objectives on the reduction of maintenance for existing legacy systems,

B. Use the savings to implement new projects in a way as independent from technology as possible.

On point A, it is critical to precisely evaluate maintenance costs, in terms of hardware, software licenses and maintenance fees, and of course human expenses to run the system and correct bugs. For custom applications that are in maintenance mode, the cost is highly correlated to the number of lines of code and the quality of the application. Refactoring existing applications without any functional change can provide huge savings and is not a hard task, as long as we do not fall into the trap of changing features at the same time.

On point B, model-driven is exactly the promise of capitalizing our work at a higher abstraction level than code. We and our customers have been delivering projects that way for 6 years, and this evolution capability is obvious once you have done it.

We sum this up through our 4 tenets that come from our experience:

1. Business entities have longer lifecycles than technology and should be defined in formats that will survive technology shifts and allow supporting them without reengineering the application.

2. Business rules and process changes need to occur through short cycles that can fit into a lean continuous maintenance scheme.

3. Efficient coupling of data, model, and presentation layers including customized code parts must be guaranteed by design.

4. Coding patterns need to be standardized and their implementation automated to ensure maintenance can be performed by standardized skills.

image

If model-driven is the solution, why Microsoft does not seem to be interested?

Since Microsoft dropped the Oslo project, and smart and talented people like Don Box have moved to other jobs in the company, one can legitimately wonder what Microsoft plans about model-driven are. Visual Studio Magazine has even published an article somewhat positioning our CodeFluent Entities product as the future of Model-Driven on the Microsoft platform.

Why has Oslo failed? As former Microsoft employees, here are some of our views on the subject.

Microsoft is a platform company. Despite a huge product offering, most of the revenue still comes from the platform, and any initiative that structurally helps the customer in being able to move away from the platform is not very well received internally, which one can easily understand. It generates a lot of internal conflicts between product groups.

It is interesting to note that even in Entity Framework, which approaches the data tier modeling in different ways, the “Code First” approach is pushed quite strongly by Microsoft. We think coding before thinking is probably not the good approach, as the global view of your model and the real key design questions are lost, but it seems more important for Microsoft to ensure developers approach development in a platform-dependent format and directly inside the language, than take the risk to give them the opportunity to switch to another platform at a later stage.

In further posts, we will detail more about our metrics for software development performance gathered from our field experience, and the cost that we think consistent with the dimension of a project: counting tables, screens, rules, reports or entities, as well as lines of code.

In a few hours, we will celebrate our 100th post on CodeFluent Entities blog, and give some insights on how we got there, starting from a very pragmatic field experience.

Filed under CodeFluent Entities, Software Development Tagged with

Motivating developers

May 6, 2011 1 Comment

Mazlow’s pyramid applied to developers

Approaching the mid 40s, I have now managed a quite significant number of developers, directly or indirectly, by also observing many development organizations as an external consultant.

Every manager in the development business will also tell you that you don’t manage developers like you manage other people. There are very good articles about it on the net, and I started this article by making a simple compilation of those developer motivators, also to make sure I do not forget a key one.

At the same time, every HR consultant will also explain you that managing people is a discipline you can learn, and there are many theories and best practices about it. Then, those theories should apply to developers, as they are also human beings. So how can these two professionals be right at the same time?

The answer I came up with is that, using the same theory, it could be interesting to just consider that needs and motivators are expressed a different way for developers. This gave me the idea to apply the good old Mazlow’s pyramid to developers… by tweaking it a little bit to transpose the needs at a slightly higher abstraction level.

As a reminder, here is what the Mazlow’s pyramid is all about. It explains that motivation is a kind of hierarchy, and you can’t jump at the higher level if the needs below are not fulfilled. Please HR professionals, don’t blame me if this is too simplistic or if you are a fan of another theory, this one has the merit to be quite easily understandable.

Mazlow

Putting my compilation of all the key motivation elements I selected as important for the developers, here is how I would transpose it for developers.

Physiological needs

1. Give developers the right tools to do their job

Being equipped with the proper level of hardware and tooling is as critical as breathing for a developer. If you don’t give them the right tools to do their job, not only will you lose precious hours of productivity, but don’t expect to go anywhere higher on the pyramid. Giving undersized hardware to developers or putting them in noisy open spaces is also a sign that you don’t value their job.

2. Refrain from excessive process constraint

Development is a job that requires some level of creativity (which is sometimes also an issue when not used at the right place but this is another story I will develop in another post). Being creative is not compatible with heavy process constraints. You cannot find a solution to a problem by just planning every second of your time or being disturbed by an excessive number of meetings.

3. Reduce their inherited technical constraints as much as possible

Systems live longer as expected. As a consequence, there are often some level of technical constraints in your project: an old database schema that cannot be changed, a poorly-designed legacy system that adds some rigidity or a customer that imposes usage of some specific technology. The more of this you have, the less comfortable the developer will be. Reduce those constraints as much as you can. One key to this is to really makes this a goal, even if you take a multi-step approach to make it compatible with your business. Keeping legacy constraints other time is very costly in terms of maintenance anyway.

Safety needs

4. Ensure the work they do will be used

It might seem obvious, but it is not. Since there is a high level of project failures in the software industry, developers that have already faced a situation where all their code was dropped might not feel safe as some issues arise on the project. And do you know of any projects where no issues popped up? The best way to do this is of course to repeatedly deliver your projects by correctly managing them. Implementing continuous delivery through agile methods is also a guarantee not to have a multi-month tunnel effect that can lead to a large drop of code base, which is not only a financial loss but a huge motivation killer.

5. Compensate them at the appropriate level

Compensation is clearly not the ultimate goal of real developers. Still, it is of course an unavoidable need as for any human being on earth. You can work much better when your personal requirements are fulfilled with some increasing level of comfort at home. Making sure there is some regular progress in compensation as the skills and the achievements grow is also very important. I personally position it at "Safety" level of the Mazlow pyramids for developers.

6. Provide reasonable career path visibility

Equally, developers will feel safe if they see their job as sustainable, and even better, as providing a path where they can climb some steps. They are not striving for career in the sense of managing more and more people, but they for sure value the titles that recognize their knowledge and expertise, as well as their ability to design complex systems or to mentor others. This is why all successful software companies have titles such as "distinguished engineers" or "technical fellows".

Belonging needs

7. Share the big picture

Once the above needs are fulfilled, you might be able to climb at the "belonging" level of the pyramid by creating a team effect. One key element of creating the belonging feeling is by sharing the big picture of the project. Don’t expect too much from developers if you just give them the tasks one after the other without giving any meaning to what they do. It is very bad for motivating teams, not to mention the fact that you will probably lose opportunities to improve the overall design.

8. Manage them through field people

This is a very important one. A developer will not find legitimate to be managed by someone who never was a developer himself and cannot fully understand their job. Considering the nature of software development, I think it normal. It is quite impossible to understand the issues developer faces if you have not done the job before. A good development manager does not need to have developed for 20 years, but he (or she) should at least have developed for some years to make the right decisions when they become necessary.

9. Favor technical discussions between peers

The more your developers discuss about technical issues and solutions, the better. Not only it will make the team more efficient and skilled over time, but it will also contribute to this belonging feeling that increases developer satisfaction and motivation.

Esteem needs

10. Make sure they always learn new things

This one is not always easy to achieve at every moment, depending on your business constraints. Fortunately – for this point because it can also be a real thorn in the side for your budget – technology evolves quite fast. So if you proactively work on removing the legacy constraints and provide enough guidance to developers, there is certainly room for learning new things on all projects that I have seen.

11. Recognize good work

It might seem obvious but people often forget about it. Everybody needs to be recognized. Depending on the nature of the people, you can do it publicly, or more intimately, but tell the developers you are happy when they achieved a good job or when they worked hard to meet a milestone. Simple recognition gifts or even just a few words like "Good job !" can make a difference. And there are moments that clearly need to be celebrated collectively.

12. Encourage external contribution to communities

Beyond the technical exchanges inside the group or the company, you might encourage your people to be active in the community. For younger folks, it might mean more listening than contributing, but it is always a good idea to do so, as it also gives them ‘icons’. For more senior people, if you have very good ones, give them time to contribute and get recognized in the community, especially if they have skills to write about technology or to speak at conferences. It will certainly have some positive impact on your business anyway.

Self-actualization needs

13. Make them accountable from A to Z

Reaching the self-actualization level of the pyramid should be a goal for development people. It is unlikely to get reached in the early days of your career, but having the big picture in mind is a good motivation. One sign that you are getting there is that you start to be fully accountable of what you deliver. This might be high pressure but it is also the counterpart of getting maximum freedom as per next point.

14. Put them in control to use their creativity

Developers are at the highest degree of satisfaction when they can control every decision on the project. Being able to make all architecture and tooling choices is very satisfactory. It goes with the accountability of point 1, which can be dangerous if you don’t have all the skills, but this is what all senior developers should strive for. Once you get there, you can express all your creativity to find the most relevant solutions to your business scenarios. As a manager, you have to portray this target to developers to motivate them and keep your best people at this level on freedom.

15. Contribute to something big (or cool)

The ultimate level is reached when, additionally, what you have built is "big", or possibly more important for developers, "cool". Cool is hard to define as it can take several form depending on your profile and sensitivity, but it may as well be the resolution of a tricky issue as the contribution to a project that has worldwide visibility or usage.

Listing all those key elements to motivate developers, here is the developer version of Mazlow’s pyramid I was able to draw.

MazlowDevelopers

As usual, feel free to comment.

Daniel COHEN-ZARDI

Filed under Software Development Tagged with

Follow

Get every new post delivered to your Inbox.

Join 183 other followers