Why I love working in an Extreme Programming Environment

A lot has been said about how Extreme Programming is great, how it produces better and more flexible software, fosters a positive development environment, increases productivity, agility, code quality and so on and so forth.

Well, this post is about none of that. I just want to share some personal (and probably highly subjective) reasons why I have really enjoyed working in XP environment. My focus is more on the person (the developer) as opposed to the final product although the two often go hand in hand – I am yet to meet a developer who takes pride in producing crappy software. Really, I haven’t.

I have been working for an XP shop for a bit more than 2 years now, and the comparison that I am drawing is against a past life of working for a large multinational software vendor with an R&D team well into the thousands. It has been quite the contrast let me tell you that!

Here are some of the reasons why I love working in an XP environment:

  • You learn a lot. By pairing all the time, you learn from fellow developers. By having collective code ownership you get experience with all parts of the code and all across the technology stack of the product that your company is making. By having a process that strives to stay close to the requirements and end-users, you learn about the overall business. With XP it is easier to get the big picture.
  • You accomplish a lot. XP makes a point of being very development centric. It’s goal is to produce quality, agile software that meets real business needs and does so with the least amount of overhead. On any given day all the energies of the XP team are focused on producing software – you are either designing it, coding it, writing test for it, or gleaning the requirements for it. There is no room for anything else – XP is by definition very light on process. For a developer this means no torturous interminable meetings with dozens of people in attendance, no endless emails with 50+ people in the cc line to flood your inbox, and (my personal favourite) little to no room for politics. At the end of the day this laser-like focus on producing software lets developers just do that – and walk out of the office with a sense of accomplishment every day. Compared to my old job, I get way more done, and it feels great.
  • You have a say of where things are going. Communication and the courage to change course are key values in XP that make it easier to get involved, take the initiative or in general have an opportunity to positively influence the direction of where things are heading. Contrast that to a more “traditional” development environment where developers have narrow and clearly defined areas of responsibility, be it a certain module, part of the product or a project that goes on for months even years at a time.
  • Time to have a life outside of work. A 40-hour week is an inviolable part of the tenets of Extreme Programming (although minor exceptions apply, such as in the case of critical pre-release crunches). With the free time you can pick up hobbies, spend time with friends and family, read, start a micro ISV on the side, etc. Ironically I find myself spending a fair amount of my spare time catching up on new languages, development tools, trends and paradigms. Geeks will be geeks, I guess đŸ™‚

Calling a stateful Web Service with JBossWS

Although Web Services are usually described as stateless and involving distributed applications exchanging one-off messages here and there, stateful web services are not that uncommon. I recently spent some time trying to invoke a stateful .Net service from JBoss (using JBossWS) and I thought I’d post the code for that here.

The .Net service required login before further methods on it are invoked. This scenario is probably quite common out there as more and more 3rd party server-side components that require authentication get exposed as web services. A web service can be made stateful by using the SOAP header to stuff state information or by setting cookies in the HTTP session. The web service I was invoking used cookies, so I will talk about that here.

The following enables cookie support on the the web service client side:

Service service = Service.create(wsdlURL, serviceQName);
ServiceInterface proxy = (ServiceInterface)service.getPort(ServiceInterface.class);
((BindingProvider)proxy).getRequestContext().put( BindingProvider.SESSION_MAINTAIN_PROPERTY, true);

However, doing this in itself IS NOT ENOUGH! Because of a bug in JBossWS, only versions of JBossWS 2.0.1 and newer have the above working correctly. JBossWS 2.0.1 was released fairly recently – the release date is listed as 17 Aug 2007. JBossWS comes with JBoss, however it is only since JBoss 4.2.2 GA that JBossWS 2.0.1 is included (older versions of JBoss have JBossWS 1.x instead).

Basically to make the above work you will need the latest versions of JBossWS or JBoss (as of the time of this writing) because versions from as recently as a few months ago won’t work.

Links of the day

  1. A Guide to Hiring programmers: The High Cost Of Low Quality. This revsys blog post talks about why hiring good programmers is well worth it and gives some tips on attracting and keeping top developer talent.
  2. Desktop Applications are Dead. Eugueny Kontsevoy’s incredibly entertaining rant on why Microsoft and Vista put the last nail in the coffin of the desktop app as we know it.
  3. Java: One Platform to Rule Them All? Michael Urban starts a good discussion on the standardization of various tools and languages on the Java platform. Check out the responses, they are very enlightening as well.

How Bad Is Your Architecture? Measure it the Agile Way!

It happens to developers all the time. After working on some piece of code for a while, they discover how truly inflexible, counter-intuitive and generally not helpful its architecture really is. Only miracles and truly brilliant developer insight is capable of making new features happen, and just barely so. Fixing bugs feels like a whack-a-mole, and only wonder-coder Joe who has been with the company for 6 years knows how things really work down there.

But then management is not always excited to pursue larger architectural overhauls just because developers say so. Hey, that piece of code has been working just fine over the last 8 years, so why touch it now? And anyways, why on earth should we be spending time on something old that delivers no visible value instead of working on all these new features that we promised to deliver to our customers??

If re-architecting that piece of code requires well above the regular 2-3 day refactoring job and would likely go on for weeks, a developer may need arguments that go beyond the “but it would be so much nicer if…” to convince everyone that more work needs to be invested there.

