The Hacker Chick Blog

Evangelist Chick: Preachin’ the Good Word to Devs

2010-03-19T14:20:00.009-04:00

I wrote the start of this post after returning from a full day of interviews, what Microsoft has endearingly termed Finals Day… I had no idea I’d actually get to post it now, 2 weeks later, as I get ready to start this awesome new job…

I just got back from my Finals Day with Microsoft. I’m interviewing for a Developer Evangelist position, which is beyond exciting. Not to mention a tad mind blowing. If anyone had told me a few months ago I’d be interviewing for this job I would have laughed them right out of the room.

And yet, here I am. So, in the spirit of fellow hax0r turned Microsoft Evangelist, Joey DeVilla (aka @AccordionGuy), I thought I’d blog about just WTF I’m thinking.

If you’ve read anything of mine, you probably know my shtick, I like to say:

“Java, C#, C/C++… it ain’t about the language but the wonderful things we build.”

And this is true – for languages, platforms, technologies, practices… I pride myself on being technology agnostic and just picking the right tool for the right job.

So, how am I interviewing for a Microsoft Evangelist role?? Good question! Let’s step back into our WABAC machine...

Sherman, take us back to April, 2008…

At MIX 08, Daniel Makoski gave this amazing presentation called Beneath the Surface: The Natural Experience Vision. In it is this quote of his that I love so much:

“The last 30 years of computing have been about people learning the language of computers…

The next 30 will be about computers learning the language of people.”

Watching the video of this presentation was one of those career-altering moments, where you see something and go “Forget everything that I’ve done for the last 15 years, THIS right here is what I want to be doing.”

And so, I set about learning the technology to help get me there. I taught myself WPF, because Surface’s UI was built with WPF. I hadn’t actually done Microsoft development since my C++/Win32 API days

#include <windows.h>

LRESULT CALLBACK WindowProc( HWND, UINT, WPARAM, LPARAM );
int WINAPI WinMain ( HINSTANCE hInstance, HINSTANCE hPrevInstance,
                     PSTR szCmdParam, int iCmdShow )

and so that meant I also had to learn this (not so) new fangled .NET and C#. The last time I looked at C#, it had struck me as the perfect combination of stripping away all the power of C++ with a dumbed down version of Java. Awesome! So I was pretty blown away by not only how far it’s come but how much it’s clearly left Java in the dust.

After a year or so playing with these tools and seeing what they can do, I concluded that these are the right tools for building out the next generation of software that’s natural for people to use. The type of software I want to be building.

And so, I decided to found my own company around this notion of building better software: Digital Muse. I even gave it a tagline inspired by Daniel Makoski’s presentation teaching computers the language of people. And, I signed up for BizSpark, Microsoft’s program that gives free software (yay!) to startups. Awesome!

Now, I just had to figure out how the heck to get customers. Hmmm.

So I’m looking around at all things WPF & Silverlight, and I come across this crazy job opening: Microsoft Developer Evangelist: Boston Startups. Hmm, what does a Developer Evangelist do anyway? Kinda’ curious, I click in and proceed to read a description that eerily describes me to a T. Here are some of the highlights:

Must demonstrate a passion for technology and previous experience showing developers “how to” (check!)
Possess current technical background in both Microsoft & competing technologies (Java, Silverlight, WPF–check!)
Exceptional skills creating and driving solutions to unexpected challenges (Hacker Chick, present!)
Opportunity to innovate by engagement, working with startups (*drooool* I love startups!)

Of course, there is no way in hell they’ll contact me back. But, what the hell, I post my resume to Microsoft and attempt to submit it for this position. Apparently, I wasn’t 10% smarter then their Careers website (tip: when applying to a Microsoft position, you probably want to use IE) and so failed. It made it into the system, but not for that job. The next day I get an email from a Microsoft recruiter saying that someone forwarded my resume to her and she was wondering if I might be interested in this position. It’s for a Developer Evangelist for Startups in the Boston area.

… fade back to today …

Despite channeling Jordan from Real Genius throughout the entire slew of phone & in-person interviews –- getting so excited and talking so fast I was sure I was just going to pass right out (exactly the right impression whilst trying to demonstrate your ‘leet communication skills), I somehow managed to land the job without the need for smelling salts.

Now, I’ll get to work with other devs who are like-mindedly crazy passionate & trying to start their own companies, and I’ll get to help them with all these amazing technologies. I honestly can’t think of a single thing I would rather be doing.

Everyone I tell says to me, “oh yeah! You’ll be a great evangelist!” and I keep thinking wow! really?? That is so weird, I’m just a hacker chick. Is being the type of person that would make a great evangelist a good thing?

But then, I think about how many devs I’ll get to reach to help promote software goodness and I think yeah. Yeah, I think that IS a good thing after all.

So just call me Evangelist Chick… preachin' the good word to developers.

Are We Agile Yet?

2010-02-25T20:35:00.031-05:00

I read somewhere that a large number of software teams think they’re Agile because they do Daily Scrums.

Now I don’t like to get religious, and I certainly don’t believe you have to follow some list of Ten Specific Practices to “Be Agile.” But I do think that sometimes companies get a little overly anxious to jump on the agile bandwagon and before we know it we’re regaled with horror stories of agile project failures. But were they really agile? Or were they just doing Daily Scrums?

What should you do if your company is trying to go agile? How can you make sure that – even if you’re not following some textbook-perfect definition – that you’re actually doing enough of the right stuff to reap agile’s benefits?

Focus on Intent, Not Practices

Agile is a set of values (see: Agile Manifesto), not practices. Of course, we’ve got all these super smart people in software and so we’re continually discovering new practices to help us achieve those values. But here’s the thing:

The practices are tools to help us, they’re not what makes us agile.

What this means is, you can’t just whip out your handy dandy List o’ Agile Practices and pick out 1 or 2 that look easy (“Hey, I bet even WE could handle these Daily Scrum things! And ooh, let’s stop Big Up Front Design too – we’re not very good at design anyway”) and think it’s going to make you Agile.

Instead, we need to focus on agile’s intent – which is defined in the Principles behind the Agile Manifesto. Things like:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Think about what you most want to achieve with agile, and then select some practices that will help you achieve it. This is helpful, because if you know what you’re trying to achieve, then you can evaluate your progress.

If you’re just trying to “be agile” – that makes it a little fuzzier. Are we agile yet? Sure, why not!

So how do you measure if you’re staying true to agile’s intent with the practices you select? I like to think of Lean as the foundation under agile – the principles that explain why it works. And so, I find that Lean provides a good compass for helping us evaluate whether the practices we select are helping us… or taking us in the wrong direction.

The 7 Principles of Lean Software Development
(adapted from Implementing Lean Software Development by Mary & Tom Poppendieck)

The following questions can (and should) be applied not only to the new agile practices you select, but also to the existing practices your team is following. Keep in mind that becoming more agile means not only adopting new, agile practices, but also eliminating the old ones that are holding you back from that agile nirvana…

1. Eliminate Waste – “Add Nothing But Value.” Can you articulate the value your practice is adding to the business or the team? Bonus Question: Is it the best practice your team can do right now to achieve this value? Just because a practice adds value doesn’t mean it’s the right place for your particular team to start.

Daily Scrums, for example, are intended to help the team. If the team finds them a waste of time, that should be a red flag. Maybe the Daily Scrums are being run incorrectly (hint: they’re not status meetings), so you need to start with learning or coaching. Or maybe your project hasn’t implemented the other parts of Scrum (teams with shared goals, sprints with backlogs, definitions of “Done”) that the Daily Scrum is there to support – so you need to start with those.

Until you resolve those issues, ask yourself if the Daily Scrums are really providing value? Or just waste?

» See Martin Fowler’s It’s Not Just Standing Up: Patterns of Daily Stand-Up Meetings for correctly run Daily Scrums.
» See Mike Cohn’s An Overview of Scrum for the building blocks of Scrum that the Daily Scrums support.

2. Build Quality In – You can’t test quality in at the end. Does your practice help ensure the team has what they need to build features right the first time? Or does it result in rework by identifying issues after the developer is “done”?

Acceptance Test-Driven Development, for example, captures the customer’s requirements as executable tests that the team can use to validate the features as they build them. Having exploratory testing in your definition of “done” means issues are identified real time so they can be corrected before moving onto the next task.

Alternately, having devs hand their code over to testers to validate so the devs can move onto the next feature results in rework and an ever growing pile of bugs as the testers find bugs in code the devs thought they were done with.

» See Where Do The Testers Go In Agile?

3. Create Knowledge – “Software development is a knowledge-creating process.” Does your practice encourage systematic learning that enables the team to stay on track and make good decisions? And does it include mechanisms for the team to rapidly respond to this new knowledge?

A number of Agile practices are intended to provide the team with frequent and regular feedback that they can learn from. This includes demoing the product to the customer at the end of each sprint to get the customer’s feedback and regular retrospectives to get the team’s. Also, automated tests that get run with TDD and continuous integration practices to provides rapid feedback on the integrity of the software.

