Doing It Right: A Manager’s Perspective

A Hacker Chick Guest post by Trudy Prins, a wonderfully passionate software development manager at RIPE NCC in The Netherlands. I asked if she might share what she believes makes a successful software team. I hope you enjoy her answer and this glimpse into how she leads her teams as much as I do...

As a Software Engineering Manager, I believe a successful engineering team is a happy team. Happiness boosts productivity, creates an environment for excellence, and offers fertile ground for growth on both a company and a personal level.

So, what makes a happy team?

Frequent knowledge transfers. Team members should have the opportunity to schedule presentations in front of their peers, engage in discussions, follow trends, try out new solutions, have spikes on all kind of topics, go to conferences together and whatever they find suited to share their knowledge & enthusiasm.

Immediate feedback on their performance. I tell them constantly, clearly, and on the fly what I think they did good, great, or not good at all, without making a big fuss about it or waiting a year until their performance review is up. Their annual review shouldn't hold any big surprises.

Read More.....

Check It Out: Micromanagement, TDD, and Nonsense

Goodness on the Internets:

An Open Letter to Micromanagers by Scott Berkun.

“Owners of thoroughbreds never stop their horses during a race, every ten seconds, to remind  the horse and jockey how to run, where the finish line is, or that it’d be a good idea to finish first. Why? It would slow them down. Only an idiot would do this…”

and so begins Scott’s letter to micromanagers everywhere. Complete with a link to anonymously send the letter to your favorite micromanager and signed, Hugs and Kisses, The People You are Micromanaging.  I love this guy.

TDD Triage.  Bob Martin addresses a number of questions around Test-Driven Development, hopefully dispelling some of the religious extremist views on the topic and showing where TDD works and where it doesn’t. These include:

• Is TDD a replacement for architecture? (Nope)
• Is TDD a replacement for design? (Not even)
• Should TDD be used for every line of code? (Usually, but... actually, no)

How Nonsense Sharpens the Intellect. Alright, this is just awesome and reminiscent of Kathy Sierra's suggestions to insert a little randomness into what we do. A NY Times article explains the science behind why nonsense and randomness actually help us understand things better. And, with that advice, I'll end this here.

A LINQ Tutorial

For the source code inclined in each of you, I just posted an application and tutorial on LINQ, .NET’s Language Integrated Query, on The Code Project. 

It shows how to map database tables to classes with LINQ and then retrieve the data in the very cool LINQ-manner that makes me ooh and ahh for doing more with C#.  It also includes a simple WPF GUI that uses data binding to display the data and navigate the relationships because, well, WPF data binding is sexy. 

I hope you enjoy!

A LINQ Tutorial: Mapping Tables to Objects

Gratuitous brag update: This article was just selected as Editor's Choice on The Code Project (w00t!)

Agile Leadership: Methodology Ain't Enough

A lot of people say you can’t be a good software manager without really understanding software development. But, let's face it, people who understand software development are a dime a dozen in our industry. What we really need are people who understand leadership & management. I mean... you know the drill – when was the last time a software project failed for technical reasons?

And so, it was very cool to hear David Spann share his research on Finding and Developing Agile Leader’s at last week’s ScrumClub. 

It’s simply not enough to know the latest agile practices. In order for agile projects to succeed, they need leaders who exhibit agile behaviors and, here’s a hint – being a technical guru ain’t one of them.

Now, I don’t want to mislead – David isn’t saying agile leaders don’t have to know anything about software development. What he is saying is that the success criteria for leading agile teams is dependent on the leader’s beliefs and behaviors. That is, how they think and act is just as - if not more - important than what they know.

Read More.....

Poka-Yoke Your Code

Mary Poppendieck tells this great story about when the manufacturing plant she worked for transitioned to Lean. When they started, she says, they had this separate QA group whose job it was to find defects in the products after they were already made (sound familiar?). But then they took these QA folks and moved them out onto the production line to figure out how to make stuff without defects in the first place. Huh! Wouldn’t it be cool if we could do that for software?

This is the idea behind Poka-Yoke, or mistake proofing. It means setting things up in such a way that prevents people from making mistakes.

You’ve probably seen this before in product design – monitor cables with male & female ends that prevent us from plugging them in the wrong way. Or in software with controls like dropdown lists (male, female) that prevent users from entering incorrect values (I’ll let you use your imagination).

