Agile Software Process Improvement

Software Architect Required To Start Monday

 

Call me old-fashioned, but when recruiters call me up at 6pm on a Sunday evening desperately looking for an architect who must be available to start work on Monday morning, I can't help feeling that something has gone very badly wrong with our profession.

Agile Design Training Course - Launched Today

 

Seven years in the making and a dozen false-starts later I finally get around to announcing the definitive training workshop on Agile Design.

What took me so long? Well, this workshop is jam-packed full of both Agile fruity goodness and visual modeling vitamins and minerals.

It's the training equivalent of a superfood, which is why it's taken so much work to distill it all down to a 5-day learning experience.

To fit it all, I've had to forego the basics. This is not a course for beginners in OO programming, Agile development or UML. This is a course for the big boys and girls. You've been doing it for while. You've mastered the basics. But now you want to take it to the next level.

It's a course that's all about having your cake and eating it: designing for now, and accomodating the future. It's got up-front OOA/D and Agile Modeling (ALA Scott Ambler) but with a test-driven twist. It's got design principles, code smells and refactoring. It's got code analysis and metrics. It's got business modeling and enterprise architecture, but not as you know it! There's no fancy-pants Big Design Up-Front Model-Driven Wotsisface going on here. It's all good, simple home-cooked Agile Enterprise Architecture.

And then there's the secret ingredient. The techniques I've used to scale up the Agile approach and align business goals with delivered code across multiple projects/systems. I'm not saying any more. You'll have to see it to find out more.

The workshop is designed to take 5 days, and is delivered at the customer's offices. It works like a big coding dojo, so you'll need to bring at least one laptop between two people, with your favorite IDE installed. .NET users will be at a slight advantage, as the code analysis examples I'll be doing will use NDepend and FxCop. But alternatives exist for Java and C++, which we can explore when we're planning your workshop.

To find out more, visit the training page on www.parlezuml.com, or email me with a few details about your needs.

Falling Between The Cracks - When Your Processes Don't Allow You To Adapt

 

A couple of years back, I lost my wallet on the way to an off-site meeting with a client.

I called my credit card company to ask them to cancel my card and send me a replacement. It just so happens at that very moment a replacement card was already on its way to me in the post because I'd been upgraded to a gold card.

They canceled the gold card. And didn't send a replacement card because a replacement card was already on its way.

Somewhere buried in their complex processes is a unique combination of circumstances for which they never planned. A box in the state transition table they forgot to tick, if you like.

And because business is complicated, such operational cul-de-sacs will inevitably catch us out from time to time.

The right thing to do when we get stuck in a box nobody planned for is to improvise a solution and incorporate it into regular operations. We call that learning. You may have heard about it...

The wrong thing to do is to refuse to admit that there's a hole in your processes and leave no room in which to improvise a solution, let alone incorporate that solution into your business in case the situation arises again. That's called not learning. It's very popular these days.

Address The Mindset Rather Than The Decision

 

Oftentimes, our decisions are informed not by logic or reason or evidence but by our state of mind.

If we're feeling depressed then we're likely to approach every decision from the standpoint that failure is imminent.

If we're feeling bloodyminded, we might be more interested in finding fault than in finding ways to move forward.

If we're feeling up-beat, we might not be willing to listen to bad news.

And so on.

Looking back, I wonder how often I was wasting my time dealing with the consequences of these decisions when I should have been focusing on the frame of mind that produced them in the first place.

Trust + Realism - Two Essential Qualities For Successful Project Teams

 

Let's not get all gooey-eyed and touchy-fuzzy about it, but I'm reminded these last few days about the importance of two very different things:

1. Relationships, and
2. Physics

It's all too easy to take interpersonal relationships and how we interact with each other for granted on software projects. It's only when those relationships break down that we realise just how very, very hard it is to make any kind of meaningful progress when there's no trust and no spirit of co-operation. As we work to rebuild trust, we see that the stark contrast between adversarial relationships and genuine partnerships. It's a timely reminder for me to remember to focus on the people and the culture - and especially on how we all interact and get along. In terms of complex systems, we learn that it the relationships between the individual components - and not the components themselves - that tend to define the system's properties.

And on to Physics. Some people just don't get the whole space and time thing. Things take time. People can only be in one place at a time. And so on. 10 days work into 48 hours does not fit. When I watch Doctor Who I tend to suspend my disbelief when 5 million Daleks are sucked through one small window in Docklands in a matter of seconds. In real life, though, we cannot suspend physics. Alas, in very reactive working environments, it's easy for managers to forget that they already asked you to do 3 impossible things before breakfast that would require you to be in two diffrerent places simultaneously. Which is why projects must be grounded in reality.

