April 25, 2010

How fast is TDD exactly?

This is a true story, but for the sake of protecting some people, all the names and other details have been skipped or changed.

It starts on some Thursday with some new guy asking me “how much TDD is slowing down the programmer”? I don't have to think twice, my instant answer is: “programming with TDD is faster than programming without”. The guy doesn't believe me, some other SQL guy joins, doubting as well. I see no point in explaining it to people who don't touch OO code. They won't believe anyway, as it is counter-intuitive, if you have not experienced it yourself. But then, life has a funny way of giving you proofs right when you need them.

Next day I'm being asked to help put out some fire. There was a project running, two junior programmers were writing a small application, one of them doing the frontend, one doing the backend. No help from any senior or architect along the way. No code reviews, no pair programming, no nothing. Things, as expected, went terribly wrong, deadlines are weeks behind, the client is furious, and the software is not doing the stuff it's supposed to. Oh, and the backend programmer is already on the way to another continent. Some guys tried to debug the problem, but after six hours of getting nowhere, they gave up. A classic FUBAR example.

All right, I say. I know the frontend programmer, he's a good guy, I like doing pair programming with him. He doesn't know much about the other guy's code, but he knows the business domain. I'll help as much as I can. So we checks out the code, we setup the IDE and look inside the backend.

And the abbys looks back into us.

We stare into the Eye of Terror. A complete chaos, infested with chaos spawns. A terrible place to look at. Things can break your mind in here. It's twisted, it's evil and it's tragic. Pretty much every principle of OOP is violated. I could give it as an example of things that should not be, except I'd hurt the audience. There are no tests, there is a lot of faulty inheritance, with abstracts knowing about the children, there are hundreds of 'ifs', 'elses' and even some 'case-switches'. Hell, there are even misleading comments! There is a 'new' keyword in every constructor, no IoC, no interfaces, no nothing. No sane mind can leave this place intact.

We take a deep breath, and we try to find out where the problem might exactly be, but as we dig into this Big Ball of Mud, we realize that the problem we are facing is just a tip of an iceberg. The software does not guarantee anything, and as far as we can tell, there is a shitload of bugs all around the place. The main algorithm is so twisted that it takes us hours to understand it, while the purpose of the whole thing is dead simple.

Ok, so we've nailed down the possible problem. I'm suggesting writing a test to repeat the bug client had reported, and then fixing it, but the problem is, that the code, the way it is now, can only be tested end-to-end, so we have a lot of setup to do. My fellow programmer's mind is already burned out, he asks me to call it a day. He also says, that he'd rather rewrite the whole module instead of digging any further, because if he has to look again into this mess, he will never be normal again.

All right. I'm a bit more resistant, but I've not exhausted myself with debugging it before, and I've seen things, you people “wouldn't want to believe”.

So we set up an emergency pair programming session on Saturday. Now it's late Friday, and I'm heading for two parties I've planned to visit that night.

Saturday, 1pm. Sun is shining, weather is beautiful, girls are dancing in the middle of the town. I'm heading for the meeting. I'm expecting some heavy code crunching today, killing chaos monsters and stuff, but when I get there, the other guy says he couldn't sleep. Knowing the main purpose and the twisted algorithms, he has been working till 4am, writing everything from the scratch. Maybe not everything, but the main stuff anyway. He's been doing TDD, and though he has lost some benefits of discovering optimal interfaces/architecture, because he's been writing interface-first, then Red-Green-Refactor style, he got it quite well.

The code is doing about 80% of what it's supposed to do, test coverage is sky-high  (except for DTOs), there are some minor issues with ubiquitous language and so on, but for a single person junior programming this is a pretty sweet piece of code.

“Great job” I say, amazed by his late-night work. What should we do now?

So I help him write an acceptance test. We make it run all clean and green. We talk about the decisions he has made, I'm giving him advices and suggestions, but I can clearly see, that the guy has defeated an ugly dragon last night. He took his TDD spear, stormed the whole army of enemy warriors, killed them all and now he's on his way for the princess. Well done man, If I had a medal with me, I'd give it to you right now. You deserve a big thanks from all of the humanity for putting the beast down.

And he's saying, that if he ever had doubts about TDD, he doesn't have any now. He has really learned something that night, he gained a lot of experience points, and he has leveled up at least two times.

There is still some work to be done, but it's easy from now on. The client is safe and sound.

And now for the conclusion: it took him LESS time to rewrite the whole module, using TDD, that it took, to find one bug in the old application.