Toyota brings this idea onto their production lines with devices that prevent incompatible parts from fitting together. But also with poka-yoke methods that detect problems and shut down the machine (stop the line) or activate alarms so people are immediately alerted to correct it. So even when it’s not possible to completely prevent errors from occurring, they still prevent those errors from entering production. And they can then fix those errors immediately before they get a chance to compound into serious problems.

So the question is, how can we poka-yoke our code?

Read More.....

Where Does Developer Testing End and Tester Testing Begin?

Thanks so much to all of the awesome people who attended Nate Oster & I’s workshop at Agile 2009. 

You can also click here to view as slide show

We used games and ideas to look at how testers and programmers can really work together on agile projects in ways that makes sense on our teams. [Read More… to view the slides]

Read More.....

Where Do the Testers Go in Agile?

While I love to write, I occasionally prefer the role of reviewer or editor. I find it a nice break to sit on the other side and evaluate someone else’s work for a change.  How much more comfortable to critique someone else’s product then to summon the courage to create something myself!

But how much easier would it be to create if we had a magical safety-net that guaranteed whatever we did would turn out well?  How much more would we accomplish if we knew our every endeavor would be a success? Imagine a kick ass editor or, in software, a fabulous tester who had our back.  Let’s call them Rumpelstiltskin. Able to take Garbage In, and turn Greatness Out.

We might find that the tables had turned.  That the need for courage had passed from the creator to the tester.  We only have to give them straw.  They have to find a way to turn it to gold.

I have seen this happen on software projects, where the senior developers’ time has been deemed too valuable to “waste” on bug fixes.  Have you seen this?  A team of developers up in their ivory tower, banging out new features, while a test and bug team come in to clean up behind them.  All so the senior folks can go work on the next big thing.

Read More.....

Plane Crashes, Software Failures, and other Human Errors

Want to know if your team is effective? Listen to them.

We can learn a lot about team effectiveness through research that's been done on teams whose work can mean the difference between life and death. Namely, operating room teams and airline cockpit crews.

The airline industry, which gets such a bad rap, actually has a phenomenal safety record. An airline like United only loses a plane from an accident about once in every four million flights.

Hospitals, on the other hand, which we tend view as safe, are the cause of 44,000 – 98,000 preventable deaths in the US each year. Even at the low end, this tops the death rate from things we actually know to fear like breast cancer (~40,000), car accidents (~40,000) or, of course, airplane fatalities (~120).

So, clearly, the aviation industry is doing better in this respect, and the healthcare industry is now actively working to adopt some of their training, known as Crew Resource Management, or CRM for short.

What is it that they've learned? And, can it help us in software? Well, as I like to say, stop me if this sounds familiar...

Read More.....

A Brief, Incomplete, and Mostly Wrong History of Programming Languages

This is priceless:
» A Brief, Incomplete, and Mostly Wrong History of Programming Languages by James Iry on the One Div Zero blog.

Beautiful Teams

Last Tuesday, Andrew Stellman and Jenny Greene came to the Boston SPIN to talk about Beautiful Teams, the topic of a wonderful book they’ve just published. A book I believe Scott Berkun captured best when he said, “Stop complaining about your coworkers. Instead, get your team and your boss to read Beautiful Teams.” And of course, once you hear Andrew & Jenny talk, or read their book, you just can’t help but think about the teams you’ve worked on… what makes the good ones great? What makes the awful ones so unbearable? Is there a recipe out there for creating those wonderful, beautiful teams that are so exhilarating to be a part of?

The best damn team I ever worked on was a startup. Right in the Internet hey day. It was exciting. It was fast paced. We worked 80+ hour work weeks, slept at the office, rarely had enough money for anything beyond the next couple of payrolls. But we were developing things no one had ever developed before and getting written up in magazines and had the ultimate brag factor over the cool things we were doing with audio and video. We had Microsoft begging us to tell them our secrets, AOL wanting to buy us (they eventually did). We took trips to the WinAmp and MTVi offices and went to RealNetworks parties hosted in museums. Man, we were HOT.

Read More.....

Scrum: A Framework for (Finding) Failure

Ken Schwaber, co-developer of Scrum, just gave an interesting talk at the Agile Project Leaders Network. Scrum, he explained, is not a methodology, but a framework for developing complex products.

The thing about complexity is that the more of it we have, the less likely it is that an external entity can dictate our way to success. There are just way too many variables and too many unknowns. Instead, what we need is a safe, supportive environment in which the team can generate ideas to dynamically deal with this complexity.

Scrum serves as a container for this environment. It’s not a methodology, it doesn’t tell us what to do (we still have to figure that part out). Instead, it exposes the weaknesses and, dare I say, failures in how we’re doing it.