Of course, if no one examines the results of the Continuous Integration tests, or no changes are made as a result of the retrospectives, then it’s clearly failing to meet its intent and so not providing value (see Principle #1).

4. Defer Commitment – Because software is a knowledge-creating process, the more we build, the more we know. The best time to make decisions is Just In Time. Does your practice enable you to defer decisions or clarifying details until the last responsible moment? Or is there pressure to nail things down as early as possible?

For example, User Stories allow us to capture the features we want to implement, while deferring the specifics of how to implement them until we’re actually ready to build them. Once we’re ready, we’ll likely have some of the application built out so it is clearer what the new features should look like. Alternately, Big Up Front Design, where we flesh out all the architectural details and build them up front (because we know we will need them) often results in rework the first time we write application code to use that architecture and discover what we really need from it.

5. Deliver Fast – “Speed is the absence of waste.” What is most interesting is that the Poppendiecks equate “fast” with “quality”. This isn’t about hacking something together as quickly as possible. They say:

“There are two ways to achieve high quality. You can slow down and be careful, or you can develop people who continually improve their processes, build quality into their product, and develop the capability to repeatedly and reliably respond to their customers many times faster than their competitors.”

I don’t know about the rest of you, but the 2nd way sounds a lot more enjoyable to me. So… I think this gives us a few questions we can ask about our practice:

Does it enable the team to repeatedly deliver working software quickly to their customers? (No waste!)
Does it promote internal quality to enable the team to sustain it’s fast pace over time, as the code base grows?
Does it allow the team to do what they feel needs to be done to respond effectively to the customers?

6. Respect People – In her paper Principles of Lean Thinking, Mary Poppendieck says:

“It is sometimes thought that a benefit of good software engineering is to allow low skilled programmers to
produce code while a few high skilled architects and designers do the critical thinking. With this in mind, a
project is often divided into requirements gathering, analysis, design, coding, testing, and so on, with
decreasing skill presumably required at each step. A ‘standard process’ is developed for each step, so that
low-skilled programmers, for example, can translate design into code simply by following the process.

This kind of thinking… is the antithesis of lean thinking and devalues the skills of the developers.

Centering on the people who add value means upgrading the skills of developers through training and
apprenticeships. It means forming teams that design their own processes and address complete problems. It
means that staff groups and managers exist to support developers, not to tell them what to do.”

This is a hard one to capture because there is much that is felt but not seen, but I think we can still glean good questions to consider when evaluating our practice:

Does it create teams that are able to design their own processes and address complete problems? (Or does it break things down by role and state that only certain people can do certain tasks)?
Does it push responsibility and decision making to the lowest level possible? (Or does it tell people how to do their jobs?)
Does it give people the training, resources, and support they need to be effective?
Does it foster pride in workmanship – creating engaged, thinking team members who are continually improving?

Per the Poppendiecks, if you implement all the principles except this one, you’ll “reap only a shadow of the potential advantages.” Yet if you implement only this principle, “you will position the people in your organization to discover and implement the remaining lean principles.”

7. Optimize The Whole – When we optimize for a subset of the whole, we almost always end up sub-optimizing the whole. Does your practice reward people for providing actual business value? Or does it reward them for intermediate steps of the process?

For example, some projects rewards developers for lines of code, or testers for # of bugs found. However, more lines of code means more code to maintain and so will actually slow the overall delivery of features. Similarly, more bugs is obviously working against the organization’s goals of delivering quality software. These types of measurements tend to be the result of teams that are structured to only provide one piece of the value chain (e.g., coding or testing) and so measure the output of those teams and reward for things that suboptimize overall delivery. Alternately, cross-functional feature teams that include all of the members/skills required to provide the required business value can not only optimize the process of developing and delivering each feature, but can be measured and rewarded on this facet as well.

What about the practices you’re following on your projects? Are they capturing the intent of Agile?

Just Do It: A Quick Intro to Agile’s Technical Practices

2010-02-14T17:11:00.011-05:00

A lot of people think Agile is about working faster, but that really isn’t right. It would be more accurate – and perhaps alleviate many of the arguments against agile practices – if we thought of agile as being about working slower because we’re being more deliberate. BUT, at the same time getting rid of all the crap that doesn’t add value, so that we do, indeed, end up delivering more functionality in a shorter period of time.

I like to think of Agile as the Just Do It methodology. In software development, we’re really great at this thing called “yak shaving.” If you’re not familiar with the term then take a moment to read: So There I Am, Shaving a Yak…. Go ahead, I’ll wait. It’s really funny, I promise.

“So there I was at the zoo, shaving a yak, all so I could take a few pictures of my dogs at the park.” – Bill Gaiennie

A really huge part of yak shaving – at least for me – is trying to figure everything out so that I can make sure I’m going about things the right way. Oh boy, I can plan and research and do proof of concepts like nobody’s business. But at the end of the day, I’ve got a bunch of “stuff” with no actual working software for the app I’m supposed to be building.

Agile instead says “You’re never going to know everything about the app until it’s already been written. Cope.” and instead gives us tools to continue to move forward by focusing on what we do know. And then, a funny thing happens. The more of the application that we build, the more we learn. And so, we’re able to move forward, not by focusing our time on what we don’t know, but rather by focusing on what we do know and building actual value out of it.

User Stories

Raise your hand if you’ve ever spent hours and hours around conference tables debating the minute details of how a feature should work in an application that hasn’t even been built yet. Now keep it raised if this is something you’d prefer to do over, say, poking yourself in the eye with a sharp stick. Yeah, I thought so.

It’s all but impossible to design the details for anything when we don’t have visuals – or some kind of shared understanding - to guide us by, and even more so in software, which not only has form and function but also interactive behaviors. So, let’s give it up and just move forward with what we do know.

User stories are reminders of the features we think we’d like to implement, but for which we’re deferring decisions on their details until we’re actually at a point where we have enough information to provide them. They’re purposefully short and informal, “As a [type of user] I’d like to X so that Y” and they’re scribbled on 3x5 cards that can be easily viewed and priority ordered by customers or product owners. And since they’re low ceremony, we can all intuitively understand that it’s no problem for the customer to add, update, remove, or reorder them at any time up until the point we’re actually working on them in an iteration because, hey, we’re agile like that.

Yes, we’ll eventually need to understand their details – but not until we’re ready to work on them. Which brings us to…

Emergent Design

This is a hard one because intuitively we feel that if we could know, up front, every last aspect of how the software should look and behave, that we can come up with an optimal design. We think that if we only build one feature at a time, without considering upcoming features, that we’ll end up with a band aided, glued together, duct taped nightmare that will fall over before we ever make it to the first release.

And, to be fair, if we add every new feature without any consideration for the overall design then um, yeah – I’ve worked on those systems before. I believe they’re called big balls of mud.

However, I’ve also worked on systems where the more functionality we build out, the more we learn about what type of design makes sense. In fact, I’d have to say this is actually true for every system I’ve ever worked on. Just like our user stories, the more of the application that gets built, the more we understand about what works and doesn’t work, and the better equipped we are to make good decisions.

So I’d actually argue that it’s a misnomer that we can come up with the optimal design by knowing all the requirements up front. That, in fact, we can only come up with the optimal design by implementing functionality and then using the knowledge gained to evolve our design with each new feature.

This is not “no design”, this is emergent design. It means that with each new feature that we add, we determine what the optimal design should be for our current functionality plus this new feature and then we …

Refactor

Refactoring is not something we spend days, weeks, or, god forbid, months (!) on because we made a mess out of our code. Refactoring is the act of continuous design while we code. It is something we do continuously, several times every day, and ideally according to guiding design principles, such as the SOLID Principles, to keep our code clean.

If you’ve worked on a legacy system, the mere thought of such a thing will elicit screams reminiscent of bad horror movies because you can just hear the sound of code breaking with each new refactor, right?

This is where we get to the point that the agile technical practices are really meant to work together and so yes, refactoring is going to be pretty scary unless you’ve built yourself a safety-net via…

Test-Driven Development

TDD is the ultimate Just Do It for how we implement each of our user stories.

Ideally, we are following Acceptance Test Driven Development so that we have objective (executable!) acceptance criteria to know exactly what is expected of this user story. And, we’ve broken the user story down into individual tasks that can each be done in about a day. So, we’re hard core focused on a single task that we can get our brain wrapped around and know precisely what it needs to do.

Now, all we need to figure out is how to design and code it in. But rather than spinning our wheels figuring out the optimal way to handle the entire task, TDD provides us a structured way to walk through designing and developing it – one step at a time, always keeping the focus on exactly what it is that our code needs to accomplish and what we want our design (e.g., the public interface for our classes) to look like to access this functionality.

Okay, to bill the customer, we’re going to need a Customer class and it should provide us with a method to obtain it’s Balance. Great, how should that method look? Let’s solidify that in a test, and then write the code to make it pass.

Even so, this can sometimes be easier said then done. Particularly if we’re working with a new technology or in a new area of the application that we haven’t spent much time before. And so, here is where we can get even more focused help on moving forward with…

Pair Programming

You don’t have to do this for every line of code written! But even if you’re an introverted programmer like me, you have to admit that pairing is a great way to share knowledge, get people up to speed on new technologies or unfamiliar parts of the system, and to just get a second set of eyes for working through a particularly tough problem.

It’s also a great way to keep things moving forward. The pair can bounce ideas off one another, and often when one is stumped, the other has an idea to move it forward.

Of course, at the end of the day, the most important thing is that the entire team is moving forward in the same direction – not one person adding features that break another person’s features (that would never happen, right?).

Continuous Integration

Our CI box makes sure the team is moving forward together, not working against one another, by automatically running the automated tests that have been built up through ATDD and TDD every time someone checks in code.

If someone’s check in does happen to break the build or the tests, the CI box has the team’s back so the problem is caught immediately and the offender can often quickly resolve the issue while it’s still fresh on their mind.

Do these practices add more time? Sure, but the team is also delivering faster because they’ve cut out the crap that doesn’t add value. No code built that isn’t specifically for a user story that’s been chosen as a top customer priority. No discussions wasted on a requirement that never ends up getting implemented. And the code is tested and integrated as we go so by the end of the iteration, it’s already tested and integrated! We can actually demo it to the customer to get their feedback and then everyone learns so we now know a little bit more and so can implement new features in the next iteration.

Mike Cohn also has some good data in Succeeding with Agile that you might find surprising:

» TDD takes only 15% longer than not doing TDD and leads to fewer defects (and so less debugging/fixing time)
» Pair Programming takes more man hours, but shorter project duration (getting that feature out the door faster) as well as fewer defects.

So what are you waiting for? Just do it!

More LINQ Goodness: Now with WPF!

2009-12-23T12:02:00.004-05:00

Apologies for the slow down in posts, I’ve been head’s down in code bringing you more tutorials on LINQ to SQL and how to use it with my current obsession, Windows Presentation Foundation.

It has now been expanded into 3 parts – aka, everything you ever-never wanted to know about LINQ to SQL:

These tutorials describe how to manually map your classes to database tables with LINQ to SQL so you can have support for M:M relationships as well as WPF data binding using my own ~~hack~~ ~~workaround~~ solution to providing this functionality. One person even claimed my code was cleaner then the auto-generated code, but I’ll leave that for you to decide yourself.

But… even if you do choose to auto-generate your classes, understanding how these techniques work will allow you to expand the code to better fit your application's needs and troubleshoot issues when they arise.

I hope these help you out in your own encounters with LINQ to SQL!

Doing It Right: A Manager’s Perspective

2009-11-05T08:01:00.002-05:00

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.

Team-spark, cooperation, concentration and energy. A general feeling of friendship and focus is in the air -- this is an intuition and experience thingy, I just know this. I feel it when it's there and I notice when there's trouble and friction. Of course, I share the same room with them! Otherwise, you miss out on these very important signals and you can't identify your team-specific energy signature. Or trouble-thermometer.

Be proud of accomplishments. Do frequent deployments and sprint demos. The team can show off their accomplishments -- their work, which they are proud of. Stakeholders can provide them feedback and pay them compliments when deserved and challenge them when needed. Make process improvements like delivered business value, rising velocity, better code coverage and decreasing bug counts visible to all.

Good company! This is something you need to be very aware of when hiring people -- make sure they add to the team cohesion. No lone wolves! If someone is technically brilliant but their social skills are lacking, I never hire the guy/girl. Has to be both, 50-50. Great coder and communicator, otherwise it's not going to work.

Apply the big 3: test driven development, requirement driven test cases, and agile methodology.

Keep it simple, keep it clear. It always works. No super complex architecture, ideas from Mars, tools from outer space or far-fetched solutions. Simple and clear is always the best choice.

Pair programming. A great way for the team to interact, learn from one another, review each other's code in real-time, help each other to overcome obstacles, share brain waves, cooperate!

A short anecdote -- when I interviewed one of my current engineers, we asked him if he cloned himself 10 times to create a team of 10 of him, what would go well and what would go wrong? For the latter, he thought for a bit, and when he spoke he said, "Well, in the end, I guess, everything could go wrong. You are always thinking in a certain direction, and when you don't get a second or third perspective, it's inevitable that you're eventually going to reach a dead end. It may take a long time to happen, but in the end you will fail". Isn't that brilliant? Of course I hired the guy :)

Empowerment. Engineers should be empowered to implement any solutions they think fit the requirements, within the high level framework decided up-front. It's useless to interfere or try to micromanage this. Don't interrupt their flow when they are doing fine.

Experiment with roles. I give them specialties to show their greatness in, but also leave them room to experiment with new roles they find appealing (ScrumMaster, product owner, UI designer). Keep on learning!

Don't demand elaborate reports and documentation solely for the fact that you then possess this information. Knowledge is power? No way -- it means nothing out of context. Reporting & documentation should always satisfy a direct business need -- I don't believe in knowing for the sole purpose of knowing.

Treat them right. Make sure they know you care for their well-being. Buy them cake, call them when they are miserable, make sure they get better chairs and monitors when they need them. Be sensitive to their needs and show empathy. They are great people and deserve your care and respect, right?

Stimulate them to explore their limits. Go further. Dig deeper. Boldly go where no-one has gone before. :) Show us something spectacular!

