Skip to main content

Posts

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

agile pontypridd

Pontypridd must be just about the strangest town in the universe. Apparently, there are houses there with a very strange geometry, so strange that some of them may even be only possile in a multi-dimensional parallel quantum universe. The proof for this is simple. Whenever you meet someone from Pontypridd, mention Tom Jones, the famous singer. You will immediately get a response along the lines of, "I (or my mum/dad grandmother/grandfather) used to live next door to him (or his mum/dad, etc, etc)" This has led many to believe that PontyPridd consists of a couple of many-sided houses belonging to the Jones clan in the middle of the town with all the other domiciles arranged in a circle around them. Obviously, the number of houses next to these necessary to support the many claims of next-dooredness cannot be satified in the three dimensions of normal space, so we may have to imagine the town exists only partly in normal space and partly in that multi-dimensional parallel quant

agile mandate

XYZ were a digital agency and over the years had done many software projects for their customers with varying degrees of success. After learning that many companies were having great success with Agile processes and noticing that even the UK government had decided to adopt those ways of working, the directors had realised the use of these new techniques would improve the performance of their own company. To that end, they had issued a mandate to the project team that by the end of the financial year, they had to have performed at least one Agile project. By this time next year, all projects needed to be Agile. So it was that Colin, our intrepid consultant, found himself in the office of Richard ‘RJ’ Jones, head of XYZ’s Project Office. RJ had contacted Colin so he could get the training and coaching he needed for his team before they started their pilot Agile project. “Tell me,” said Colin opening the conversation, “how big is your team?” RJ though a bit before responding, “We have a t