Scrum is not going to solve your problems, it’s just going to make them in-your-face obvious, every day.
"Do you have a mother-in-law?" Ken asks one of the men at the session.

Read More.....

Craftsmanship and Ethics

Bob Martin’s Craftsmanship and Ethics presentation is now freely available. Think of it as a 45 minute video on the key principles of agile programming. Or, if you’d prefer, a tutorial on how to become a professional developer.

As developers, our main product is our code. And, so, to be considered professionals, we must craft our product (code) in a disciplined manner. We should always, for example, check in the code a little cleaner then we found it so that our systems are always improving (as opposed to degrading). However, in this industry, one of our biggest problems is that we almost always check it in worse then we found it. Uncle Bob jokes,

“It’s difficult to call ourselves professionals when our primary outcome is a huge, stinking mess!”

"How many times have you been significantly slowed down by bad code? Martin asks and we can be sure all programmer hands went up. “Then why did you write it?” he asks. There is laughter because of the truth in his question. We have all been slowed by bad code and yet, we continue to allow bad code to be written on our projects. And why? Because we didn’t have time to write it well?

We fool ourselves into thinking we can defer the problems of bad code until later. But the problem is that the slow down is not something that occurs months from now, it’s immediate. “How many of you have stared at code you wrote 2 hours ago and thought, ‘what the hell does that do?!'”

“Bad code is not something that slows someone else down months from now. It slows us down immediately. We must not write bad code. Period. This is a fundamental issue of professional behavior.”

And, so, Uncle Bob presents us with a number of principles we can follow if we want to become professionals. In doing so, he offers justification behind many of the agile practices – iterative development, pair programming, TDD, avoiding Big Up Front Designs (only Uncle Bob likes to call them “Turgid, Viscous Architectures”). And, what I think is arguably one of the most important lessons of agile, which is that “the only way to go fast is to go well.”

Religious War #48,293: Single Vs. Multiple Returns

A few months ago, a reader emailed me for my views on single versus multiple return statements in a method…

"What's your take on single-vs-multiple returns in a method?

Personally, I don't mind multiple returns. It often makes code more readable, less if-nesting, etc. But it has almost become a war here at my workplace, with a few people saying it's “bad programming" to have more than one exit from a method.”

And I thought – wow, are people really still fighting over this? But then, I'm reviewing some code with an otherwise totally competent coworker the other day and he mentions how much he dislikes methods with multiple returns. Huh!

So, I thought I'd post my response and see what others think.

Read More.....

The (Schedule) Games Managers Play

I went to see Johanna Rothman speak last week at the Software Quality Group of New England. I like Johanna because, as an expert in management, she can spot a line of management B.S. from a mile away.

I don't have this skill. As a coder, my special power is spotting crappy code. If another developer shows me crappy code, I can describe 7 ways to Sunday why it's a bad idea and 10 ways to fix it. But management B.S., that's harder. Kind of like those game shows that turn seemingly intelligent folks into complete idiots... that's pretty much the effect management B.S. has on me. I will actually sit there, stupefied, trying to reason some sense out of what they tell me. "Well, of course there's no time for us to do things the right way. BUT, if you can just deliver this 6 month project in a 3 month period, that leaves you a whole 3 extra months to clean things up!" Uhhhhh.

So, I liked Johanna's presentation, Schedule Games: Recognizing and Avoiding the Games We Play, because it makes me think there might be hope for us managerially-challenged developers yet.

Read More.....

Why You Should Let Your Developers Surf

A lot of managers don't think twice about every day things that slow down developers...

• Slow or unstable development machines
• Delays from business folks in clarifying requirements
• Little to no feedback on the product until it's already "done"
• Loss of focus from repeated interruptions

And yet, these same managers will often go out of their way to make sure the developers are busy 100% of the time in the name of "getting things done faster." It's a little counterintuitive if you stop and think about it. As any good developer knows, optimizing a part of your system that isn't the bottleneck doesn't actually speed anything up. In fact, it can actually do more harm then good as optimized code can be more difficult to understand and to work with.

But, anyway, what are those developers so busy working on if they don't have the information & feedback they need to build the product correctly? Whenever this happens on my projects, all it does is muddy up the code for the rest of us with unnecessary or incorrect functionality that degrades quality and slows us all down. Sort of like Wally's anti-work...

"This week I did equal amounts of work and anti-work.
For every unit of work I did, I generated an equal amount of unnecessary work for co-workers.
I figure I broke even."

Read More.....