Let them take the glory of their successes. I won't snitch it away from them. My team presents their own ideas and implementations to senior management and clients and takes full credit for them!

Provide them with everything they need to succeed. Buy them shiny new MacBook Pros that they love to work with (it will pay itself back, no worries ;) ), provide them with a nice, light, spacious and quite room with lots of white boards where they can all sit together and be happy, let them buy stuff when they need it: books, licenses, whatever they think is needed to match our expectations.

-- Trudy Prins, fellow hacker chick

Check It Out: Micromanagement, TDD, and Nonsense

2009-10-15T10:00:00.001-04:00

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

2009-10-13T09:56:00.005-04:00

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

2009-09-29T09:26:00.012-04:00

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.

Beliefs

David identified 5 underlying beliefs that a successful agile leader should hold.
How many of these do you hold? How many does your manager?

1. A group of well intentioned, skilled people will make a better decision through consensus then I can on my own.

2. Five or more people with a single, clear purpose can (and often do!) change the world.

3. Asking the right questions will always create better outcomes then making a series of well-crafted statements.

4. The leadership role is about creating a great environment in which others can succeed.

5. Trust is the foundational component of any relationship and it must be tended to with care, integrity and humility.

Behaviors

David identified the behaviors that make agile leaders successful and from that came two very interesting observations:

The behaviors that make agile leaders successful are, largely, the same behaviors that make Facilitators successful.

The behaviors that cause agile leaders to fail are, largely, the same behaviors we seek when hiring Project Managers.

Behaviors We Want in our Agile Leaders

Strategic. Agile is very pragmatic, with a strong emphasis on the here & now. YAGNI, defer decisions, no Big Up Front anything. And so, it's interesting to see strategic, "taking a long range approach," as a key success criteria for agile leaders. I think this underscores the importance of having a clear vision for the team to rally around, and the need for our leaders to be thinking ahead to make sure that we're not just moving forward - but moving in the right direction.

Tactical. At the same time, agile is very pragmatic, delivery focused. So our leaders need to emphasize the importance of continuously delivering value by focusing on "short-range, hands-on, practical strategies."

Innovative. We are out there, every day, responding to change, creating things no one has before. Our leaders should be open to new ideas, willing to take risks, and comfortable with agile's level of change.

Excitement. We want our leaders to be passionate! To have excitement and energy and enthusiasm, and to pass that passion on to the team and make it felt by all who come in contact with it.

Communication. Agile is about bringing people together to produce more than they could individually. Those 5 people with a clear purpose out there changing the world. This requires communication, "stating clearly what you want and expect... clearly expressing your thoughts and ideas; maintaining a precise and constant flow of information."

Consensual. Agile teams are about respect. Leaders value their team's ideas and opinions and demonstrate this by using their position to help the team gain consensus on how to proceed rather than just telling them what to do.

Delegation. Agile teams are about trust. Leaders encourage this by enlisting team member's strengths to achieve results and giving the team autonomy to make their own judgments about the best way to meet objectives.

Empathy. Agile leaders empathize with and support their team members.

Behaviors that Hurt Agile Teams

Authority. Leaders who are - and believe others should be - deferential to authority, tend to be liabilities on agile teams. Agile teams need to be continuously on the look out for new and better ways to do things and a great way to kill that that is by saying "nope, we don't allow new ideas unless they come from/are approved by the guy at the top."