For the remainder of this post I want to present a practical way of measuring the drag factor of suboptimal architecture. We recently came up with it in my company and are in the process of making it work for us. The focus is on larger architectural issues, usually ones that a routine refactoring is not enough to fix. Although the discussion is in the context of Extreme Programming, it can easily be extended to non-agile environments given the right team dynamics.

The main idea is fairly simple. Upon completion of every story in the XP iteration, an estimate is given to reflect how much the story was “slowed down” by the presence of “bad” or suboptimal architecture. We call this the Legacy Architecture Cost (LAC). If more than one component or area of the product is suspect of needing re-architecting, the LAC is broken down by area/component. After a certain period of time, say 6 months, the LAC total for each component or area is added and analyzed on a Return on Investment (ROI) basis.

For example, if it turns out that over 6 months the team has spent 20 man days because of the suboptimal design of some crusty component that would have taken 10 days to re-architect, that component is an obvious candidate for redesign. However, if the LAC for another component is 5 days and it would have taken more than a month to fix, maybe we shouldn’t roll up our sleeves just yet.

A natural priority list then emerges. Components with the highest ratio of LAC to estimated fix time percolate to the top of the list of thnigs that need to be re-architected first. Of course, the usefulness of the priority list depends on the length of the LAC collection period as well as on how statistically representative it is of the overall software development activity in the team.

Just blindly using the LAC ratio would probably be over-zealous too. Other things can influence the decision of what components to re-architect first, such as current priorities as well as expectation of upcoming work (e.g. are the next few months going to be mostly backend work?).

The idea is to give some empirical and objective value to the drag factor of suboptimal architecture and move the re-design discussion into less subjective territory.

  1. What if the estimate for the fix cost is not known? Well, if it is not known how to fix the design of the component, how can you know for sure that the current design is not actually the optimal one? You just can’t be sure. So unless there is a strategy that has a reasonable assurance of producing a better design, developers shouldn’t be griping about how bad the component is! To get a better estimate of the fix cost, a special research story can be added to an iteration, or a spike can be done to produce a quick proof of concept.
  2. The LAC numbers are too subjective. The idea behind measuring LAC is to produce a rough ROI argument in favor of re-design. Does it really matter if the team spent 31 days instead of 30 being held down by a component that would have taken 10 days to fix? Probably not. A high level of precision may not be needed at the end of the day.
  3. Developers may inflate LAC numbers. Developers usually like building and rebuilding stuff, so they may have a conscious or subconscious inclination to up the numbers and make the case for a re-design look more compelling. This could be a bit of a problem, although it may not be that big of an issue if the relationship between developers and management is a healthy one.

I will make more posts as we continue to use this technique. This is all work in progress for us, so any feedback or tips are highly appreciated!

Related links:

  •  Measuring the cost of suboptimal architecture is closely related to the concept of Technical Debt that Martin Fowler describes and talks about on his bliki.
  • Johanna Rothman gives an interesting approach to paying off testing technical debt in this article.
  • Technical Debt and the Death of Design, Part 1. An excellent article by Kane Mar further describing the nature of technical debt.

Why Certification was useful for me

The topic of developer certification has stirred a lot of debate recently. Is it good, is it bad, is it just downright evil? Raganwald recently jumped ship on the certification debate with his Certification? Bring it On!. An excellent rebuttal over at Enfranchised Mind was quick to follow and made some excellent points as well.

But I as a developer found certification useful for reasons somewhat different than what these guys are talking about. Certification worked well for me because going through the actual process (I did the Sun Certified Java Programmer about a year ago) made me brush up on areas of the Java platform that, for one reason or another, I hadn’t had much exposure to in my professional life up until that point.

The companies that I have worked for in the past few years are pretty established and by the time I joined them, certain parts of their code base like handling times, formatting dates, threading or doing I/O etc. were pretty mature, stable and bug-free and had been so for a long time. Not much work was needed there. So after a couple of years of Java development out in the industry I found myself not completely satisfied with my knowledge in some of those areas.

Going through the certification process not only gave me a structured and focused way of covering areas that my professional experience didn’t touch on or just touched on fairly lightly. It was also a good segway (or an excuse for a segway) into digging out more information on some of the topics that the certification book just mentioned but didn’t elaborate to the extent that I would have liked.

Was there sufficient material on these topics in the SCJP to achieve what I personally would consider reasonable proficiency? Sometimes yes, sometimes not. Certain topics like generics are covered in a much more enlightened way in articles like Gilad Braha’s Generics in the Java Programming Language than they are treated in the SCJP. But hey, the certification curriculum was a good starting point.

Now, is getting certified the only way to brush up those “dusty corners”? Absolutely not. Developers can achieve the same result in a myriad of other ways without having to pay the $200 for taking the exam (shame on you Sun for upping the fees again!). Do an interesting project on the side, launch a cool site or just regularly scan the various posts on dzone. There is plenty of good stuff out there to keep you well-informed and your skill set current.

Certification is just something that worked for me. And if you are a junior to intermediate developer, it may work for you for the same reasons, especially if you work in larger company where the projects last for many months and responsibilities usually cover a small part of the end product and require skills that mostly fall in a narrow subset of the languages/technologies used.