I maintain that if you can build trust and inspire great working relationships, and if you can ground your plans in reality, you'll go a long away towards succeeding.

Tests Are Instances Of Rules

 

In test-driven development, we use tests as executable specifications of what is required of the software we create.

For this to work effectively, our tests have to convey the underlying intent. And this requires us to ponder the relationship between a test and a specification.

First of all, what is a specification? Well, in simple terms it's just a rule. A rule that the software must obey. For example, it might be a rule that says that we cannot transfer money from one bank account to the same bank account.

We can test this rule by trying to transfer money from Jill's current account with ID 12345678 to Jill's current account with the same ID.


That is not the rule. The rule applies to every account, not just Jill's. That we cannot transfer money from Jill's current account to the same account is an example of the rule in practice. In much the same that 12345678 is an example (or "instance") of a bank account.

The relationship between types of objects and instances of objects is much the same as exists between rules (and therefore specifications) and tests. Test cases are instances of rules.

Just as we can instantiate a bank account with ID of 12345678 and a balance of £50, so too can we instantiate our rule about transferring funds between the same account where the payer is account 12345678 and the payee is also account 12345678.

In this particular instance, we might expect the software to prevent the transfer from being executed. If we instantiated the rule with payer 12345678 and payee 76564534 we might expect a successful transfer to be completed.

In a test-driven approach, we use the instance to illustrate the rule and serve as the specification ("specification by example").

But sometimes examples don't clearly explain what the rule is - especially when rules are subtle and complex. Which is why it is important when writing tests to make it clear where test data has been substituted for rule variables (like payer and payee) and to express test assertions in terms of rule variables wherever possible.

Some advocates of parameterised testing might wish to go further and dynamically substitute test data in multiple scenarios, cleanly separating code that descrfibes the rule from code that instantiates it.

Whatever your TDD approach, I think the important thing to try and achieve is tests that clearly describe the rule, using carefully chosen test data variable names and thoughtfully-worded assertions to ensure the reader "gets it" as far as the underlying intent is concerned.

Minicab Firm Makes Frightening Admission

 

A real-world illustration of the importance of choosing your words carefully...

Software Developers Make Bad Customers

 

It's demonstrably true that software developers - and ex-developers - make the worst customers on software projects.

I think we just find it too difficult to stand back from the details of the solution and focus on communicating the business problem.

The danger for projects is that developers are run ragged addressing trivial technical concerns - like naming conventions or the use of design patterns - while the big fish slip past our nets unnoticed.

Much of the thinking around software design is hearsay and opinion. Should member variables start with m_, or should camelCase be the way to go instead? I think that m_ is redundant, personally, and clutters up your code. But if it's going to take several hours to change hundreds of m_ variable names into camelCase equivalents, i might wisely choose to spend that money on something more important.

Even I - the world's greatest software developer - can be prone to a bit of back seat driving and losing sight of the bigger picture when some interesting technical detail catches my eye. I just can't help myself.

Neither, I suspect, can you. So let's remove ourselves from temptation and leave the business decisions to the business folk, most of whom simpy couln't care less what naming conventions we apply.

(Okay, so lack of customer concern for design quality can lead to even bigger problems, but we can't solve that by becoming the customer ourselves.)

PowerPoint Jockey Required

 

I just loved this advertisement for a senior architect. Here's a clue as to how "hands-on" they expect him or her to be:

You will also have a proven ability to make sound decisions in high pressure environments and possess the ability to think laterally across many resource requests within complex projects. You will have high standards of written and oral communication skills and proven experience of people performance management techniques. You will have experience using resource planning tools such as MS Project and be able to drive Microsoft Office products to high degree of proficiency.

Oh boy. Where do I sign?!

Ever-Decreasing Cycles - Draft Article

 

You can find a draft of an article I'm writing about the trend towards getting feedback about software quality ever faster and more cheaply. The end vision is one regular blog visitors might be familiar with - that of the continuous background tsting and code quality analysis I've spoken about in the past.

My argument is that, just as background compilation has freed our minds from the minutiae of syntactical correctness to allow us to focus on higher matters - like what the code acually does and how easy it will be to change - I foresee a time when continuous background unit testing and static analysis will free our minds from thinking about correctness and internal design quality to allows us to focus on even loftier issues like how easy the software is to use and whether we're delivering the most valuable features.

Well, a man can dream, can't he?