Structuring. The Plan-Driven Manager who spends weeks devising the "perfect plan" and the rest of the project aligning everything back to that is in direct opposition to the team's agility. Per the manifesto, agile teams value responding to change over following a plan.

Conservative. If it ain't broke don't fix it, says the conservative leader, while agile says, "what can we do better?"

Technical. While some technical understanding is good, being an expert is not only unnecessary but, as we've all seen, can be detrimental. We need our leaders helping us with communication and vision and supporting us to get the work done, not busy doing it all - or coming up with all the answers - themselves.

When we look for managers in our organizations, what kinds of traits do we look for? Managers should have Authority, right? And, just look at the PMP - you know, the thing that tells us how to manage projects - about 90% of it's Body of Knowledge is around planning, so Structuring must be important too. Conservative? Sure, old white guys in suits, right? ;-) And technical... well, we all know what role the techies get promoted to when they do a good job.

What about YOU: Which beliefs and behaviors do you see in your own agile leaders? What about in yourself?

--
Learn more in David Spann's articles on his research into Agile Management Behaviors:
» Agile Management Behaviors: What to Look For and Develop
» The Facilitative Mind of Agile

New! See Patrick Wilson Welsh's response: Agile Team Lead : Useful New Role?
which takes this idea to the next level, and join in the conversation!

Poka-Yoke Your Code

2009-09-08T10:38:00.013-04:00

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?

And I think the answer, like Toyota’s, is a range of techniques…

Compilers. If we’re using a compiled language then our compiler prevents language-specific errors from entering the software –- it won’t even build the software if it detects errors, right? So we can start by designing our code in a way that actively pushes things up from run-time detection to compile time detection. Using thing like using generics and favoring objects over primitives. And avoiding hacks like hiding things in String or Object types that might feel flexible but that allow errors to sneak right past our first poka-yoke.

Modern Languages. We can build on this idea by using modern languages that are specifically designed to prevent common programming errors. Things like functional languages that use immutable values and methods with no side effects that make our code safer by preventing us from making those mistakes in the first place.

And if we’re stuck with older languages, we can still learn about the newer languages & incorporate some of their ideas into our own code to make it less error-prone. Stephan Schmidt (@CodeMonkeyism) wrote an excellent post on this Go Ahead: Next Generation Java Programming Style that I highly recommend.

Automated Tests. Well, this is all lovely, but of course it won’t find even the most basic of application errors. So, like Toyota, we need to supplement our builds with poka-yoke methods that detect problems and alert us to correct them. We’re probably already using automated tests to validate our application logic –- issues our compiler can't catch. So what we can do are employ our own poka-yoke techniques to give us better coverage and that truly “stop the line” to prevent errors from moving forward. Things like:

Using TDD & ATDD to ensure we don’t write a line of production code without test coverage to poka-yoke it.
Continuous integration boxes that alarm when these tests fail so we’re immediately alerted to fix them.
Tools & scripting languages that automatically run the appropriate test suites on check ins and deployments and to prevent (or at least alarm) us from taking those actions upon failure.

Exploratory Testers. Okay, but what about all the stuff we don’t think to put in our tests (it breaks when you do what?!). This is where we need to take our Testers (aka “QA Folks”) and move them out onto the production line (yep, right there in our programming spaces!) to figure out how we can make stuff without defects in the first place.

I know, we’re really super smart and all, but software development is hard. And if we knew how to make software without defects in the first place, well… then you probably wouldn’t have read this far down in this post by now (and if you did, feel free to share your secret with the rest of us in the comments).

We are really good at building software. But we need another perspective. While we’re focused on how to make things work, it’s helpful to have people focused on how things might break so that we can then feed that knowledge into what we’re building to prevent those defects from happening in the first place. This means things like pairing programmers & testers on each story so we’ve got that tester right there on our coding floor with us doing exploratory testing early & often. And it means feeding their results into new automated tests that then become part of our poka-yoke.

Even at Toyota they can’t know from day 1 all the things that might break. Instead, they employ processes that are continually inspecting for problems in the system and, when one is found, they take steps like adding new poka-yoke methods to prevent it from ever occurring again. Wouldn’t it be neat in software if we found a way to stop repeating our same mistakes over again? :-)

I have obviously only barely scratched the surface here, so am hoping this post will generate more ideas. What ways can you see for poka-yoking your code? How can we evolve these ideas to really make them work?

Where Does Developer Testing End and Tester Testing Begin?

2009-08-31T10:00:00.008-04:00

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

Roy Tanck's Flickr Widget requires Flash Player 9 or better.

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]

In agile, we love to talk about “all together” but the truth is a lot of times our teams are structured in ways that force us into testing smells that make it really hard for us to succeed, no matter how hard we try. Things like:

Testing at the end
Repeating manual tests
Using testers as a safety-net
Not aligning rewards with goals
Programmers & testers not working towards the same goal

You can view our slides below. I’ll try to post more about these smells in the coming weeks. And if there’s one thing I learned from Agile 2009, it’s the power of ideas when you’re working with brilliant and passionate people, of which we have so many in this field. So, would really love to hear your thoughts on these concepts. How can we make them better and how do we take them to the next level?

Click here to view on Slide Share
This presentation is licensed under a Creative Commons Attribution-Share Alike 3.0 License.

What do you think: How do the programmers & testers work together on your projects? How do we get programmers & testers pairing effectively on projects?

--
» Photo widget courtesy of http://www.roytanck.com/

Where Do the Testers Go in Agile?

2009-06-16T09:00:00.008-04:00

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.

I just can’t imagine this situation is satisfactory for anyone involved. Not for the senior developers because we ask them to invest all that hard work but then deprive them the satisfaction of a job well done by forcing them to stop short of learning whether they got it right or allowing them to sculpt it into the final solution. Not for the testers or bug team, because they’re left with the onus of getting it right, while the senior developers get all of the credit.

Even when the developers are writing unit tests to ensure their code “works,” so many of the problems we find in software are communication, rather than technical, issues. And the further we remove developers from the process of validating whether their software does what the customer really wants, the more the problem gets compounded.

In agile, we seek a better answer with our notion of All Together. One where we all require courage, but where finding that courage is made easier by the safety nets we put in place. If testers are really good at working with completed software to ensure it meets the customers needs, why not just allow them to do this throughout? Let’s skip the separate bug team and it’s test/fix cycle and just get it right the first time.

Testers can work with customers up front, before a feature has been developed. They can dig beyond the stated requirement to learn what it will take for the feature to actually be usable. The criteria by which users will judge it. In the end, success is defined by the software's usefulness to the user, not by its adherence to documents. And so if testers are going to have to figure out how to validate that it meets those user needs, why not figure that out up front – and allow that knowledge to help drive development in the right direction?

The truth is, it’s a waste of testers’ skills and an exercise in frustration to leave them until the end - trying to inject quality into something that’s already built.

So, agile puts testers at the beginning. It gets them involved with the customer, helping elicit acceptance criteria in terms of objective tests. And sharing these with developers so they can design the right solution to build from the start.

And it puts testers in the middle. We talk a lot about having developers testing their own code. Well good! As developers, we should be able to test our own code. But the truth is, most developers haven’t been trained in testing and so figuring out what to test can sometimes be daunting. Why not let testers sit down and pair with us while we’re writing some of our tests? Give us a second set of eyes and help us find techniques for writing effective tests as simply as possible.

And it put testers at the end. Not the end of a release, but the end of a feature. As we integrate our new features, testers provide us with their wonderful safety net of tests to ensure that our software continues working as expected. And since most defects will have been prevented or dealt with by this point, it allows testers to look further. To inspect the software and feed ideas for improvement back into the process we use as we move on to the next feature.

I know that for a long time our industry has believed that to be effective, tests must be independent. But in agile, we value the customer’s opinion as the final say, not some techie’s. So lets allow our testers to instead work with the team and help us move forward with the confidence of knowing that it is within our ability to deliver success.

Where does your project put its testers?
--

» See Agile Testing by Lisa Crispin and Janet Gregory for more information and wonderful ideas on testing in agile.

Plane Crashes, Software Failures, and other Human Errors

2009-05-20T01:31:00.014-04:00

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...

About 80% of all (airline) crashes are caused by human, rather then technical (mechanical) errors. And, in fact, many of these are the result of errors in communication. Okay, this makes sense for software errors, right? We all know how horrible everyone is at communicating with one another. But, it's one thing when the risk of miscommunication is frustrated users. If we put ourselves in a situation where failing to communicate could result in "oh my God, we're all going to die!!" then it seems we'd be able to do just a little better, right?

Let's take the 1982 Air Florida crash in Washington DC that killed 74 of it's 79 occupants plus 4 motorists on the 14th Street Bridge that it struck. The first officer tried several times to tell the captain that the plane had a dangerous amount of ice on its wings, enough to cause all of these deaths. And yet, listen to how he reports the problem:

Try #1: "Look how the ice is just hanging on his, ah, back, back there, see that?"

