Skip to main content

Posts

eyes wide shut

As a youngster one of my favourite authors was the American humorist, James Thurber. Of all the pieces of his I read, the one that I remember most concerned his English teacher′s obsession with the use of "the container for the thing contained" as a figure of speech. For example, we might say, "Today London elected a new mayor." Of course, London would do no such thing, it is an inanimate city of roads, parks and buildings and roads parks and buildings have not yet been given the vote. It is the people of London that elect mayors but the use of the container for the thing contained is a common trait with humans and everyone understands it. Another similar manifestation of this type of behavioural trait concerns certification. We imagine that the owner of a certificate possesses not just the knowledge originally required to gain the certificate but also the talent and skill to use that knowledge effectively. The fact that a standard exists also implies that the stand

lazy agile developers

..said my colleague. "How so?" I enquired. "Well!" he said, "when we do planning, I notice that one or two of the guys are always happy to suggest we only ever attempt to match our previous velocity, they never try to improve. If anyone suggests we aim for more points than we achieved before, they are quick to shoot them down. If that's not laziness, I don't know what is?" "OK" I replied, "if we set aside the issues of point inflation and the like for the moment, I still don't see how Agile has made anyone lazy? If it's true that these individuals are, indeed, lazy, then what Agile has done is simply made this visible. I would guess that they were always lazy, it's just that nobody really knew before because work and the effort required to complete it were hidden. It's only now that we've introduced transparent methods that these issues have become apparent." That is if, and only if, they really are lazy. My

the death of tdd

Several years ago, Colin had the pleasure of working with Mike and his team as they embarked on their Agile journey. As with many teams, they went through stages of what might be termed maturity. First, they learned how to plan and work iteratively, later they learned incremental working. Finally, they reached a point where they wanted to improve their engineering practices and so Colin had introduced them to Test-Driven Development. Now he was sitting listening to Mike, the technical team lead for the team, explain to him why TDD wasn’t working for them. "You see, TDD forces you to decouple everything” he said, “You taught us the SOLID principles, JSP and the Composed Method pattern?” He looked down into his cappuccino, “you introduced us to clean code, too. We’ve followed the rules in the book to the letter and now we’ve found it’s just too difficult to write code.” I was curious about his statement, “What do you mean it’s too difficult?” I asked. Mike was hesitant at first but

cross-functional

“RJ,” said Willy, the CEO, putting his arm around RJ’s shoulders, “we made you CTO because you said you could deliver. Foofle have launched a cloud product and it looks like we’ll lose our market share to them. We can’t wait a year, what’s the earliest we can launch Project Synergy? Change the team if they can’t deliver!” Richard Jones (known as RJ to everyone except his mum) went back to his office to think about the situation. Willy was right; he was promoted because he promised to deliver Project Synergy within a year. Unfortunately, things weren’t going well. He had skilled engineers and he’d planned everything thoroughly but things weren’t working out. His DBA, Donald, had broken his leg snowboarding and couldn’t produce Synergy’s schemas, tables and queries. The middle-tier team were working on defects while waiting for Donald to recover. The UI team were finished with Synergy and had moved on but their team lead was worried about rework. He wouldn’t stay CTO for long at this rat

planetary system

Until 1781, humans had believed there to be only six planets (including Earth) in the solar system. Although many eminent astronomers had previously spotted the planet Uranus, they had always presumed it to be just another star and listed it as such. In March 1781, William Herschel made a series of parallax observations through his telescope and believed he had discovered a comet. On 26th April that year, he reported his find. Only after feedback on his report from the Astronomer Royal and independent confirmation from European astronomers, did he finally concede he had discovered a new planet. After some discussion, Berlin astronomer, Johann Elert Bode, named the planet Uranus. Herschel brought the number of planets in the solar system to seven. Later, Alex Bouvard noticed some unexpected perturbations in Uranus’s orbit and predicted the existence of yet another planet. Johann Galle visually confirmed Neptune’s presence in September 1846 and brought the number of planets to eight. No,

stakeholder value

Willy the CEO slammed down his mobile after another ear bashing from his biggest investor. He took a breath, dialled the newly appointed CTO and explained the situation. “We’re in the last chance saloon, RJ. The board have given us six months to fix what we’re delivering from Engineering. We need to prove our value and fast!” Willy sighed and continued, “They’re pushing me to consider outsourcing everything.” Sitting in his office, RJ took a deep breath and thought about his team’s performance, “My teams are solid. We deliver on time and we deliver high quality, well-tested code but still the stakeholders complain about the product. What’s going wrong?” He reached for the phone and called Colin, the coach. Sitting in RJ’s office some days later, Colin explained to RJ about stakeholder value, “Stakeholders sponsor a product because they believe it will give them benefit or value, if you like. Your teams need to focus on delivering this value to the stakeholders.” “I thought we were doin

non-functional code

...is what I immediately think of when I′m asked to work with ′non-functional requirements.′ If that′s what they want, I am only too willing and definitely more than capable of satisfying the request and have proved this many times in the past. Seriously, though, the way we are presented with these so-called non-functional requirements is amazing, as is the range of them. One of the most common ones is, ″It must be fast!″ Well what does that mean? Programmers are sometimes accused of being pedantic and selfish about what functionality they will let you have from a system but the other side of the coin is the miserly customer, the one who is unable, or refuses, to explain the true extent of the requirement. Fast is a relative term. We need to ask the customer, ″How will we know when it is fast enough?″ In other words, we need to quantify it so we can write a test for it. Tests are how we know that we′ve completed the task and can go on to the next one, or go home. Only when the tests ar