I have a strong dislike for the term "post-agilism" and it will take somewhat more than 140 characters to explain why. Sorry twitter.

Post-agilism is a strawman argument. It postulates that agilism is zealous, doctrinaire and narrow-minded, and then posits that because of these deficiencies we need something that is "post-agilist". Implicit in this is that people who call themselves "agilists" have got it wrong.

This is simply another turn in a vicious circle. The "post-agilists" solution is a restatement of agile principles. Agile didn't start with hype, it didn't start with zealotry. On the contrary, Agile by declaration is adaptive and focussed on getting working software delivered. If you say you're doing agile but you don't believe in these principles then I'm sorry folks, you're just wrong. You probably weren't there at the beginning, and you've been misinformed, quite possibly by people who cherry-picked things out of context. We don't need another revolution, we need help with the swinging pendulum of the current phase.

So for the "post-agilists" out there - change your message. Say "wow, lots of people are doing agile wrong, we need to stop that, let's do agile right". Otherwise in 10 more years we'll have post-post-agilists decrying the shortcomings of how people have interpreted post-agilism (though more likely because of a lack of any structure than from too much).

I purchased a build light for my team at work in November last year and have finally gotten around to putting it in place to monitor my CI server. I wrote a little framework called Lighthouse to manage when and how it turns on.

At about the same time I noticed that Simon Harris also purchased the same build light, but used a different CI server (servers?).

So, all this lead to Lighthouse supporting Hudson, Pulse and Team City.

On behalf of all decent developers everywhere; I'd like to take this opportunity to flip a giant bird at the developers of Team City.

Download Lighthouse.

With sadness and trepidation I need to tell everyone that I plan to leave Cogent Consulting. I appreciate that you're not supposed to leave your own company, but I've rarely let what you're "supposed" to do govern my career. My departure from Cogent will create a hole, but I'm perfectly comfortable that the hole will be quickly filled. Marty Andrews will take over my role as decision-maker-of-last-resort, and I expect that most people, both staff and customers, will notice little difference on how Cogent runs or the quality of the service that it provides.

The decision to leave Cogent isn't an easy one, but sometimes opportunities come up that you simply can't ignore. I'll leave out the details of this particular opportunity since it isn't finalised, but I believe it's in the "can't ignore" category. It's quite possible that it won't turn out as I hope and I'll be back, but I need to find that out for myself. As my lovely wife said, "If you'd never created Cogent, you would have regretted it for the rest of your life. If you don't try this, you'll regret it for the rest of your life." Or as she said to our son, "would you like to have a family adventure this year?".

I'm very proud of what Marty and I have accomplished to date. We're running a company using approaches we were told were unrealistic, that simply wouldn't work, and Cogent's existence is proof to me that they can work. All the books of the company are open to all the employees, we don't put people on gigs they wouldn't choose to do themselves, and we try to make as many decisions as we can as a group. We share our profits in a fairly egalitarian way, and we've done some product development. We don't do any of this perfectly, but our hearts are in the right place. I'm a little more balanced about the pros and cons of these approaches, a little less naive, but I suspect that Rupert would still call me a Trotskyite. I wish I'd started this ten years earlier.

In many senses, as an individual I'm not important to Cogent. It's the principles, values and quality of the staff that separate Cogent from other companies and help us deliver great solutions at great value-for-money. All of these things will survive my departure. Cogent has always been managed by a small group with contributions from throughout the company, and this will continue. The trepidation I mentioned earlier is for myself, rather than for Cogent.

I expect to finish up with Cogent at the end of March, and I'll pass on more details as they become available.

I have a site that lets you create child entities on the create form for the aggregate root. Thanks to accepts_nested_attributes_for this isn't too hard.

accepts_nested_attributes_for :kids, :allow_destroy => true

The problem I hit was mixing this with single table inheritance. When the child node is for a derived class, it saves without the 'type' information being set.

It seems the accepts_nested_attributes only creates new instances of the generic base class entity, which then ignores the value passed to the 'type' field.

I ended up doing this work around to get it to replace #new on the base class with an implementation that returns the correctly typed derived instance when the hash passed includes a 'type' field.

Thanks to Coderrr for posting this work around.

Note: I've backed up the code to http://gist.github.com/273858

• Partially Done Work
  
• Relearning
  
• Hand-offs
  
• Task Switching
  
• Delays
  
• Defects
  
• Extra Features
  

Just in case you're interested :-)

• Feedback over Technical Elegance
  
• Reliability over Feedback
  
• Relationships over Code
  
• Learning over Producing
  

I get asked this a lot, and let me say that I personally don't care very much. I do care whether or not the development process is effective or not, and mostly you know the answer to that before you ask me. But if I needed to form an independent opinion here are some questions that I'd ask you about feedback cycles. The underlying assumption is that a team will almost continually make mistakes (that vary dramatically in size) and that a lot of our practices and processes are about exposing those mistakes as quickly as possible. So how long is it between the these mistakes and the practice/process/activity that will expose that mistake, and how do you make that period smaller? These questions aren't presented in any particular order.

• A feature doesn't add any value


• Our code is unmaintainable


• We have duplicate code (or other quality problems)


• A developer introduces a new defect


• We've broken an existing feature


• What we're building doesn't match what was expected


• A feature is costing too much to be worth implementing


• A feature is unusable


• A feature works in isolation but not when integrated with other features


• The entire project is costing too much


• The project is going to cost too much

In addition, how long from a the time a feature is requested to the time that it hits production?