Try #2: "See all those icicles on the back there and everything?"

Try #3: "Boy, this is a, this is a losing battle here on trying to de-ice those things, it [gives] you a false feeling of security, that's all it does."

I don't know about you, but when I picture myself in a situation where my life, and the lives of 78 people around me, is at risk, I'm picturing a very direct and crystal clear warning and if that doesn't work, screaming, with potentially some jumping up and down and arms waving around. Not "ahhh, see all those icicles back there and everything?"

The captain clearly didn't take him seriously either until at the end when the first officer finally says, "Larry, we're going down, Larry," and the captain responds, "I know it." Crash. Boom. Bam. 78 dead.

But even more amazingly, what researchers found was that this exact problem was actually common in airline cockpit crews. A famous crash in aviation is the 1990 Columbian Avianca 052 crash that slammed into tennis champion John McEnroe's father's estate in New York, killing 73 passengers. The reason? Plane ran out of fuel. Ran out of fuel because it had to go further then expected? No, ran out of fuel while politely waiting for air traffic control at Kennedy airport to give it permission to land. Why didn't the co-pilot just tell air traffic control they were about to run out of fuel? They were trying to be polite rather than pushy. Peace, love and happiness. Have a flower. 73 dead.

Korean Air Flight 801, almost the same exact situation as Air Florida. In trying to warn the captain of severe weather problems that would eventually lead to the deaths of 228 of the 254 people on board, the first officer says, "Don't you think it rains more? In this area, here?" and "Captain, the weather radar has helped us a lot"…

Captain, the weather radar has helped us a lot?! What are these people doing? They're hinting at the impending problem, in hopes that the guy who's a little busy with the whole "flying an airplane" or "trying to bring 99 planes circling Kennedy airport in for a landing" thing is going to catch on, read their mind, and solve the problem for them self. All without losing face. All without getting upset at the hinter for being too pushy or impolite. Wouldn't want any hurt feelings, now would we?

The official term for this is "mitigated speech" and Malcolm Gladwell provides a fascinating account of how it has effected the airline industry in his book Outliers. He defines it as "any attempt to downplay or sugarcoat the meaning of what is being said." and explains that "we mitigate when we're being polite, or when we're ashamed or embarrassed, or when we're being deferential to authority."

Amazingly, this mitigated speech actually explains a major source of airline crashes in the past, and since implementing CRM training to combat it, preventable accidents in aviation have decreased by 50%. And so now the healthcare profession is looking to benefit from it too, because, wow, 44,000 – 98,000 preventable deaths per year!

The crazy common point in both operating rooms and cockpit crews, the thing that makes this all so damning is that research into both fields has shown that errors occur most often when a senior, experienced person is performing. In other words, even in these highly trained professions, it is not just about being skilled or knowledgeable enough – in fact, the more skilled you are, the more it can hurt you!

» In surgery, errors occur most often with experienced surgeons, typically resulting from a breakdown in communications such as a resident failing to effectively communicate vital information (ahh, see all those icicles?).

» In commercial airlines, planes are flown with 2 pilots –- the captain and a first officer –- who split the flying duties equally. And yet, crashes occur most often when the captain is flying. Why? "Planes are safer when the least experienced pilot is flying, because it means the second pilot isn't going to be afraid to speak up." (Gladwell)

And so the question we have to ask ourselves is – can this also be true in software development? Is being skilled or knowledgeable enough? Or can it sometimes hurt us? Do we work in environments where people are encouraged to speak up, to stop the line when they see things going wrong? Or might we have senior team members and managers that are intimidating or difficult to raise issues to? Do we find ourselves hinting to save face in the light of possible problems? Or, perhaps, just remaining silent on issues? (pay no attention to the man behind the curtain).

Part of the research behind CRM found that, even among highly skilled professions, human errors are still going to happen. However, we can compensate for this and drastically reduce the consequences of those errors if we have a team that is effectively communicating with one another. A team where its members, regardless of position, are able to speak up and clearly communicate when they notice a problem. And thus, we don't have to be infallible if we can work with others we can rely on to have our back and catch issues that might miss our attention.

I like this quote from the Nebraska Medical Center, one of the medical centers adopting CRM for their operating rooms:

"The use of CRM creates an atmosphere of mutual responsibility not only for making sure everyone does his or her job, but also for making sure everyone else on the team is informed."
Sounds a little like agile, doesn't it?

I'm curious for people's opinions. Do you think this is an issue in software development? I know us developers can be almost obnoxiously outspoken when we see problems in our areas of expertise... but what about when we see problems in the areas we may not consider ourselves "the expert" at?

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

2009-05-08T13:20:00.009-04:00

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

Beautiful Teams

2009-04-28T10:00:00.009-04:00

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.

We were, in fact, certifiably bad-ass in the sheer amounts of innovation we were able to deliver. We had this amazing VP of Engineering who would come in and tell us we were going to do these absolutely insane things and we’d all look at her like she’d finally lost it. But then, the craziest thing would happen and we’d actually find a way to do them.

But then… one day, it became not so hot. We grew big enough to need a “real” CEO, and with him came a team of “real” business executives. And these business folks thought they knew all the answers and so before we knew what was happening they’d booted that VP of Engineering – the absolute heart and soul behind our software – right out the door. They brought in a new VP who told us that he thought perhaps our reputation “exceeded” us, and you can just imagine the developers couldn’t find the exit door fast enough. And, of course, nothing was ever the same after.

What happened?! How could we have created such greatness? And then, how could it be ripped away from us so easily?

In software development, we give a lot of weight to the practices we follow – is your project agile? Are you doing TDD? Continuous Integration? Daily Scrums? And it’s not that these things aren’t important. They’re extremely important. But, the thing is that they’re not most important. And, when you stand them up next to what is most important – the people and the teams – it really puts them in perspective. We weren’t doing any of these things in our hey day and yet it was by far the most productive team I have ever – and probably will ever – have the pleasure of working on.

On the flip side, how many of us have been on teams where we’ve been handed a whole laundry list of “best practices” we must follow and have found those to be the most miserable, ineffective teams we’ve ever worked on? How does this make sense when we’re talking proven practices that are considered the best our industry has to offer? And I would say they were doomed from the start when someone decided they had so little respect for the team that they felt the need to dictate those best practices to us rather than giving us goals and training and having enough respect for us, the team, to find our own best practices.

And when I think back to that great startup, that’s exactly how it was. Sure, the goals were out there – seemingly impossible pipe dreams. But we were given time and space to learn what we needed, and the autonomy to figure the best way to achieve those goals on our own. That, and a wonderful, brilliant set of people, and we were unstoppable.

There’s a lot of recipes for successful teams in Beautiful Teams. But for me, personally, I can’t help but think the #1 factor – the thing that trumps all else – is simple respect. And it is a wonder that we put so much time and energy into buying the right books, going to the right conferences, reading the right blogs if we’re going to ignore this most vital component of software development. Just like Soylent Green, that secret ingredient -- It’s people!

What was the best team you ever worked on? What about the worst? What do you think made them so?

Update: Abbot of Unreason answers these with his own stories of beautiful teams in Coding Cats. Check it out.

Scrum: A Framework for (Finding) Failure

2009-03-02T10:30:00.013-05:00

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.

"Of course," the man laughs. "Now imagine that your mother-in-law believed her daughter could do better," Ken proposes. "And then imagine that she moved in with you. That’s what Scrum is like."

You see, the other thing about complexity is that it’s really hard (as a customer of mine recently reminded me). No matter how smart we are, we’re still going to get some things wrong – either because we misunderstood, or the conditions of success changed, or just because that’s what it means to be human rather than a machine. And so which is more helpful? A process that pats us on the back and tells us everything is going to be just fine (see, it says so right here in the plan!)? Or one that provides us with immediate feedback when we get something wrong?

Think of the red x’s in our IDEs that show us errors before we even request a compile. Or, the squiggly red underlines letting us know that "squigly" is misspelled (it has 2 g’s). It may sound counterintuitive, but if we can be notified of what’s wrong before we even think to ask; in a simple, non-intrusive manner, it allows us to to correct problems so easily that we hardly have to stop and think about them. Before those errors can domino out to impact other, larger things that are harder to fix. Before incorrect assumptions can kick off a trail of bad decisions. Before they grow to be complex problems in and of themselves that require massive amounts of rework and frustration.

Our goal is not to avoid all errors in software development (the mere act of creating new things requires a process of trial & error). But rather to spot them as quickly as possible, before they become a problem. Scrum is not as automated as our IDEs or text editors. But then, building software is a lot more complex then just banging out code or documentation. It requires really hard things like understanding what the customer wants. Which, of course, is never the same as what they say they want. So, there’s a bit of mind reading involved, which can be rather challenging. And then there’s making sure our code works. Not just on its own, but also with other people’s code, which of course is never as good as our own, so that’s a challenge as well.

