I was sat with my colleague Alex Vandenberg today, and I spotted a “book” to his side. I call it a book, but it wasnt really. Reality is, when I went to lift the book off the table, I actually slipped a disc. In fact, on my second attempt, sweat pouring, blood vessels almost ready to burst, I did manage to lift the book using the classic clean and jerk, and what a jerk a felt when I slipped my other disc.
In 2004 I started writing an article related to some musings on the effects I was seeing from the agile development practices. I eventually got the article finished in 2005. However, even today I am hearing from different companies the noises that inspired me to write my article in the first place, so it seems as relevant today as it was back in 2004. I also have an internet friend that seems to have lots of spare time, so hopefully he’ll like this. Here it is.
As the sun sets on our current iteration, I will sleep tonight feeling a lot of joy for the team about what will come tomorrow. Like most things in life, projects experience peaks and troughs, and three iterations ago it seemed we were headed south, and we had to stick together to ride it. The nature of the downward trajectory was the best-willed intention to break some work into technical stories, rather than sticking to user stories. Part of the team wanted to try technical stories, part of the team didn’t. Regardless, being one team, we all stuck together and worked very hard to deliver them. But we didn’t deliver; the stories beat us. Three iterations on we have nearly completed the work, and it seems we have seen the worst of the issues that arose due to the nature of these technical stories.
When I started to snowboard, I spent most of my time on the easy green slopes, sliding on my bottom or gliding with grace, on my chest. I found it difficult to get going, very painful when learning on pack-ice, and somewhat embarrassing at times. I started off learning at the bottom of the slopes, in the nursery section, because having never skied before, it would have been a little foolish to go up the mountain without learning the basics of standing up, edging the board and turning. I often got frustrated with my progress, and would attempt to start further up the mountain, or when coming down the slope and I was picking up speed, I’d get a bit excited and go with the rush, only to wipe out badly after getting ahead of myself.
Heres a question : imagine you are a team manager, and every day you observe your team from afar. You notice that you can always rely on your team working hard at their computers; everybody is always sat around a computer coding.
Is this good?
Today I have had an interesting discussion with a colleague, reflecting on the people side of software development. Reminiscing over past project engagements, I was reminded of the respectful belief that it is important to see that every team member is doing the very best that they can, even if it seems like thats not helpful or constructive.
I’ve been thinking about simple design recently, toying with various subjective opinions, struggling a little with my own appreciation when dutifully challenged. You Aint Gunna Need It (YAGNI), Once and Only Once (OAOO), and Simple Design are all principles on how to craft agile software. YAGNI is about slamming a lightening rod into the ground of the present moment, to remind us that second guessing what might come, may indeed never come – why waste time and money on it now? OOAO is about handling various forms of duplication, stating that we should diligently remove duplication simply because it’s a serious risk to the quality of an ever changing system. And Simple Design is all about keeping a software design as simple as possible at all times, yet unfortunately, there is no greater oxymoron than Simple Design.
A recent internal conversation started relating to the infamous Good Agile Bad Agile article by Steve Yegge. We decided to share it, so here it is (part of it at least).
Bruce,
Great post. I read somewhere that a company had 99 lever arch files full of documentation so that they could be assessed and accredited by an external CMM auditor. CMMI is an acceptance by SEI that maybe its a bit too heavy weight for practical use; though many have moved up the levels of CMM with success. But agile is a bit more than iterative, as iterative is still around today in the forms of RUP and other BDUF methodologies that accept the canonical waterfall dictum is not practical. Iterative to me is a step towards realising that maybe the problems we are trying to solve are too big for us, and that embracing divide and conquer might be more wise; a positive realisation. Agile however embraces something different (to me), and that is Rittel’s notion of the wicked problem, that software is not only very complex, but also that by trying to solve some of the problem, we can learn more about what it is we are trying to solve in the first place – this new knowledge being feedback into understanding again what the problem really is. Of course, there is much more to the agile movement than just problem definition, but its still no use building for the wrong problem.
A couple of weeks ago I was sitting in Starbucks, as I sit now writing this, and I overheard two guys talking about agile development. Normally there’s not much going on when I’m sat here and I can easily enter flow and zone out. Sometimes I’m not so lucky and there’s distraction after distraction – sit long enough and you’ll play your anonymous role in illicit rendezvous’, marriage break-ups, and foreign lovers-by-penpal meeting up for the very first time (at Starbucks). So it was a welcome surprise to be sitting close enough to a conversation I have a deep interest in…
Nobody likes bugs…Dez has had a tough month – its just about to get worse. Theres been a problem for over a week with creating the release candidate, and the guys who are focused on it don’t look to be close to fixing the integration problems – the boss is on fire because he runs a tight ship, and failure is not a word he understands. Just as the clock turns 9:34 and Dez realizes his third cup of coffee is empty, the phone rings – it’s the boss. The boss is angry because the release candidate is not doing his reputation any good and his bonus relies on the fact he promised this release would not only be complete, but he would bring the defect list down by at least 70 from 290 to 220. Furthermore, it looks like theres been a log created about performance, and its in Dez’s area, so its clearly his fault.
Some say that perfection does not exist. Others say that it is only in the garden of perfection that true excellence grows. What is true is that perfection is subjective at best, and better the person will be who searches for it, if she understands what such a goal will do for her. Striving for perfection in any discipline will require energy and dedication, and it must be tempered with a sense of realism and a courageous heart, for there will be times when pain is all there will be, for perfection and pain dance along the pathways to the halls of fame. Nonetheless it is possible that any rookie, endowed with the right attitude and frame of mind, can make the slow but sure progress towards mastery in their field.
Prefactoring is the name given to a book written by Ken Pugh, and it is a book that has generated a lot of controversy, partly because of the title (of all things). It seems a shame people have been side-tracked, almost as if they feel they’ve been duped into buying the book. My thoughts on this are short.
For most people on most teams, the level of quality expected of them is second to none. Sometimes even though a person is on a team, that person is solely responsible for her own quality, and should she slip, other members are so engrossed in not slipping themselves, there’s nobody there to catch her. For me this is not a team I would enjoy, because to me this does not capture the essence of true team work.
A few days ago a colleague was investigating the performance impact between using virtual and non-virtual methods in C#. As part of the experiment a subclass defined a method previously defined as virtual in the parent class, using the new modifier:
This week has been a really good week as a new start in Lab49 because I’ve been able to do what I love – write code and study. But the early mornings (pre-6am) to get into London have certainly taken their toll having spent the past month enjoying a well deserved rest at home relaxing. Yesterday while on the train home, mother nature embraced my sleepy head, and I fell asleep. I eventually came too and I was at first surprised as the world seemed to be at a 45 degree angle. Still a little groggy I rubbed my eyes and quickly realised I was using my fellow passenger’s arm as a pillow. A little embarrassed I hurriedly apologised and delicately removed the dribble from his expensive looking suit before I caught a glimpse of the rolling vista – super I thought, I was just passing Slough, two stops before my stop; I’d been asleep for about 25 minutes. I felt amazing, so I took out a book from my bag and started reading. When my stop came I considered again apologising for the suit damages, but the look of disgust from my train journey buddy suggested it was perhaps best just to leave…Later lastnight as I explained to my wife how I had fallen asleep on a fellow commuter on the train home, a realisation popped into my head about a book I read some time ago about peak performance…
