Posted by Lars Vonk in the late evening: July 10th, 2008
A new version of Xebia’s open source maven-dashboard-plugin has been released. This version fixed some bugs. A quick guide on how to use the dashboard in your project please read this blogpost.
Keep an eye on this blog or checkout the roadmap in Jira for upcoming releases.
Posted by ShriKant Vashishtha in the late afternoon: May 5th, 2008
As you enter into Agile world, a statement welcomes you – “Just do enough documentation”. For quite sometime, I was puzzled what we really mean by this. In my view “just-enough” is very ambiguous or abstract. You cannot quantify it. For some who are working for a development project, creating documentation may not make much sense as you can find people just across your table to answer your question and you can get away by doing “not just-enough documentation” (no java-docs, no project overview etc). However when you come in maintenance cycle of the project, it just sucks. Maintenance may implicitly means new people, a long project cycle and people who leave the project or even organization itself.
What do you do then? People who were in the project at the beginning may not be there anymore, either from customer side or from software developers side. Without having a knowledge repository, new people will try to reinvent the wheel, will go through the code (white box, which ideally should be a black box most of the times) or will look like people who enter in a dark tunnel without having clue on what they are supposed to do.
Posted by Jeroen van Erp in the wee hours: March 27th, 2008
Quality is an everyday part of the life of a Xebia software developer. One of the ways to get insight into quality is by looking at metrics like FindBugs, PMD, Simian, Code Coverage, etc. With large software products consisting of different modules, quality assurance can become quite a trying task. This means that tools which alleviate this burden are a welcome addition to our toolbox.
(more…)
Posted by Erwin Bolwidt in the late afternoon: January 18th, 2008
Many courses and books on requirements will tell you that a good requirement describes the “what” of a need of a customer (or more generally, stakeholder). They will tell you that you shouldn’t write down the “how” (they call that ‘design’) because it pushes you in a technical direction and causes you to miss out on other good solutions.
That’s good advice in the sense that you shouldn’t restrict yourself to a solution if another solution satisfies the needs of a customer better. But when is something a design, and when is it a requirement? If you’ve thought about it, you realized that it is hard to draw the line. (more…)
Posted by Erik Pragt in the wee hours: January 9th, 2008
XKE
Tonight, we organized our biweekly XKE (Xebia Knowledge Exchange), which is a forum where we update each other on interesting developments or have discussions on various topics.
One of the topics of tonight was: “what keeps us programming in Java”? The underlying thought about it was: what prevents us from programming in a different language, especially a dynamic language like Ruby on Groovy. Because I’m a little more into Groovy than I am into Ruby, I’ll talk the rest of the blog about Groovy, but you can probably exchange it for any (dynamic) language.
One of the key factors (and this might sound like an open door) to stick to programming in Java is that we are all very familiar with the language. We have invested time learning it, we know the frameworks, and we have real experience that it works. Furthermore, people know how to manage a Java application, know how to deploy it on an application server, and as an added bonus, IDE’s support Java really well.
(more…)
Posted by Vikas Hazrati in the early evening: December 9th, 2007
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…)
Posted by Gerard Janssen in the early morning: July 18th, 2007
Quality assurance is too often used to just identify a lack of quality and to find deviations from the norm. This is logical in organizational cultures where responsibility is something to be managed carefully. However, wouldn’t it be better if QA would be supportive towards an overall strategic goal of improving quality? For this you need a sense of shared responsibility across the organization and its processes. Then QA can work to start improving quality by improving processes, procedures and practices, making sure to prevent problems instead of identifying them. Taking responsibility instead of shifting it. That’s proactive QA.
(more…)