So, we have these really hard parts in software development – and they’re mostly the parts that involve other people. And since we can’t just pull out our red sharpies and go around marking red X’s on people’s foreheads when they do things we don’t like, we have to find a different approach. In Scrum, we do this by putting a framework into place that makes detection of errors as automatic as possible:

1. Scrum forces us all to work on the same pieces at the same time until each piece is completed to everyone’s satisfaction. This is done quickly and efficiently – the pieces are time boxed to fit into sprints that are, at most, 30 days in length. So, if there is an error or misunderstanding (you wanted the software to do what?!), it will be caught while we are working on the item. Each sprint produces production ready software, so we can move forward with confidence, knowing that we can reliably build upon what’s already in place.

2. We can’t automate error detection in human communication and understanding, so Scrum builds in human inspections at regular intervals that are designed to catch these types of errors as quickly & non-intrusively as possible:

Each day, we inspect our progress towards meeting our commitments in the Daily Scrum.
Each sprint, our customers inspect what we’ve developed against the product they want at the Sprint Reviews.

I say non-intrusively because in Scrum, these inspections are done as such a natural part of the process that they become second nature, like those red squiggly underlines (hey, something is wrong here if you’d like to fix it).

And so, Scrum’s benefit is not that it tells us how to do things. But, rather, that it recognizes that only the team is in position to adapt and respond quickly enough to the unknowns and changing variables in order to drive the product to success. Scrum instead focuses on ensuring that feedback is always available to keep the team on track; moving in the right direction, closer and closer to their target.

--
Ken says when people do Scrumbut (We’re using Scrum, but… we don’t do X), the "but" often removes the parts of Scrum that expose problems (we’re doing Scrum, but… we don’t do Daily Scrums every day), thus defeating the purpose of Scrum. Does your project do Scrumbut? Does your but negate your Scrum?

Craftsmanship and Ethics

2009-02-14T14:00:00.003-05:00

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

2009-02-03T09:00:00.009-05:00

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.

"I believe if you have a function that, in certain scenarios, completes all of it's required processing before it's reached the end of the function block, then by failing to return at that point, you're:

a) risking the chance that additional processing will incorrectly occur, and
b) forced to add if/else nesting to ensure your function's additional processing does not occur for this scenario.

As you eluded to, the additional nesting of if/else blocks makes the code harder to read and more difficult to maintain, thus increasing the likelihood of errors and the amount of effort to maintain it.

But the worst part is that if you're setting a value and you choose - even after setting the appropriate value for this scenario - to keep processing, you risk inadvertently changing the value from the right one to an incorrect one. Honestly, this is how I was taught to code (always prefer a return an else{}), so I've never really understood the justification to continue processing after you're – well - done!"

It's like continuing to loop through a list after you've already found the value you were looking for. What's the point?

Bob Martin also addresses this in Clean Code, stating that while it was good practice at one point, that doesn't mean we should just blindly enforce the rules of structured program in today's object oriented world:

"Some programmers follow Edsger Dijkstra's rules of structured programming. Dijkstra said that every function, and every block within a function, should have one entry and one exit. Following these rules means there should only be one return statement in a function, no break or continue statements in a loop...

While we are sympathetic to the goals and disciplines of structured programming, those rules serve little benefit when functions are very small. It is only in larger functions that such rules provide significant benefit. So, if you keep your functions small, then the occasional multiple return, break, or continue statement does no harm and can sometimes even be more expressive then the single-entry, single-exit rule."

What do YOU think about multiple returns? Good programming practice or devil spawn?

The (Schedule) Games Managers Play

2009-01-22T01:55:00.012-05:00

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.

Here's the first game she described - stop me if this sounds familiar:

     Manager: How long will this project take?
     You: 3 months
     Manager: Can you do it faster?
     You: Well, maybe... if we got another developer we might be able to finish it in 2 1/2 months
     Manager: Can you do it faster?
     You: Um, well, maybe, if everything goes perfectly, it's possible it would come in a few days earlier
     Manager: Can you do it faster?
     You: No.
     Manager: Well, what can you give me in 1 month?

This, my friend, is the Bring Me a Rock schedule game and it has been the cause of many a management cursing.

Her suggestion: turn the conversation around. At that very first "can you do it faster?" explain to the manager what they get for that 3 months. And then, if they continue to ask, explain what they'd get for 1 month. Features cost time. The more time you're given, the more features you provide.

Somehow, while we all understand that side of the equation, we get kind of stupid on the flip side and decide that while more time == more features, less time == we just have to find a way to go faster.

Bzzzzzzt! Wrong answer.

Less time == less features, no matter how optimistic we happen to be feeling at the moment. So, instead of "well, maybe we can go faster", explain what complete, quality, production ready functionality can be delivered if the time is chopped in 1/2 or 1/3rd. I know, this can feel like an impossible task if you're thinking in terms of complex functionality that requires months worth of work to complete. So instead, think in terms of small features or user stories - what complete user stories could you deliver in that time? Specified, designed, developed, tested, production-level quality stories. What stories can you complete in 1 month? 2 months? 3 months? Ask the manager for a prioritized list so you can work them in priority order and get through as many as you can within the time period given.

Whereas in the first scenario, you've hidden the downside to less time ("we'll just work faster") and so, of course, there is nothing but upside to the manager in asking for less and less time. In the new scenario, you've made the tradeoffs visible to the manager and you've given him control to not only select the balance that makes the most sense from a business perspective, but also to prioritize the order that will provide the most value. Smart developer, smart manager.

Of course, as we see, it takes a bit of work to get to the smart side of things. Here's a few more games Johanna described - let me know if you've heard them before:

We've never done anything like this and we totally don't have the experience/resources/training/knowledge for it, but that's okay because we really think we can do it! -- Hope is our Most Important Strategy

You may think it's impossible, but I have faith in you, I know you'll find a way!
-- Queen of Denial

Even though it has absolutely no relation whatsoever to our product schedule, we just HAVE to release something on this particular date because <insert silly reason here - e.g., "It's the boss's birthday!"> -- Happy Date

Even though you had absolutely no input into this schedule, this is THE SCHEDULE and therefore, you will be held accountable for it. -- Schedule == Commitment

If you're like me, you hear these and panic. Oh my God, how will I ever make it work?! And, like the "we'll just go faster" answer, all this does is to force the team to shoulder an unreasonable burden while completely hiding the problem from the manager. No downside to manager, so manager keeps pushing. Stupid manager, pissed developer.

So what do we do instead? We start by recognizing these for what they are. Recognize that they're not reasonable. Recognize that it's the managers job to make the project successful, not doomed to failure. And, recognize that in all likelihood, the manager really does want to make the project successful - so helping them once again become smart manager by presenting options that can work.

Want to take on a project we know nothing about? Let's not just blindly assume we know all the answers up front and just Hope everything will go right (read: Waterfall). Instead, let's do some short, time boxed iterations that run through a "Hello, World" equivalent of the project to try to gather more information about what the work will entail and what issues and questions we'll need to address moving forward. Let's be flexible and follow a process that can accommodate the continual changes we're going to run into as we learn more about this new area.

Got a flaky senior executive that likes asking for releases on random dates? Work in short iterations that always result in production-ready product so that you can be ready to deliver at almost any time.

I don't know why manager's play games. Of course, developers play games too. Maybe its just our knee jerk reaction to the ridiculous levels of complexity we have to deal with. It seems so much easier to Deny the facts, declare a Happy Date and Hope beyond hope that it will work because the Schedule says it will. But then, of course, there's reality...

What schedule games do you play on your projects? And how do you deal with them?

Why You Should Let Your Developers Surf

2009-01-12T17:43:00.016-05:00

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."

In Alan Shalloway's Lean Online Training, we're learning about the Myth of Optimization Through Decomposition, which states that trying to go faster by optimizing each individual piece does not speed up the system.

In the physical world of manufacturing, attempting to run every single machine at 100% utilization results in large piles of unfinished product just sitting around waiting to get through the next step of the pipeline or for a buyer. These unfinished products incur significant costs in terms of inventory and storage. And, whenever the product line is changed or stopped, whatever is sitting in that pipeline winds up being thrown away. This is why physical operations do best when they use a Just In Time strategy -- creating only what they need and no more. It turns out that operating each machine at 100% utilization is actually a really bad business decision.

In the world of software development, the parallel to running every machine at 100% utilization is making sure every employee is busy 100% of the time. And, just like in the physical world, this results in large amounts of unfinished works in progress that incur significant costs and risks. Knowledge degrades quickly, requirements get out of date, the feedback loop is delayed so we don’t learn what we’re doing wrong. The result is unfinished, untested, misunderstood, and often flat-out unnecessary code bogging down our product, degrading its quality, and, actually slowing us down.

• It's difficult implementing a feature that was specified so long ago that no one can remember what it's for.

• It's hard tracking down an error in code developed so long ago that no one remembers how it was implemented.

• It's slow adding new features when the software is muddled with unfinished, untested code (that isn't even needed!).

