Requirements, people, and monsters (part 2)

Requirements. There is an ever growing, massive pile of requirements. This pile threatens to crush the development team under its weight. The agile movement taught us how to deal with this. Well… before that life taught us how to deal with this… one step at a time. The key to dealing with the pile of requirements is focus.

Planning Game

The planning game is one of the main ways to tame the requirements. First it does this by breaking the pile down into a few piles. Talk with the project sponsor about the requirements. Divide them into three buckets:

• items essential for launch

• items that are very important

• items that can be postponed

The names of these buckets are adjusted to accommodate your current project sponsor. The only important thing is that roughly two-thirds of the requirements are moved into a category of things “not to work on”.

Now apply this process iteratively. Take the remaining pile of “essential” items and continue breaking it down into sets of three buckets until the remaining items is small enough that you feel your sanity restored. This should be a couple of months worth of work.

That is the first key to the planning game, it is a form of triage that allows the team to focus on the essentials. The second aspect is related. Divide the essential elements into a series of very small releases, or iterations. Choose an iteration length of one to two weeks and layout the essential requirements into a series of iterations.

As much as possible have the project sponsor make the decisions about what features go in which iterations. The most important aspect of this part is to have the project sponsor make the changes to the iteration schedule. Give them a quota for how much can be in each iteration and then place the burden on them to arrange the requirements such that there is not too much in any one iteration. This is key because it creates a mechanism for the painful truth to be communicated directly to the sponsor. The truth is that 6 days of work cannot be crammed into 5 days.

If the game is setup correctly the sponsor feels this truth as a direct consequence of their actions, not as some arbitrary bad news that the development team has to tell them. So if the sponsor puts five more requirements into the next iteration then they should see that they need to remove five requirements in order to “make it fit”.

Iterations

Regardless of whether you can make the planning game work, iterations are essential for dealing with the pile. Take a tiny set of features from the pile and focus exclusively on them for a week or two and get them done. That is the essence of surviving and conquering the pile. (If you have a steady stream of support issues then leave room for this in your iteration plans.)

Successfully completing each iteration becomes the defining rhythm of the team. It is the basic stroke of the development engine.

Checklists

Completing iterations provides vital motivation to the team. But we frail humans need to be rewarded more often than once every week or two. We need daily reinforcement. So break the features for an iteration down into smaller steps that can be completed in a few hours. Get these listed for all of the team to see. Now developers can feel the satisfaction of crossing something off the list every day. Crossing items off of the list assures the team that the pile is being conquered.

So the team can survive the crush of the pile by dodging it. Don’t try and carry the weight of all of the requirements. Let the weight rest on the ground. Instead take on small parts of the pile at a time. Always take an amount that you can do and you build a pattern of success day after day, week after week.

Resolio signup

Resolio, our tool for making web resumes, is marching forward towards launch. If you want to be one of the early users then signup to be notified when the service launches.

Requirements, people, and monsters

Software development projects are dominated by three complex systems. First there are the requirements. Not just a few requirements but a massive mountain of requirements:

And it is a dangerous mountain that threatens to come tumbling down as an avalanche:

Crushing the development team. The second system: the team. A group of people. And that is their distinguishing characteristic. They are people. Weird people, creative people, confused people, confusing people, thinking people. That is the source of both their great annoyance and their charm… they are people:

But the people are not alone, they have built an application. They have created a monster:

A monster that requires constant care and feeding. A monster that occasionally goes on rampages threatening life and limb and demanding immediate attention.

That is the dangerous world we live in. A bunch of people under threat of being crushed in an avalanche of requirements and living with a monster. Sounds like fun, eh?

Invest $20 in a RentACoder experiment

If you are a developer you need to experience what it is like to use RentACoder to buy code.

Here is what you do:

• Think of a little piece of code you want written. Think of something you would pay $20 for.

• Write a one page spec for what you want.

• Create an account on RentACoder. This is a bit painful, particularly the part where they validate your financial credentials. But hey, no pain, no gain.

• Post the spec on RentACoder, watch the bids come in, pick a likely looking developer, and have them code it for you.

Here is why:

• Learn what developers around the world will code for $20.

• See what kind of code your competition produces.

• See what it is like working with a developer. What does the developer do to help make the effort a success or a failure?

• Experience buying software development services. Most coders spend their lives coding, but never get a chance to buy coding services. Experiencing the buying side will help you know how to relate to your buyers better.

If you are serious about your craft of programming it is well worth your time, and money to do a RentACoder experiment. Think of it as a bit of market research. It is guaranteed to open your eyes in some ways.

Give it a try and post a comment back here to let me know what you learn!

3 questions to ask about a programming language

I often come across ad-hoc mini-programming languages. For example, a scripting extension to an app or even something like CSS. When I am introduced to one of these mini-programming language I try to remember the basic elements of programming as described in the Structure and Interpretation of Computer Programs.

Ask the questions:

• what are the primitives - what are the basic things the language does?

• what are the means of combination - how do you put primitives together?

• what are the means of abstraction - how do you create a new primitive from combinations?

Asking these questions leads very quickly to a clear understanding of the power or the limitations of the language. If the language falls short, these questions provide a framework for crisply describing the problem. Moreover, if you are designing such a mini-language (which is a bad idea) then these questions will focus your attention on providing a powerful solution.

10 (or so) tips for learning a new programming language

