Learning by example by Ivar Jacobson

In the work that we do people often want a recipe for developing software, a series of steps that predictably produce a result. Recipes are good, whether in cooking or in other areas, but they are not enough, and not everything that is interesting can be reduced to a simple recipe.

Over the years I've had the chance to observe how people learn. Reflecting on how I learn new things as well, I've come to the conclusion that many people, myself included, don't learn very well from following a recipe. In fact I'm rather hopeless at following step-by-step instructions.  As a kid I liked to tear things apart, figure out how they worked, and then put them back together. And most of the time they actually worked when I did eventually get them back together.

Taking something apart and putting it back together is a special case of learning by example where the thing you are taking apart is the example.  Once you've done this enough you can start improvising and designing new ways to solve the problem.

A lot of software development works the same way - whether it is a piece of code or a requirements specification, a lot can be learned from tearing apart a good example, understanding why it is good and how it works, and then, over time, starting to improvise those lessons learned on new problems.  In fact, given the choice between templates and a good example I'll choose the good example any time.  Even if you don't understand all the principles right away, most of us are clever enough to copy the parts that work that we don't understand and be creative in areas where we need to.  Over time we learn and the need to mimic goes away.  This is the way that all of us learned our native tongues, and the approach still serves us well today.

7 Comments
  1. Silveira Neto | January 16, 2009 at 3:08 pm Reply

    avatar

    I completely agree.
    I remember when I started to write my first codes, when kid, I had a book called something like “100 pieces of code” with 100 functional source codes, each one doing well something in a very limited scope. I remember that it was one of the best books that I ever read.
    Today I learn a lot by looking real source code from open source projects. It’s like the process of a kit disassembling and assembling a toy.

  2. Kurt Bittner | October 9, 2008 at 2:58 pm Reply

    avatar

    The examples are great and show how declarative requirements can be used in a variety of contexts. Some useful additions would be to show how prototypes (or at least GUI screen shots) can be used to capture requirements that can be (and sometime can only be) visualized, using domain models to capture requirements on information needs, using use cases or scenarios (or visual notations) to capture “flow” or business processes. Perhaps we could organize a little “community project”?

  3. Adriano Comai | October 9, 2008 at 7:26 am Reply

    avatar

    I agree with you post. So much that I compiled , some time ago, a Requirement-by-Example collection of examples drawn from some of the best requirements engineering literature. It can be found at
    http://www.analisi-disegno.com/requisiti/Requirements-By-Example.htm

  4. Kurt Bittner | September 19, 2008 at 9:21 pm Reply

    avatar

    What I meant by “tearing something apart”, in this case a requirements spec, is to find a good one and really look at it to figure out what makes it good. Finding a good one is tough, since most suffer from one of two problems: they are either too vague and imprecise (“high level”), or they are “lost in the weeds” of excessive detail. But a good one – one that is clear and succinct while not specifying things that should be left to the creativity of the developers, is instructive.

  5. Jagadeesh Hiremath | September 18, 2008 at 3:10 pm Reply

    avatar

    I partially do agree and with little concern. We are discussing about a scenario where something already exists and we have a change to tear it apart and put it back. This may complete the learning cycle but actually puts limitation to innovation or creativity.

    To an extent I am able to visualise tearing apart requirements specification but failing to visualise in the real world, how this could happen?

  6. Jan Glas | July 25, 2008 at 7:17 am Reply

    avatar

    So agree I. Learning by example is a good way to start anything new. It can be a document or even better a person you see working. What we are trying in our department is to offer a living example to our juniors. They get on a project with someone skilled and experienced and have a chance to follow the whole process. This adds understanding to pure learning by example.
    We give our junior a mentor, person who can teach and explain and in later stage (for seniors) we have coaches who can elevate our people much higher.

  7. mikemacd | July 22, 2008 at 10:19 am Reply

    avatar

    Completely agree – I learn best by getting my hands on something real and understanding how it works. In one of our process improvement projects at a large client in the UK we’ve published a wiki that includes examples from real projects of all sorts of work products.

    By supplying examples from different types of projects (small development, large development, COTS, Notes, Infrastructure upgrades) practitioners can learn from the experiences of other people in their organisation and also know who to talk to in the organisation if they want more information.