Thus, Lean teaches us that striving for 100% utilization is not the answer. It doesn't get the product completed any more quickly, and the only thing it creates is waste.

The only way to go faster is the optimize the whole. In other words, find your bottlenecks -- the things that are slowing down the process, incurring delays, and adding waste -- and remove those. And when you do, a funny thing happens, it lets your developers work faster! They're happier, you're happier, and ultimately the customer is happier.

Jeff Sutherland describes this nicely:

"The task then is to refine the code base to better meet customer need. If that is not clear, the programmers should not write a line of code. Every line of code costs money to write and more money to support.

It is better for the developers to be surfing then writing code that won't be needed.

If they write code that ultimately is not used, I will be paying for that code for the life of the system... If they went surfing, they would have fun, and I would have a less expensive system and fewer headaches to maintain."

So let's take their advice and stop wasting our time trying to speed up the things that are working (e.g., writing code against understood requirements). Let's, instead, spend our time minimizing or eliminating the things that aren't working. Our goal should be to spend 100% of our working time on productive & useful things, rather than to spend 100% of our time working in the Wally fashion of equal parts work and anti-work.

--
With thanks to Alan Shalloway & NetObjectives for the fantastic free Lean Online Training they're providing as well as the most excellent chapters of their upcoming book on Lean that they've made available on their web site:

» Lean Software Development: Scaling Agile to the Enterprise (free online!) by Alan Shalloway, Guy Beaver, Jim Trott

Deep Agile - Ya Know, Like Teenage Sex

2008-11-12T11:00:00.004-05:00

Because, apparently, their 30 minute debate on TDD was insufficient, Agile Bazaar invited industry leaders Bob Martin & Jim Coplien to continue the discussion over an entire weekend of old sk00l learning at MIT. And so, as 90 of us gathered to hear them out, they kicked it off by explaining why agile is so damn hard. You see...

Agile development is like teenage sex.
Everyone says they're doing it, but only 10% are.
And those who are -- ARE DOING IT WRONG.

Don't believe it?
Take the Agile Machismo test - industry scores range from -4,000 to about +20.

And even for those following the practices - what have we learned? According to Coplien, 70% of Scrum implementations fail, pair programming fails 50% of the time, TDD deteriorates our design, on site customers demoralize the customer and the team, and agile retrospectives have actually been proven to make projects worse.

Phew! So why do we bother?

Pan to Uncle Bob... fast forward 15 minutes past the discussion on how the universe was formed...

Paying the bills is hard! But NOT paying the bills... is harder.

Doing the dishes is hard.

Scraping the hardened CRUD off after several days so we can have clean dishes to make our next dinner - is harder.

Agile, then, is the software equivalent of doing the dishes. It's our admonition to pay the bills.

It's hard. But not doing agile is harder.

Sure, there are a lot of practices in agile. And, depending on your persuasion - XP, Scrum, Lean - they may all be a little different. But, one thing Bob and Cope both agreed on was that agile is not about the practices. Agile is NOT TDD (regardless of your views on its goodness or badness). And agile practices are not a substitute for thinking.

As Uncle Bob and Cope leapt up to perform an impromptu martial arts move in eerie synchrony, they spoke to how the practices in agile - like those in martial arts - are only the starting point, the building blocks, from which we learn. If you're caught in a fight, you're not going to repeat each form you learned in perfect order while your enemy bows and gives you space. You're going to use the principles you've learned from years of practice to figure out the best moves to make.

And so it is with agile. The religion has to die. XP, Scrum, Lean, these are just sets of practices - good ideas that people have assembled. Scrum is filled with great ideas for creating successful teams, but if all you do are assign the necessary roles and hold the prescribed meetings, you're missing the point.

Testing can positively influence your design. But it still takes strong design skills & knowledge to do a good design. Even Jim concedes that unit testing can be helpful for tactical decisions, but they both agree it's no substitute for architecture.

Per its manifesto, agile is about uncovering better ways of developing software by doing it and helping others do it. If you just take the practices, with no consideration for the underlying values or how to make them work within your organization, then you -- like all those teenagers -- are doing it wrong.
--
» Deep Agile 2008

Just Say No to Nulls (or Refactoring Your Way to Programmer Bliss)

2008-10-27T12:10:00.016-04:00

I can't help but feel my code is getting harder and harder to read as I wade through an ever increasing number of if != null checks before finding my way to the real logic that I actually care about...

God, doesn't your brain just want to shut down even trying to look at it? I've been trying to manage this by creating an endless number of private methods whose sole purpose is to check for values in a null safe way. This at least makes my public methods easier to follow so that I can understand their logic...

But, man, now there's even more code and all I'm doing are a few simple checks.

Doesn't it feel like there has to be a better way?!

Well, actually yes, there is.

Stop allowing any of your methods to return nulls.

EVER.

No nulls returned, no null checks necessary. Thank you for reading.

Oh, you're still here. Yeah, that's a little easier said then done, isn't it? Particularly if you're working on existing applications with thousands of lines of null returning code. And let's not even get started on 3rd party libraries.

The problem, of course, is that if we only manage to remove some of the null returns, developers are going to have to remember which methods can return null and which ones can't. And the first time they're hit with our favorite NullPointerException they're going to go "shit!" and start adding those if != null checks all over the code again.

And so, it starts to feel like an all or nothing scenario to get out of null check hell. Either we prevent ALL of our methods from returning null and ascend into programming bliss. Or, we're stuck with those damn null checks.

Well, the good news is that when it comes to code, improving even one small element tends to exert a positive influence on our overall design. And so, even by tackling some of our null returns, we actually end up with better, easier to maintain software. And, if we're able to do it in a structured way -- say, a policy of fixing NPEs by changing the method to not return null rather than inserting an if != null check, or taking our most heavily used component and just removing all null returns from it -- then I think we can alleviate some of our brain pain.

So, okay, where do we start?

The worst culprits are the getter methods that return objects. When we have classes that return instances of other classes, which in turn return instances of yet other classes, pretty soon we wind up with a lot of method chaining

myObject.getFoo().getBar().getName().rhymesWith( "Banana" )...

and this is the worst thing we can do because there isn't even anywhere to squeeze a null check into there.

The truth is, when we find ourselves wading through endless object hierarchies such as these, that there is what we call a code smell. And it's a pretty good indication that we might want to revisit our design. A true OO design is composed of nice little well behaved classes that expose methods we can call on to have them do things for us. These classes abstract the nitty gritty behind the scenes details and just do it (often without the need to return any value at all).

dog.bark() not dog.getAnatomy().getVoiceBox().EmitSound( "woof" )

This is a great opportunity to see if we can't remove some unnecessary code and complexity with a bit of encapsulation. Is it possible that the parent object can just take care of what we need without showing off how the sausage is made? If so, believe me - not only will we thank ourselves the next time we need that functionality, but so will the other developers. And, look ma, no null returns!