There are certainly other things that can go wrong with a project, but I think that reducing feedback cycle duration (time between event and feedback on the event) requires applying many agile principles and practices.

Roodi stands for Ruby Object Oriented Design Inferometer. It parses your Ruby code and warns you about design issues you have based on the checks that is has configured.

Changes in 2.1.0:

• Ruby 1.9 compatible.
• New framework support to allow start and end file events.
• Added MissingForeignKeyIndexCheck. Still experimental for now.

http://gemcutter.org/gems/roodi

Here's an email from one of our consultants, and my response (edited for anonymity and to removing the internal cursing!).

---

So, our product manager asked me today whether we could (just) let quality slide for a while, in the interests of getting stuff done faster.

I gibbered and muttered for a bit, and then gave an answer which amounted to "I don't know how to do that". Which is true; having personally experienced the benefits of practices like pairing, automated tests, and refactoring, and having done things that way exclusively for a quite a while, I'm not sure I know HOW to do it the old way.

I'm not sure that the his concern has gone away, though. He describes his experience as "mostly startup-like stuff", throwing stuff together quickly, and potentially throwing in away a few short years later. He's certainly never worked in an agile environment before, and is doubtful about the value of some of our practices.

Any advice?

---

As with most companies with a history of software development, there are people who have been burned by non-agile development, and people who haven't had that experience, and they have very different perceptions.

Here are some principles:

1) The customer is in control of the quality sliders for a project. We (IT, not just Cogent) are a service provider who give advice and recommendations, and then act on the instructions/direction of the business.

2) If the customer asks us to do something we (Cogent) fundamentally disagree with, we tell them that we are not the right group to provide that service and we quietly, respectfully disengage. Think of a surgeon who was told to perform operations without sterilisation, and that someone else would deal with the infection later.

3) There certainly are times when "not doing things the right way" is appropriate. I wrote the first cuts of Cogent Times with no test cases, because I didn't know if it would get any traction (i.e. be useful enough for people to use it). I don't regret it, and I would do it that way again. Now I'm adding test cases incrementally. When Runway was only developed by Simon it didn't have tests either - we demonstrated that this didn't scale. Kent's blog on the Flight of a Startup describes this well.

4) I think it's important to understand timeframes though. I believe that letting (internal) quality slide for a while will get stuff done faster for a few weeks. Other people seem to think that it will let them go faster for months or years. I disagree. Put simply, dropping quality won't get things done faster. We have the courage of our convictions here - we use these practices when we spend our own money on our own applications, when we really, truly, want to go as fast as we can.

5) The impact of lower (internal) quality is exacerbated by:
number of people working on the application
quality of the people working on the application
size of the application
level of understanding of the problem domain
level of change in requirements
flexibility of the technology stack
tolerance for defects in production

If your application is being built in a modern language, by one skilled person who is familiar with the product domain, working with people who know what they want and can describe it in detail without hesitation, false starts or iterations, and no one loses any money (or lives) if there are production defects, then what we do is definitely overkill. I've yet to see an environment that matches this description.

Having said all that, in the bigger picture the product manager isn't necessarily the person who makes the decisions on where the quality sliders are. Those are frequently decisions that need to be made at a higher level as they affect the total life cycle cost of the application, and the product manager is only responsible for the development part. This is the classic breakdown mode of process change - the people who bear the cost of the process change are not the people who reap the benefits of the product change. Producing a stable, defect free application that can be extended isn't necessarily in the product manager's interest, though it may very well be in the company's overall interest, especially when funding is allocated per project rather than per product. I present that argument mostly for completeness, since I think that the payback period of our practices is short enough that they're in the product manager's interest as well.

Things get even worse when the organisation funds work as "projects" rather than investing in "products". In these situations the value of feedback is reduced (since success is judged on the delivery of the promised features) and the focus is on the short term (the delivery phase for those features).

However it's also fair for the customer (and I mean the big-picture customer, not just the product manager) to suggest experiments - a good question in those situations is what will be measured to determine if things are better, and better for who? You need all the stakeholders involved in these discussions, not just the product owners.

Also bear in mind that we are not the only people to say these kinds of things. I believe part of what you're seeing is descent into the "easiest" possible implementation of Scrum. Here's what they're implicitly asking for:

"To be able to change their mind on requirements each iteration, and to obtain the benefits of this flexibility, without either performing enough up-front analysis to understand the fundamentals of the problem domain, or making any investment in the technical robustness of the application to support change"

This is very appealing from a business perspective, but it's an illusion. Jeff Sutherland has said he's never seen a hyper-productive Scrum team that didn't use the XP technical practices. Martin Fowler has written on what he calls Flaccid Scrum. The trend is to no longer consider the practices you mention as "agile", but simply "contemporary" - things you should be doing without a second thought.

So my first response to these kinds of suggestions (actually, my second, after I stop cursing) is that if the proposals would make things go faster then we'd happily implement them. But they won't. If I'm challenged further then I would ask them to find someone else on the technical staff who believe that the proposals will make things go faster, and then I'd step aside for them.

Seriously, hospital administrators don't tell surgeons how to maintain hygiene and where to cut. The customer can do whatever they want - we don't have to do it for them.

Not sure if that helps or not.

Steve

Roodi stands for Ruby Object Oriented Design Inferometer. It parses your Ruby code and warns you about design issues you have based on the checks that is has configured.

Changes in 2.0.1:

• Fixed a bug where roodi.yml was not being loaded. Patch supplied by Rob Mitchell.

http://roodi.rubyforge.org/