How's that for an answer?

PS: pictures are from www.studiocombo.pl

April 15, 2010

Mentoring in Software Craftsmanship

Maria Diaconu and  Alexandru Bolboaca are both strong supporters of Software Craftsmanship and Agile movements in Romania, with years of experience as developers, leaders, architects, managers and instructors. On their lecture at Agile Central Europe Conference they were talking about Software  Craftsmanship movement. While Sobótka at 4Developers was showing what Craftsmanship from the code point of view is, our guests from Romania gave us a brief introduction into the process of becoming a Craftsman.

The fact, that university education for programmers doesn't give us skills suitable for professional environment is old news (at least in Poland and Romania). While steps are being taken in the right direction, it's going to take a while to get there, and that's where  Software Craftsmanship movement comes in handy.

The core concept of the presentation, was that if you want to go pro, you should understand the way you need to follow. In other crafts, there are practices recognized as the core of a profession. Programming is so vast, that you may get lost on the way, and certifications like SCP do not help much, as they are too technology oriented, looking more like a “technological masturbation” (technology for itself) rather than a way to really learn something useful. Software craftsmanship has a concept of mentoring, which is based on one of Agile  principles: “individuals and interactions over processes and tools”.

How does it work in practice? To become a craftsman you start as an apprentice at some master of your choice. If you're lucky, you'll find someone to work for and learn from. If not (you have to work in a bad environment to get by, or everyone around doesn't have more experience than you do), you can choose a well known writer, such as Martin Fowler or Robert C. Marting (Clean Code is a great start) and learn from him (all of them, even better). But that's not enough. Next step would be to participate in the community (local language user groups, etc.) and finally, to get your ass to other places and learn from people out there. That means conferences, but also a week-out pair programming in another company, far, far away, an idea more and more popular in US, as you can see at software_craftsmanship google group. After all a journeyman has a “journey” part in it, doesn't it?

So easy so far, right? Nothing new and mind-shaking?

The thing is to understand, that while official certifications are a great magnet for potential employers, skills of a good programmer don't come from certification books. Skills come from work experience with other good programmers. That's why Pair Programming is so important. That's why you should start going for local language/craftsmanship group meetings even if you do not understand everything they are talking about. That's why it's more important to work WITH a great programmer than to work FOR a well known company.

I've seen so many people understating the technology to the ground, yet failing to create a good software solution,  because they've never ever seen, how a good solution is build. I've heard opinions that “no software is maintainable” from people with 10+ years of experience in Java.

All you really need is a mentor. A master, that can show you, what a great software is written like.

Sławomir Sobótka, answering the question “How to start with Java” on Jacek Laskowski's blog, wrote lately: “I'd leave SCJP and similar sadomasochisms for later, maybe in a few years time, or even better, I'd boycott it all together”. He is damn right.

Robert C. Martin has a very interesting entry on his blog “Developer Certification WTF?”, where he is explaining why  official certification programs are so much bullshit these days. Beware of big companies as well, remember that “big and successful company” doesn't mean “a good place to get better”. On the contrary, it sometimes means: “a place where an apprentice is treated like shit and a code monkey”. Check the company for people and methods that you're going to be involved with on daily basis, before you send your CV. Ask a lot of questions, talk to the guys working there, if you can, ask to spend some time with the team, do some pair programming, and see what they are up to.

While chances are, in most companies your CV is going to be processed forward basing on buzzwords and certificates, the most important thing is to check whether the people you are going to work with can inspire you, bring you to the next level. And vice-versa. This is exactly what Thoughtworks is doing. Don't be afraid to risk you stability and position to get more knowledge and experience. If you've been playing Heroes of Might and Magic, you probably know damn well, that to choose experience is better than to choose money in the long run. Always.

If you want more tips what to look for when searching for a good employer, have a look here.

Mentoring should not to be underestimated. When Piotr Jagielski began his speech about refactoring test code, at Agile Central Europe Conference, he started with saying that he was very lucky to get a great mentor at the very beginning of his work. I'm sharing similar experience: while I've started my carrier as an analyst in a long waterfallish kind of a project, when I've moved into programming I was extremely lucky to work with Piotr Szarwas, the guy who in one year taught me more than 5 years of university and two years of former software experience all together.

And if you already are a good programmer, remember that learning never stops. When you are a master, you are a student as well.

“Even today, I dare not say that I have reached a state of achievement. I'm still learning, for learning is boundless.“ [Bruce Lee, Tao of Jeet Kune Do]

April 14, 2010

ACE Conference: Reachel Davies – Retrospectives

Reachel Davies, author of “Agile Coaching”, with ten years of experience in XP, Scrum and Agile (seven on the board of directors of the Agile Alliance), and 19 overall in IT, is a serious girl in this industry. Funny, I'd think she has some psychology background, but no, she's an engineer to the core. I'd think that because her presentation made so many points on the psychological part of our line of work, that my sister (who is a psychologist as well as a jazz singer) may be interested.

Her talk was about the underestimated art of retrospectives in our agile methods. Teams tend to forget about it or do it a wrong way, while it's the main thing that can help them get better.

She suggested another technique for retrospectives, to create a constant time-line where the team would put their sticky notes, writing:
  • what happened
  • what was frustrating / stressful
  • what was useful / fun
That can give you a very interesting insight in what was happening during the project. She also pointed out that people's moods take a big part in the efficiency of the team, and to have a valid historical view, you should include them as well (like biorhythms). To get that, anything would be good, from putting your spirit level on a scale, up to drawing a picture. Back to kindergarten anyone?.

That may seem silly, but the team is the most important part of the project, and as such, we need to pay attention to everything that happens within. For example, while voting on things to change during a retrospective can help, we should beware of serious disagreements. There are things, like personal values, that you cannot change with a simple statement, and there are things (personal values again for example) for which people would rather be fired than give up on.

That was pretty familiar to me, as I cannot agree to include chaos and lose quality for the sake of other things. And don't talk to me about quality versus work performance dilemma. It's a myth. You'll never be faster by writing uglier. In the long run, bugs and accidental complexity will bring you down big time.

It's quite an interesting twist to think about retrospectives in a more general sense. You can (should?) use them outside of IT as well. About three years ago, I've been to a sailing camp at Mazury where my trainer, who was a youngster, after every not-so-perfect maneuver, would ask: “What went wrong?”.  As simple as it is, the question generated a lot of afterthoughts that helper us pass the exam in the end.

Now, think for a while, what else could also benefit from a well performed, regular retrospective?

A marriage, perhaps?

ACE Conference general impressions

Getting up at 4am is never easy for me, and so it wasn't this time, especially after getting to bed only three hours earlier. Nonetheless, on the 8th of April, thanks to TouK, I was getting myself on a train to Cracow for 2 days long Agile Central Europe Conference, when out of a sudden I saw a man walking out his dog. That made me think: if this guy has so much love for his pet to walk it out in the middle of the night, then I definitely have enough passion for knowledge to stop complaining and be extremely happy that I have a chance to learn something.

And boy, how happy I am that I've been there.

While both 4Developers and Winter Agile Tunning, that I've attended last month, were really great (I can recommend both and I'd like to be there next year), ACE conference was simply fantastic. It seems that it's not only my opinion. Kuba Kurlenda, to whom I gave my free conference pass, that I got (won?) on Winter Agile Tunning for asking Szczepan Feber a hell lot of questions, was also delighted.