If not (or maybe we're just not prepared to go quite that far at the moment), we can still ask ourselves if we really need all those getter & setter methods in the first place. Ctrl-Shift-G is one of my favorit'ist ever hot keys in Eclipse (and Resharper's equivalent in Visual Studio). Sure, we know it's bad design to make our instance variables public. But, are we really gaining that much when we make our variables private but then turn around and blindly provide public get/set methods for each and every one of them?

If we can lighten our code by even a few methods, not only are we removing some of those pesky null returns, we're also reducing our maintenance costs by removing unneeded code. And that's a Good Thing.

Of course, even after all of this cleaning, we'll still have some methods that just want to return null. But, even so, a lot we can handle by simply returning an empty instance of the object or collection where we previously would have returned null. Sure, it still requires an if != null check in the get method, but we've at least moved that check to a single location rather than letting it perpetuate throughout the code. And this too is a Good Thing, so we're making our code better as we go - even if it's 1 tiny method at a time.

What is your project's policy on returning nulls? When you get a NullPointerException, do you fix it by adding an if != null check? Or by altering the method to stop returning nulls?

How would you like your code? Refining our Definition of Done

2008-10-15T11:00:00.007-04:00

Agile has a notion of defining "done." This might sound funny - how could we not know when something is done? But, as with any creative endeavor - there is "done" and then there's Done.

Just try it - ask 5 different people on your project how they determine when a development task is "done" and, as the saying goes, you'll get a lot of different answers. But, while this might be an interesting exercise, if you really want to understand the problem, don't just ask them what is meant by done. Instead, look and see what they're actually passing off as done.

On my current project, it seems pretty clear that the management - if not through their words, then through their actions - has defined "done" to mean that code was checked in and a little checkmark was placed in the "Done" column for that task.

This makes all of the management's schedules and reports up to their management look nice and tidy. Give yourselves a pat on the back, "well done, Bob!"

On the other hand, this makes the code look like a bloody mass of ... well, you get the idea.

In management's defense, the managers aren't developers and even if they were, there's way too much code for them to dig through to determine if it's really production ready or not. Why shouldn't managers be able to rely on their developers' word for when something is done?

In the developer's defense, they are working from outlandishly unrealistic schedules and whenever anyone tries to explain that more time is needed they're rewarded with a management gem such as "well, it's just got to be done by that date because that's when we go live."

So the developer's, God bless 'em, tried their best to meet those deadlines - because why shouldn't developers be able to follow their manager's direction? At the very first sign that the code seemed to be working, they checked that puppy in and moved on to the next task.

The results are reminiscent of one million monkeys typing. You know the type - amorphous blobs of stuff that aren't even sustainable enough to get us to an initial release of the product. One step forward, two steps back.

And I just keep thinking back to Clean Code's preface: if we're to call ourselves professionals, we have a responsibility to act as such. And maybe that means we really do need a 5th element for our Agile Manifesto:

We value Craftsmanship over Crap

meaning that we need to value the craft of building software to last over the mad rush of delivering the first solution we think up that appears to work. Sure, managers and customers are always going to try to squeeze the last dime of productivity out of us - that's just human nature. But what it really comes down to is that we, as developers, are the ones that ultimately say when our code is done. We are the experts that management ultimately relies on to tell them what is needed. And every time we agree to deadlines that don't allow us to do our jobs, every time we proclaim our work as "done" using crap rather than craft as our measuring stick, we're failing to live up to our responsibility.

What do you think? Who defines done on your project? How do you think it should get defined?

The Future is Now!

2008-08-23T12:51:00.025-04:00

If you want to build the kind of science fiction, futuristic GUIs that only exist in TV and movies (think: Minority Report) then you want to be looking at Windows Presentation Foundation (WPF).

WPF is Microsoft's next generation API for developing applications and it's possibilities really start to shine through when you look at Microsoft Surface, which was developed entirely with WPF and the .NET Framework.

The idea behind Surface is that any surface - vertical or horizontal - can be made so that you can interact with it in a very direct and natural way.

"We used to say a computer on every desktop and now we say every desktop will be a computer" -- Bill Gates

This notion of interfacing with a computer through touch and gestures rather than mice and keyboards is all part of the next generation of user interfaces - termed "Natural User Interfaces" or NUIs for short (pronounced New-eee, like GUI with an "N"). The idea is that we began with Command Line Interfaces (okay, we began with blinkin' lights, toggle switches, and punch cards - but...), progressed to Graphical User Interfaces, and we are now entering the next stage of this evolution.

"The last 30 years of computing have been about people learning the language of computers. The next 30 years are going to be about computers learning the language of people."
-- Daniel Makoski, Interaction Design Manager, Microsoft Surface

There is this notion that content is the interface. That you can just walk up and interact with it. And even if you don't have a $10,000 touch screen wall, WPF provides a whole new way of designing user interfaces on today's PCs that allows you to break free from the old paradigms.

» Screens are rendered with a Painter's Algorithm, which you can think of as a canvas upon which any element in your application can draw. Any shape is allowed, so say goodbye to yesterday's rectangular windows and controls. And any element can add to the layers beneath it, allowing you to render 3D scenes on a 2D surface.

Imagine if photos didn't have to be stuck in an unnatural row of perfectly spaced rectangles. You could scatter them across the "table", spin them around, group them so they overlap one another just as if you were handling the physical versions.

» All types of content - text, images, video, audio, 3D graphics, documents, etc. - are treated as 1st class citizens within a WPF application. They can respond to user input and issue commands, moving us away from PC constructs like buttons and menus, and towards the more natural model where content is the interface. WPF intrinsically supports things like 3D objects as "buttons" (imagine a spinning globe you can navigate and zoom in to find your destination).

» All content is rendered as 3D. This means you can apply transformations and animations to any object, allowing objects to respond to users just as real world objects do. Imagine a 3-Dimensional object moving just slightly when you touch it. It suddenly becomes more tangible than a static 2D image.

» WPF is vector-based, meaning that all drawing is done through mathematical algorithms rather than dots per inch, providing us with perfect scalability of our content (obviously, bitmaps not withstanding) as we zoom in and out.

This allows us to present information in an entirely new way. Imagine how we work with documents in the real world. If your desk is like mine, you've got papers scattered across it and stacked up in piles that others might call messy, but, of course, we like it because we know where everything is. Now, imagine a "project" on your computer that's made up of text, spreadsheet data, images, audio and video where you can seamlessly navigate between all of the different components, zooming in on the areas you want to focus on, then zooming back out to a view that allows you to see what else is in the project. Just like you could do with the papers on your desk, but with the technological perks of rich media, in place editing, and whatever other nifty tweaks us developers can think of.

So, okay, maybe the future is still tomorrow, but I think we've got some very exciting things that we can do today to move us in that direction. And, if nothing else, there is the hope that...

"One day, your computer will be a big ass table" -- Sarcastic Gamer.
--
Check it out:
» Microsoft Surface - check out their videos to see it in action
» Microsoft Surface Parody by Sarcastic Gamer - because we still love making fun of Microsoft
» WPF Bootcamp - Learn WPF with Microsoft's bootcamp: 3 days of training videos and hands-on labs. Awesome stuff!
Bootcamp '08 Video of the 2008 training. Highly recommended, but the labs aren't on-line yet.
Bootcamp '07 - Includes hands-on labs from the 2007 bootcamp you can use to augment '08 training.

Clean Code

2008-08-13T15:23:00.015-04:00

Bob Martin's new book, Clean Code: A Handbook of Agile Software Craftsmanship is finally out and the UPS man just dropped a shiny new copy on my doorstep. It kicks off with these fine words of wisdom:

"The only valid measurement of code quality: WTFs/minute"

Thought I'd take you with me on my quick skim in case your UPS man wasn't as nice...

Chapter 1 begins with "You are reading this book for two reasons. First, you are a programmer. Second, you want to be a better programmer. Good. We need better programmers." Includes sections like The Total Cost of Owning a Mess.

The Functions chapter earns bonus points for its opening image of the hookah-smoking caterpillar from Alice in Wonderland. I'm not quite sure what Uncle Bob is suggesting here, but this chapter includes goodness to the likes of Have no side effects, Prefer exceptions to returning error codes, and classic Uncle Bobness such as:

"Functions should do one thing. They should do it well. They should do it only."

The Formatting chapter explains how to avoid "a scrambled mass of code that looks like it was written by a bevy of drunken sailors" (hmm, I think I've seen that code before). And the Objects and Data Structures chapter (which starts with an image of Data from Star Trek - I swear I couldn't make this stuff up) has some interesting looking sections like Data/object anti-symmetry, The law of Demeter, and Train wrecks.

The book talks about Emergent Design (Simple Design Rule 1: Run All the Tests, Simple Design Rules 2-4: Refactoring) and, of course, the principles of good class design. It covers exception handling (written by Michael Feathers, very cool), dependency injection, aspect oriented programming, concurrency (including thread-safe collections and testing threads), logging, unit testing (including JUnit internals), and code smells & heuristics.

And just gobs and gobs of code examples. The back of the book promises that readers will come away with:

» How to tell the difference between good and bad code
» How to write good code and how to transform bad code into good code
» How to create good names, good functions, good objects, and good classes
» How to format code for maximum readability
» How to implement complete error handling without obscuring code logic
» How to unit test and practice test-driven development

You can find the complete table of contents on Bob Martin's Clean Code, Whew!

Agile as the Path to Happiness?

2008-07-22T09:00:00.004-04:00

This might be a sign that I'm working too much, but I keep finding myself making analogies between agile software development and how I want to be living my life.

As strange as it sounds, I think it stems from how crazy life can be and how agile seems to have found some good tricks for taming the chaos. Agile methodologies are, after all, built to deal with the high levels of change and uncertainty in software development. And, let's face it,

software's level of change and uncertainty ain't got nothing on life

Agile says screw waterfall because we don't even know all of the information up front to enable perfectly detailed, fail-proof plans. And even if we did somehow bizarrely know everything there is to know about what needs to get done, the world around us is changing so quickly it'll become out of date (read: wrong) almost immediately.

So, striving for perfection is futile because:
a) we can't even define perfection, and
b) even if we could, that definition would change before we could achieve it.

If we foolishly listen to conventional wisdom and find ourselves going down this path, our only option will be failure.

What we can do though is figure out one small piece of the puzzle that we do know today and quickly go implement that before it changes. Wasting time with a bunch of formal plans and high ceremony is counter-productive at this point and just as likely to make us fail as it is to help us. And who wants a bunch of plans and documents anyway? Wouldn't we rather working software that we can use?

Or, in life… (this post was supposed to be about life, wasn't it?), I want to have achieved some small measure of happiness by accomplishing or obtaining or getting to experience that one thing that - even if small - is giving me something that I'm confident I want.

What do you think? Is it time for a mandatory vacation to the loony bin? Or is there maybe some wisdom in agile that can extend beyond banging out code?