Xebia Blog

Most of the times we are content that our code is of the right quality, if somehow, we manage to get the Static Code Analysis (SCA) tools like Checkstyle, PMD etc. report less number of severe violations. As an example if we see that the class is big in size then we conveniently split it into two or more classes to get rid of the violation. The tool is happy and so are we and most of the times that is the end of the story.

However more frequently than not getting an SCA violation is the start of the story. If you start associating the question “Why' with every SCA violation found then the real reasons start unfolding.

This is similar to the way we resolve impediments on an Scrum project. The impediments rarely represent the isolated incidences of inefficiency. Rather, most of the times they are a part of a larger problem. The way to work out an impediment is fix it so that the team can work effectively and then to look at the root cause which caused the impediment so that the main cause can be fixed. This is called “Bottom-up process re-engineering.”

Similarly the way to work out an SCA violation is to remove it so that the code looks clean and good and then to hunt for the real cause.
(more...)

Filed under: Articles, General, Java, Quality Assurance
5 Comments

15 Stand-up commitments for those crucial 15 minutes

It is another great day, sun shining bright, traffic snarls continuing on roads, the team getting ready for another productive agile day with droopy faces! Droopy faces , why ???

Well because they have to get over the stand-up ritual first before they can get started with some real work.

But is the stand up a ritual??? Aren't stand-ups supposed to be exciting and energizing???

If this a common question disturbing you for a while then it is time to stand up for the stand-up. The details that follow are meant for any team practicing any Agile methodology like Scrum and who has started thinking that stand-ups are no more than an empty ritual which has to be pushed out at the start of the day.
(more...)

Filed under: Agile, Articles
2 Comments

The origins of lean thinking lie in production and there’s quite a bit of interest in finding parallels between current software development practices and those of manufacturing. The Poppendiecks for instance, frequently quote examples from classic manufacturing companies (Ford, GM, Dell, Toyota) to help understand why agile methods are a very effective approach to software development. Oddly enough they (and many, many others) are hesitant to buy fully into the concept that manufacturing industries and software development have indeed much in common.

(more...)

Filed under: Articles, General
8 Comments

We’ve put up a new article on the Articles page. Summary follows:

The article Factories are about abstraction, not creation told what factories are for, and when they should be used. This article will show different ways to implement factories. The complexity that is needed for a factory implementation depends on the required flexibility and how much effort is needed to construct a complete instance:

• when should it be possible to configure the factory repository: can it be coded and remain fixed for a release or should it be configurable at runtime?
• does the client of a factory need to influence the subclass choice in some way?
• how complex is the algorithm to determine the correct subclass?
• how difficult is it to construct a valid instance of the required class?

Filed under: Articles, Java
No Comments

Agile development is aimed at producing valuable software early and continuously. Sadly enough it seems to have only been picked up by the software development community. Many discussions on Agile development stress the importance of agile practices to the development process. The discussions treat the importance of TDD, pair programming and so on. These practices are very important and when done properly done will increase the quality of deliverables considerably. But the regular discussions on Agile obfuscate the real benefit of Agile development: Producing business value.

(more...)

Filed under: Agile, Articles, General
No Comments

We've put up a new article. Summary follows:

Polymorphism is the main mechanism to create maintainable object-oriented code. Client code uses other code through an abstract interface, and as long as we don't break the behavioral contract, we can change the implementation behind that interface at will.

You will only achieve real maintainability if client code has dependencies to other code through an abstract interface and nothing else.
Unfortunately creational logic will - by its very nature - break this rule. When you create an instance, at some point you will
need call the constructor on the actual implementing class. This creates a dependency that prevents you from changing the implementation transparently, effectively cancelling the advantages of polymorphism.

The solution to the creational problem is to protect the abstraction by hiding the creational logic from the client code. Dependency injection is the ideal solution, in this case the client does not use creational logic at all. But in its turn the injecting code needs to create real instances.

This article is the first of a series of three: this article will illustrate how the creational problem manifests itself, the second will deal with some advanced implementations of creational code, and the third will deal with dependency injection.

Filed under: Articles, Java
No Comments

The Software Development Process (SDP in short) defines the way business ideas are put into software practice. It covers the entire process from requirements definition through to using the software in production. Many projects simply fail because of the fact that the business and software development processes are not aligned. It is a known fact [Standish98] that the most important factors that make or break a software development project are:

1. User Involvement,
2. Executive Support and
3. Clear Business Objectives.

These factors are more important than an experienced Project Manager. This is clearly evidence that stakeholders outside the IT department should be represented in the Software Development Process. To emphasize this even more, research has shown that 45% of all features implemented are never used at all. Therefore we can’t stress the simple point enough:

The software development process should resemble the business process.

Often this is not the case and the SDP has remained a mere IT asset or, even worse, a pure development instrument that has originated from team or developer preference, theory or vendor promotion. This can seriously hurt business as projects are more likely to fail with an inadequate process, and if they succeed they may be twice as expensive as needed.

(more...)

Filed under: Agile, Articles, General
No Comments