The first time you hear about some new programming language you have a big, empty, black space in your head. That is your ignorance. The new language is foreign, unknown, a dark void. Learning the language is all about dispelling the darkness in your head and to replace it with a mental model of how the language works. You must cast the light of knowledge on the subject. Here are techniques I use:

Get your hands on it

You may have all sorts of intentions to learn something, but if you don’t have it then it is hard to learn. So first go download the thing you want to learn. You need to be able to hold it in your hand, look at it, and then you can consider actually using it.

Make it do something

This is the classical “hello world” program. The point is to make the language do something, anything. The broader lesson is to choose some initial tasks and make the language do those things. You must start to assert control. You don’t need to write perfect code or even good code at this stage. You simply need to make the system do something. This is the first glimmer of light in the darkness.

Study history

Find out where the language came from. Go back and find the original source material to understand the history of the language. Why was it first created? What kind of problems was it designed to solve? This will help you understand its strengths. What languages influenced its syntax? Does it have a C heritage, a Perl heritage? What accidents of history are responsible for you ever hearing about it (how many languages are created that nobody ever knows about)? Don’t be content to read some distilled version of the history. Look for the original, definitive source that puts the language into context. This is a beginning towards understanding the nature of the darkness.

Browse

Google, flip through books, look at the language source code, visit mailing lists, look at different products. Spend some time just exploring all the different kinds of information there are about the language. At this point you can’t remember much of it, but you will pick up some tidbits, you will start to get a feel for some of the main issues, and you will discover good resources to learn more. Many of these sources will give contradictory and just plain wrong advice, so don’t believe everything you read. This is not so much shedding light on the subject as it is shopping for places to get light.

Read the spec

Find the manual. Don’t just read some magazine articles about how an API works. Find the actual spec or API docs. Find the definitive source that says how it works. This is your map in the darkness. Find the definitive reference materials and keep them close at hand.

Identify the masters

Explore the language community enough to find out who the recognized “masters” of the language are. These could be the people who created the language, but they must be the people who are publicly putting the language to the best use in building real systems. These are the people who define the programming idioms that are characteristic of the language. These are the people who are setting the standard for how to best use the language. Find a guide for the journey into the dark.

Read the writings of the masters

Read what the masters have to say about the language. For .NET this means reading Jeff Richter For C this means Kernighan and Ritchie For Smalltalk you need to read Kent Beck

The main point is to read the good stuff. Don’t content yourself with reading some third-hand story on a miscellaneous web site. Once you learn the language better then you will be in a position to sift through such material, but it can’t be your main source. So by all means browse the web and read all kinds of stuff, but you must look to the experts for your primary education. Follow the master guide into the darkness.

Build something yourself

You can read books and tutorials all day. What the author does will make complete sense. “Of course” you will say… to make blue text appear on the screen that is obviously the right command to use. The problem is that your brain tricks you into saying “of course” to the answers you are given. What you need to do is to try and make the language do something of your own design. So what if you want green text and what if you want it to be tilted at an angle? Well… the book doesn’t say how to do that… now your brain has to engage and actually learn how to make the language do what you want rather than simply assent to what it reads in a book. Now you are traveling through the darkness and gaining first hand experiences to truly understand what the language is all about.

Read a complete description of the system

Find a good reference document that broadly covers everything the language can do. You need to have a complete survey of all of the classes of things that the language provides. For example, if you are learning Java, you need to know not just the basic syntax, but you also need to know that it is possible to integrate native code, to decompile Java code, to run on quite different Java virtual machines, to create a security sandbox, etc. You don’t need to learn all of these things in any kind of detail, but you need to become familiar with the range of possibilities of the language. This is an attempt to establish a general border of the big black void in your mind.

Learn some aspect in great detail

Choose some aspect of the language that you are interested in and become an absolute expert in that topic. Learn everything there is to know about it. Explore every last option, leave no stone left unturned. For example, maybe you take on the issue of threading. Explore every primitive the language offers for thread synchronization, learn all of the mechanics of creating threads, study the idioms that capture the communities sense of “best practice” with threads, learn how threads are implemented on different computer platforms, etc.. This is now a thin beam of light that extends all the way to the bottom of the darkness. There is no remaining mystery around the topic. Nothing hiding in the dark.

Study the work of the masters

Find code written by a master. So not only are you studying what the master has to say about the language, but rather you are learning what the master has said in the language. Read lots and lots of code written by the master. You want to just soak in well written code so it seeps into your thinking and into your style in ways that you are not even aware of. For Lisp this is reading Paul Graham’s On Lisp Here the goal is to learn to navigate the language, not just to get to the other side, but to get there in style, to do good work, to be an expert.

Hang out in the community

Find a community of experts in the language. Often this will mailing list archives or some kind of online forum. Browse through the archives. Spend a few weeks getting the latest messages. This is a way of immersing yourself in the culture of the language. So you will learn how such people think, what kinds of solutions are preferred.

Read the critics

Find the clearest thinking critics of the language and read what they have to say. This is a way to discover some of the hidden pits in the darkness.

Look to the future

Learn where the language is going. You don’t want to simply know how it works today, you want to know how it will work tomorrow. To be an expert you need to be ahead of the general adoption curve. For Java this means learning about upcoming JSR’s or just finding a good resource like Alex’s Java 7 page

So that is all there is to it. If you are trying to learn a new language and you are stuck then look back over this list, find something you haven’t done and go do it.

Of course these are just the starting points. To really know a language you need to build a real system and take it to production… and support it… a few times… over the span of several years… but that is another post.