Developing Code, Connecting Industry

I recently read an interesting blog post about why it’s ok not to write unit tests.

I disagree.

However, I believe the topic does deserve a proper rebuttal of some form, and I would like to try my hand.

You can find the full discussion at CodeQuirks.com but I’ve included the most important points here.

Why failing tests create safety.
Until recently I didn’t fully get the meaning of this idea.

The big problem I saw was that failing tests just got altered or deleted. How on earth does deleting or changing a failing test make the refactor easy? Couldn’t you have just refactored without the test?

The answer hit me like an untested jar-file.

When I change a piece of code and 3 tests fail, I can read those tests and know exactly what contracts I had violated. That doesn’t mean my change was wrong, but it does make it very clear what assumptions had previously been made about the system.

This empowers me to go into any areas that used those components, and modify them based on the new contract I am trying to put in place. I now know exactly how my alteration affects other areas of the system.

This article is a summary of my opinions, expressed at CodeQuirks.com

---

One of the most interesting aspects of writing computer software, at least for me, has been the collaborative nature of what we do. I enjoy seeing the various ways in which a team can be organized, or organize itself, and the results of each of them. What makes software development effective, in the end, is an effective team that can deliver quality solutions to their customers in an efficient manner.

That’s why lately I’ve been absolutely fascinated with the affect agile practices have had on my team. The results have been absolutely amazing, but none of them come even close to comparing with the power of self-organization.

Self-organization has been one of the driving factors of the success of our team in the past few months, and I believe one of the most important aspects of our behaviour is our sprint retrospectives.

What does Self-Organization mean?

From Wikipedia:

Self-organization is a process of attraction and repulsion in which the internal organization of a system, normally an open system, increases in complexity without being guided or managed by an outside source. Self-organizing systems typically (but not always) display emergent properties.

…

Self-organization usually relies on four basic ingredients:

1. Positive feedback
2. Negative feedback
3. Balance of exploitation and exploration
4. Multiple interactions

But what does that really mean for a software team?

Well it implies a state of flux and constant change. It also implies that outside forces will eventually affect the team and influence its growth. However, these outside forces are not allowed to guide or manage the growth of the team. The team will, instead, react to the pressures of the outside world and adapt to them in order to operate more effectively. It really is a powerful statement, but how on earth does it work?

Positive Feedback/Negative Feedback

The purpose of a good retrospective is to look back at the previous sprint or iteration, and identify what things contributed to the successes and failures of the team. Often teams will identify many positive driving factors which helped them, as individuals, feel as if they were doing a good job. They will also identify negative factors which slowed them down, or made them feel as if they could have done better.

Balance of Exploration and Exploitation

Identifying what went wrong in a sprint is an excellent starting point, but that knowledge would be of little value if the team didn’t have ideas for how to fix the problems or prevent them from occurring in the future. Perhaps even more importantly, if the team isn’t aware of ways in which it can repeat the positive factors of the sprint, the benefit from them may quickly be lost.

Multiple Interactions

The primary artifacts of a successful retrospective are knowledge and action. The team is empowered with knowledge of what works, and what doesn’t. This way each team member can learn from the experiences of their teammates. The team takes action based on this new knowledge, in order to help become more effective and efficient.

Summary

While I go into a fuller analysis at my blog, I believe it is apparent that the sprint retrospective is one of the biggest keys to self-organization success. It provides many of the key properties a team requires in order to grow and achieve results. I can say from personal experience that the most important part of effective sprints, for me, has been effective retrospectives because they have allowed me to identify key areas for growth and learning. Perhaps one of the most important things you can do as a team, at least as a first effort, is figure out how to make these meetings flow smoothly and provide value effectively.

“I have but one lamp by which my feet are guided, and that is the lamp of experience. I know no way of judging of the future but by the past.” (Edward Gibbon)

Over the past couple of days I realized just how annoying it is to do simple data-lookups on arbitrary XML in Java.

The only two real options we seem to have are configuring XStream or JaxB, which is more hassle than it’s worth for simple data, or parsing the XML and manually traversing the DOM. Neither of these, honestly, seems like a sufficient easy solution to such a common problem.

That’s why I created, and open-sourced, XmlBeanUtils.

XmlBeanUtils is a simple library that allows you to load arbitrary XML into a Bean-like object for quick data access. For a more full description, read the full blog post.

(Please note: Apache Commons BeanUtils are required as a transitive dependency.)

The final post in a 3-part walkthrough for automatically versioning and provisioning features for OSGi deployments. This post discusses how the features.xml file produced by the previous 2 posts can be told to automatically manage version numbers.

The post begins with an explanation of our motivation, discusses a forked modification to an existing Maven plugin which will provide the functionality we require, and finally move into the use of the plugin in the pom.xml.

This post, like the previous posts, is code-heavy with bare descriptions. Questions are very welcome.

(Follow the link for the full blog post)

http://kodequirks.wordpress.com/2010/04/16/auto-provisioning-osgi-features-automatic-versioning/

This is part 2/3 describing how to set up a pom to provision a features.xml for a ServiceMix Deployment, deploy and release the file to Nexus, and automate the handling of version numbers.

The post begins with the simple setup for localized installation. It then moves on to how to get Maven to deploy the artifact to a Nexus repository properly, before explaining the tweaks needed to release to a different repository.

For the XML-phobic, this post is fairly XML-heavy as most of the concepts are self-explanatory.

(Follow the link for the full blog post)

http://kodequirks.wordpress.com/2010/04/01/auto-provisioning-osgi-features-deployment-and-installation/

Recently, during a software project, we decided to deliver an application via OSGi inside a ServiceMix container. In order to do that, we chose to provision a “feature”, allowing the customer to install the entire application through a simple URL.

Doing so raised some interesting problems. How do you deploy a versioned “feature” file to a Nexus repository? And how do you automate the versioning of the bundles contained within it?

Our solution to that problem is the topic for this blog series.

---

Part 1/3 : The Basics

Turning your “features.xml” into a feature template

(Follow the link for the full blog post)

http://kodequirks.wordpress.com/2010/03/29/auto-provisioning-osgi-features-the-basics/