There are two organizers mentioned on the site, but as far as I know, it was put together by one man, Paul Klipp, who is a president and Scrum Coach at Lunar Logic Polska, and founder of half a dozen different groups and other undertakings.

So what was so special about this event? Apart from great speakers, that is. First of all, there were only two tracks, but you wouldn't be bored, because as a “bonus third track”, there was an Open Space, where everyone had a chance to put his favorite subject and get some people to talk about it. Breaks between presentations were half an hour long, which was also motivating to get to know each other and start talking. That was what I missed the most on Winter Agile Tunning, a chance to talk with everybody. Finally, Paul was aware that people are getting tired at the end of a day, so instead of putting not-so-hot topics on late hours, he got us the most funny/innovative to wake us up, and after that, we had Lighting Talks, lasting for 5 minutes each, which is precisely as long as you can keep your focus on the subject when you're exhausted.

Big kudos to Paul for all of this. The only two things I'd change were, that we didn't get any pens/notebooks together with conference materials, which is something of a surprise (I wasn't prepared for that and had nothing to note with, except my phone), and that it could've started at noon, so people from other parts of the country would have a bit more time to get there (and to sleep at night).

I had a chance to talk with Paul about it, so chances are, he'll use those ideas next time, as I'm sure there'll be more ACE Conferences in years to come.

So much for the general impressions. I'll have to make one post for presentation, for the sake of readability. Stay tuned.