Author Archives: Espen

About Espen

For details, see www.espen.com.

How to write a teaching case

Since I sometimes give classes on how to do case teaching and have written a book on the subject with Bill Schiano, I am sometimes asked how to write a teaching case. The following blog post is a quick tips & tricks collection (essentially an update of this post.)

Why are you writing this case?
First and foremost: Cases are written for a teaching purpose – and to write a teaching case, you need to have a teaching objective in mind. It is not enough to have an interesting company. Even the best company story needs to have a pedagogical point, a theory or dilemma to illustrate. So don’t write a teaching case just because you happen to know someone in a really interesting company – it does need to be a good story, but it also need to have a purpose.

The standard outline
Cases – particularly the standard HBS case – follow an outline that can seem rather trite, but which is very effective. It is something like this:

  • 0.5 page: Intro: The protagonist is introduced, typically pondering a question of some importance. The idea is to tell the students from which perspective the case is written, to set the scene – and that is all there is to it.
  • 1 – 1.5 pages: Description of the company – not the whole history, but the relevant details, explaining what the company is doing, how they make their money. Most companies are to a very large degree formed by their history, so the relevant parts need to be told.
  • 1 page: Industry. Companies exist within a context, and you need to set it. Explain the industry, its evolution, and the company’s position within it. Do it succinctly, but leave more detail in than what is strictly necessary.
  • 1 – 5 pages: Specific issue. This is the meat of the case, the issue at hand, the story to ponder. Make sure you tell it logically and cooly, not leaving anything out, but also conveying the complexity of the situation.
  • 0.5 page: Conclusion, typically with the protagonist wondering what to do, often with some sort of event (board meeting, etc.) where he or she has to present a solution to the problem.

Most cases are just that – one case. You can have a B case and even a C case, but keep them short, since they have to be handed out and read in class. The B case should explain what the company did and perhaps introduce a new problem, the C case, if necessary, should bring some sort of closure, explaining what eventually happened. In my experience, it is very hard to get discussion after a C case – the students become exhausted. As a novice case writer, especially if you are writing about a company with a long history, it can be tempting to create a long string of small cases, but in practice this seldom works well – for one thing, it forces the discussion into a very predictable path.

The no-nos
No theory. A good case should be a description of an interesting situation, frequently a decision point – and nothing else. This means that there should be no theory and no discussion of the case in the case itself. Save that for the teaching note, or write a separate academic article about it. Not only does this make the case more realistic, it also means it can be used for more purposes than the one initially envisioned. This can be quite challenging for the traditional academic writer – but it is actually good practice to only present the facts (though, of course, which facts you choose to present constitute a discussion of sorts).

No hero, no villain. When teaching students how to analyze a case, I always start by saying that for most business situations, if is useful to begin the analysis with the assumption that people are not stupid and not evil. Consequently, when you write a case, make sure it has no heroes and no villains. If a case has a clear-cut hero or villain, it is a sign that you have not done enough research. Write things so that the students can see the issue from many perspectives.

No judgement. I frequently find, when reading prospective teaching cases, especially if written with the help of the communications department of a company, that judgements tend to be embedded in the text itself, though it is supposed to be as neutral and purely descriptive as possible. Do not write that a company is “leading” – instead, describe what they do, perhaps adding a bit of industry numbers for comparison, and let the decision about how leading the company is be up to the student. Do not write “Smith was a highly accomplished manager, leading a successful technology implementation.” Instead, write “Smith, at 29, was promoted to be the youngest vice president in company history after conceiving and overseeing the introduction of the first machine learning platform in the industry.”

No consultingese. Be very careful of weasel terms – is the company embarking on a strategic alliance or merely collaborating with another company for a specific purpose? (As a friend of mine said: “I buy all my socks at Marks and Spencer. That does not mean I have a strategic alliance with them.”) Avoid terms that are not well defined, and be precise in your language. Remember, a teaching case has the longest legs when it describes a human situation (since humans change slowly) and to not tie the narrative to specifically to a technology or a situation. (See the example of Fabritek below.) I quite often use old technology cases, and when the students complain, ask them to take out a pen and change the dates mentioned to current times, update the technology capabilities accordingly – and see if anything else changes.

Dramatic structure
A really well written case has dramatic structure – there is a beginning, a middle that builds up the story, and a really compelling issue at the end. The best cases are almost like a detective story, where you have to dig deep into the analysis to find surprising and sometimes counter-intuitive conclusions. One example of a “detective story” case is Fabritek 1992*, a very old (first published 1969, rewritten by Jan Hammond) case about a quality control issue in a small mechanical workshop. (Hat tip to Robert D. Austin, eminent case teacher, for making me aware of this case and showing me how to teach it.) The case is excellent because it starts with the company (strategic level), proceeds to describe a new situation and a new process (organizational or business logic level) and then introduces the problem (operational level.) Analyzing the operational details leads to one conclusion, which then can be discussed in terms of the organization and its business logic, which can then be placed into a strategic context. The case is excellent because it allows links between these levels – and also teaches the students that the devil indeed resides in the details, and that you as a manager better be very close to how the business you are leading works and makes money.

iPremier-front-pageA second case which shows quality and innovation is iPremier, written by Robert D. Austin and Jeremy C. Short, the first and only graphic novel (cartoon) case I am aware of. The story is about a small online gift company being attacked by hackers, exposing glaring gaps in their security procedures and forcing managers at various levels to make some really hard decisions. The graphic format is excellent in making the various characters real (though they, on average, tend to be way too good-looking for a normal business situation), illustrates technical issues in a way that is very understandable even by non-technology students, and has a cracking good storyline with a B and a C case. I like to introduce a few technical cases in my courses because, well, I don’t think there is enough technology in business schools, and this cases answers very well because it illustrates that certain technical decisions very much require top management attention – ignore (or mindlessly delegate) technology understanding and responsibility at your peril. The graphic format also provides a welcome break from the standard case verbiage, which can be a trifle dour on occasion.

Details, details, details!
Research cases – the kind that is published in refereed journals – tend to be written from a very specific viewpoint, and only facts pertaining to that perspective is included, often in a very abstract format. A teaching case is the direct opposite: It needs lots of details, frequently made available as exhibits (graphs, pictures, documents, tables, etc.) placed at the end, after the main text. A teaching case writer, when visiting a company to write about it, needs to notice the small details, much like a really good journalist does. I tell my students that they should prepare each case so well that they feel like they have worked in the case company – and to allow them to do that, you need to provide the operational details necessary. (Incidentally, having more details than strictly necessary has the added benefit of making the case realistic – in the real world, you have to decide what is important and what is not.)

Doing it – and reading about it.
grandongillI am not aware of many books about how to write a good teaching case, with one exception: Grandon Gill (pictured), professor at University of South Florida and an excellent case teacher, has written a book called Informing with the case method, which is available for free download in PDF, MOBI and EPUB format from his web site. It has lots of details, tips and tricks, not just about case writing, but also about case teaching and course planning. (For the latter, of course, I am duty bound to recommend Bill Schiano’s and my book Teaching with Cases: A Practical Guide.)

Last but definitely not least: Don’t underestimate how much work writing a proper business case is. Getting the details right, describing the dramatis personae, and making the storyline compelling is quite a challenge, in many dimensions different from the traditional academic article. On the other hand, should you get it right, you will have a very effective teaching tool for many years to come.

Good luck!

Peter as the bionic man

Peter Scott-Morgan, former colleague of mine and a mercurial mind in so many dimensions, was relatively recently diagnosed with motor neuron disease (MND or, more popularly known as  ALS or Lou Gehrig’s disease. Steven Hawking had a slow-moving version of this disease. Charlie Osborne, a friend and fellow doctoral student of mine, died from it.) A devastating blow to anyone, Peter has, not unexpectedly, turned this into an opportunity to explore technology as a way of staying connected with his surroundings.

MND gradually shuts down the communication system between your body and your brain, and can leave you trapped with a fully functioning brain locked inside a body you cannot control. Peter, who has a Ph.D. in robotics and energy enough for a platoon, aims to do whatever he can to stay not just alive, but communicating and functioning, as long as possible. To do this, he has had several operations to facilitate technology access to his body and continued functioning (you eventually lose control of the smooth (involuntary) muscles as well as the regular ones) after his brain stops communicating naturally.

Dr Peter Scott-Morgan on Vimeo.

In order to install and to a large extent develop this technology, he needs help finding people with expertise and interest in developing new technology using him as the experimental subject and development partner. Peter is no stranger to being a pioneer – him and his spouse Francis Scott-Morgan were the first gay couple to be married in a full ceremony in the UK in 2005.

So – anyone with knowledge of medical technology and interest in this project – please get in touch with Peter! (And incidentally, there is already going to be a documentary about his quest.)

Anne-Cath Vestly on where children come from

anne-cath-_vestlyAnne-Cath Vestly (1920 – 2008) was a much loved Norwegian author of children’s books, who challenged many of the prejudices of her time by writing about non-stereotypical families where the mother worked and the father was home, children who lived in high-rises rather than in saccarine little houses, etc.

In 1953 she was reading a story on the radio program “Barnetimen” (The Children’s Hour) about the little boy Ole Aleksander whose mother was going to have a baby. Telling children how babies came to be was considered shocking at the time, so this created an uproar, even death threats. As she said, it seemed to be the grown-ups that were bothered – the children wrote her letters telling her not to feel sad.

She also did radio programs for grown-ups, so her response was to write a short story about a little boy who is going to have a sibling, and how he found out about it. And just the other day, I met a little American boy who was very confused about how someone could have a baby without being married (apparently, he thought it was the marriage ceremony that produced the offspring), so I decided that a translation into English of Anne-Cath’s story was in order. Totally unauthorised, of course, errors are all mine, but very much in her spirit. (And you can find some of her books in English – at astonishing prices – at Amazon.)

A Children’s Hour for Grown-Ups

Anne-Cath Vestly, 1953

Once there was a small boy named Anton. He lived in a small house in a small town with his father and mother. One day, just before dinner, his mother was knitting a small jumpsuit. Perhaps you know what that is?

Anton was sitting and looking at the knitting – for a long time. Then he said:

— That is way too small for me, Mum.

— So you think it is for you?, said Mum, and her face looked a bit peculiar.

— Isn’t it?, said Anton.

— No, this for a little baby, said Mum. Would you like it if we had a little baby?

— Oh yes, could we? said Anton. But, Mum — how can we get a baby?

Mum was quiet for a little bit, and then she started to knit very fast. Then she said: Those babies … we buy them in the country.

— In the country they sure have many things, said Anton. I wish we lived in the country, because then we could go and look at those babies every day.

— Yes, said Mum.

— But Mum, when we were in the country this summer, do you remember that lady in the red house? She went to the city, and when she came back she had a baby?

— Oh yes, said Mum, those who live in the country go to the city to buy their babies!

— Oh, said Anton. So I was bought in the country?

— Yes, said Mum.

— Was I expensive??? asked Anton.

— Oh, not too bad, said Mum.

— When are we going to go and buy that baby? asked Anton, and now he was really excited.

— Not too long now, said Mum, but, you see, you cannot come with us.

— Why not? said Anton. I bet I could pick the best baby for you!

— Now, you should not ask so many questions, said Mum. You were really cute when you were smaller. You didn’t ask so many questions then…

— Couldn’t I talk then? asked Anton.

Right then, they heard Dad coming home, and Mum ran out to the hallway and whispered to him: Now I have finally told him about the baby!

— Great! said Dad, coming in. Hello, my boy! I guess you are really excited about whether it will be a girl or a boy the stork will bring?

— The stork? said Anton.

— Yes, don’t you know that it is the stork that brings the small babies? It flies all the way from the Nile with the little baby in its blanket, and then it flies over all the houses and drops the little baby right down to us.

— Well, um, said Mum, I just told Anton that we buy the small babies out in the country.

— Oh, said Dad. Well, I, at least, came with the stork. I remember it distinctly.

— Come and have dinner, said Mum.

After dinner, Mum and Dad wanted to rest for a while, and Dad said: Con you sit in the living room and mind the house for a while, Anton?

— Yes, said Anton.

In a little while, there was a knock on the door. Anton opened, and there was old Aunt Agnete.

— Is you mother home? she asked.

— Yes, she is home, but she is so very tired, so she is resting.

— Is she now, said Aunt Agnete. Can’t be too long now, she murmured to herself.

On the table was Mum’s knitting. Anton looked at it and said: Aunt Agnete, you know what? We are going to buy a baby!

— So you know? said Aunt Agnete. Her face turned very peculiar for a while, then she cleared her throat and made her voice almost normal and said: But you are not going to buy one, little friend. Don’t you know that the little babies lie in a large pond, up in heaven above the skies. There they swim around all the time until they find that they want to come down to us, and then they glide down one quiet night and snuggle into their bed under the duvet. And when you wake up next morning, there is a baby there!

— Where you born that way? said Anton.

— Yes, said Aunt Agnete.

— Can you swim? said Anton.

— No, I can’t, said Aunt Agnete. She taught it was a bit odd that Anton was not more interested in the babies she talked about, but she was mistaken.

— Have you forgotten how, then? said Anton. You knew how to swim when you were crawling around that pond…

— How you talk, said Aunt Agnete. Imagine, crawling…

— Maybe you were just swimming the breaststroke, said Anton.

— What a naughty boy you have become, said Aunt Agnete. Why don’t you go out and play for a while, I’ll mind the house in the meantime.

Anton went out, where he met old Martin who used to sweep the streets in the little town.

— Martin, said Anton. How were you born?

— I, said Martin, came sailing down the river on a board.

That night Anton lay awake thinking for a long time before he fell asleep. When he woke up the next morning, Mum had indeed gone, and Anton went out to play with a little boy named Lars.

— Mum has gone to the country to buy a baby, he said proudly.

— That’s not how it works, said Lars. Don’t you know that little babies are inside their mother’s tummy, and when they come out they are all finished with eyes and a nose and everything. Isn’t that great?

— Yes, said Anton. That is really great.

Then he sighed and said to himself: If only it had been that simple…

Summer reading for the diligent digital technology student

eivindgEivind Grønlund, one of my students at the Informatics: Digital Business and Leadership program at the University of Oslo sent me an email asking about what to read during the summer to prepare for the fall.

Well, I don’t believe in reading textbooks in the summer, I believe in reading things that will excite you and make you think about what you are doing and slightly derail you in a way that will make you a more interesting person when Fall comes. In other words, read whatever you want.

That being said, the students at DigØk have two business courses next year – one on organization and leadership, one on technology evolution and strategy. Both will have a a focus on basics, with a flavor of high tech and the software business. What can you read to understand that, without having to dig into textbooks or books that may be on the syllabus, like Leading DigitalThe Innovator’s SolutionEnterprise Architecture as Strategy, or Information Rules?

Here are four books that are entertaining and wise and will give you an understanding of how humans and technology interact and at least some of the difficulties you will run into trying to manage them – but in a non-schoolbook context. Just the thing for the beach, the mountain-top, the sailboat.

  • 816Neal Stephenson: Cryptonomicon. The ultimate nerd novel. A technology management friend of mine re-reads this book every summer. It involves history, magic reality (the character of Enoch Root), humor, startup lore, encryption and, well, fun. Several stories in one: About a group of nerds (main protagonist: Randy Waterhouse) doing a startup in Manila and other places 1999, his grandfather, Randall P. Waterhouse, running cryptographic warfare against the Germans and Japanese during WWII, and how the stories gradually intersect and come together towards the end. The gallery of characters is hilarious and fascinating, and you can really learn something about startups, nerd culture, programming, cryptography and history along the way. Highly recommended.
  • 7090Tracy Kidder: The Soul of a New Machine. This 1981 book describes the development process of a Data General minicomputer as a deep case study of the people in it. It could just as well have been written about any really advanced technology project today – the characters, the challenges, the little subcultures that develop within a highly focused team stretching the boundaries for what is possible. One of the best case studies ever written. If you want to understand how advanced technology gets made, this is it.
  • 24113Douglas Hofstadter: Gödel, Escher, Bach. This book (aficionados just call it GEB) was recommended to me by one of my professors in 1983, and is responsible for me wanting to be in academia and have time and occasion to read books such as this one. It is also one of the reasons I think The Matrix is a really crap movie – Hofstadter said it all before, and I figured out the plot almost at once and thought the whole thing a tiresome copycat. Hofstader writes about patterns, abstractions, the concept of meta-phenomena, but mostly the book is about self-referencing systems, but as with any good book that makes you think it is breath-taking in what it covers, pulling together music, art, philosophy and computer science (including a bit on encryption, always a favorite) and history. Not for the faint-hearted, but as Erling Iversen, my old boss and an extremely well-read man, said: You can divide techies into two kinds: Those who have read Hofstadter, and those who haven’t.
  • 34017076Tim O’Reilly: WTF? What’s the Future and Why It’s Up to Us. Tim is the founder of O’Reilly and Associates (the premier source of hands-on tech books for me) and has been a ringsider and a participant in anything Internet and digital tech since the nineties. This fairly recent book provides a good overview of the major evolutions and battles during the last 10-15 years and is a great catcher-upper for the young person who has not been been part of the revolution (so far.)

And with that – have a great summer!

The history of software engineering

grady_booch2c_chm_2011_2_cropped

The History of Software Engineering
an ACM webinar presentation by
ACM Fellow Grady Booch, Chief Scientist for Software Engineering, IBM Software
(PDF slides here.)

Note: These are notes taken while listening to this webinar. Errors, misunderstandings and misses aplenty…

(This is one of the perks of being a member of ACM – listening to legends of the industry talking about how it got started…)

Trust is fundamental – and we trust engineering because of licensing and certification. This is not true of software systems – and that leads us to software engineering. Checks and balances important – Hammurabi code of buildings, for instance. First licensed engineer was Charles Bellamy, in Wyoming, in 1907, largely because of former failures of bridges, boilers, dams, etc.

Systems engineering dates back to Bell labs, early 1940s, during WWII. In some states you can declare yourself a software engineer, in others licensing is required, perhaps because the industry is young. Computers were, in the beginning, human (mostly women). Stibitz coined digital around 1942, Tukey coined software in 1952. 1968-69 conference on software engineering coined the term, but CACM letter by Anthony Oettinger used the term in 1966, but the term was used before that (“systems software engineering”), most probably originated by Margaret Hamilton in 1963, working for Draper Labs.

Programming – art or science? Hopper, Dijkstra, Knuth, sees them as practical art, art, etc. Parnas distinguished between computer science and software engineering. Booch sees it as dealing with forces that are apparent when designing and building software systems. Good engineering based on discovery, invention, and implementation – and this has been the pattern of software engineering – dance between science and implementation.

Lovelace first programmer, algorithmic development. Boole and boolean algebra, implementing raw logic as “laws of thought”.

First computers were low cost assistants to astronomers, establishing rigorous processes for acting on data (Annie Cannon, Henrietta Leavitt.) Scaling of problems and automation towards the end of the 1800s – rows of (human) computers in a pipeline architecture. The Gilbreths created process charts (1921). Edith Clarke (1921) wrote about the process of programming. Mechanisation with punch cards (Gertrude Blanch, human computing, 1938; J Presper Eckert on punch car methods (1940), first methodology with pattern languages.

Digital methods coming – Stibitz, Von Neumann, Aitken, Goldstein, Grace Hopper with machine-independent programming in 1952, devising languages and independent algorithms. Colossus and Turing, Tommy Flowers on programmable computation, Dotthy du Boisson with workflow (primary operator of Colossus), Konrad Zuse on high order languages, first general purpose stored programs computer. ENIAC with plugboard programming, dominated by women, (Antonelli, Snyder, Spence, Teitelbaum, Wescoff). Towards the end of the war: Kilburn real-time (1948), Wilson and Gill subroutines (1949), Eckert and Mauchly with software as a thing of itself (1949). John Bacchus with imperative programming (Fortran, 1946), Goldstein and von Neumann flowcharts (1947). Commercial computers – Leo for a tea company in England. John Pinkerton creating operating system, Hoper with ALGOL and COBOL, reuse (Bener, Sammet). SAGE system important, command and control – Jay Forrester and Whirlwind 1951, Bob Evans (Sage, 1957), Strachey time sharing 1959, St Johnson with the first programming services company (1959).

Software crisis – not enough programmers around, machines more expensive than the humans, priesthood of programming, carry programs over and get results, batch. Fred Brooks on project management (1964), Constantin on modular programming (1968), Dijkstra on structured programming (1969). Formal systems (Hoare and Floyd) and provable programs; object orientation (Dahl and Nygaard, 1967). Main programming problem was complexity and productivity, hence software engineering (Margaret Hamilton) arguing that process should be managed.

Royce and the waterfall method (1970), Wirth on stepwise refinement, Parnas on information hiding, Liskov on abstract data types, Chen on entity-relationship modelling. First SW engineering methods: Ross, Constantine, Yourdon, Jackson, Demarco. Fagin on software inspection, Backus on functional programming, Lamport on distributed computing. Microcomputers made computing cheap – second generation of SW engineering: UML (Booch 1986), Rumbaugh, Jacobsen on use cases, standardization on UML in 1997, open source. Mellor, Yourdon, Worfs-Brock, Coad, Boehm, Basils, Cox, Mills, Humphrey (CMM), James Martin and John Zachman from the business side. Software engineering becomes a discipline with associations. Don Knuth (literate programming), Stallman on free software, Cooper on visual programming (visual basic).

Arpanet and Internet changed things again: Sutherland and SCRUM, Beck on eXtreme prorgamming, Fowler and refactoring, Royce on Rational Unified Process. Software architecture (Kruchten etc.), Reed Hastings (configuration management), Raymond on open source, Kaznik on outsourcing (first major contract between GE and India).

Mobile devices changed things again – Torvalds and git, Coplien and organiational patterns, Wing and computational thinking, Spolsky and stackoverflow, Robert Martin and clean code (2008). Consolidation into cloud: Shafer and Debois on devops (2008), context becoming important. Brad Cox and componentized structures, service-oriented architectures and APIs, Jeff Dean and platform computing, Jeff Bezos.

And here we are today: Ambient computing, systems are everywhere and surround us. Software-intensive systems are used all the time, trusted, and there we are. Computer science focused on physics and algorithms, software engineering on process, architecture, economics, organisation, HCI. SWEBOK first 2004, latest 2014, codification.

Mathematical -> Symbolic -> Personal -> Distributed & Connected -> Imagined Realities

Fundamentals -> Complexity -> HCI -> Scale -> Ethics and morals

Scale is important – risk and cost increases with size. Most SW development is like engineering a city, you have to change things in the presence of things that you can’t change and cannot change. AI changes things again – symbolic approaches and connectionist approaches, such as Deepmind. Still a lot we don’t know what to do – such as architecture for AI, little rigorous specification and testing. Orchestration of AI will change how we look at systems, teaching systems rather than programming them.

Fundamentals always apply: Abstraction, separation, responsibilities, simplicity. Process is iterative, incremental, continuous releases. Future: Orchestrating, architecture, edge/cloud, scale in the presence of untrusted components, dealing with the general product.

“Software is the invisible writing that whispers the stories of possibility to our hardware…” Software engineering allows us to build systems that are trusted.

Sources: https://twitter.com/Grady_Boochhttps://computingthehumanexperience.com/

Brilliance squared

Stephen Fry and Steven Pinker are two of the people I admire the most, for their erudition, extreme levels and variety of learning, and willingness to discuss their ideas. Having them both on stage at the same time, one interviewing the other (on the subject of Pinker’s last book, Enlightenment Now), is almost too much, but here they are:

(I did, for some reason, receive an invitation to this event, and would have gone there despite timing and expense if at all possible, but it was oversubscribed before I could clink the link. So thank whomever for Youtube, I say. It can be used to spread enlightenment, too.)

Interesting interview with Rodney Brooks

sawyer_and_baxterBoingboing, which is a fantastic source of interesting stuff to do during Easter vacation, has a long and fascinating interview by Rob Reid with Rodney Brooks, AI and robotics researcher and entrepreneur extraordinaire. Among the things I learned:

  • What the Baxter robot really does well – interacting with humans and not requiring 1/10 mm precision, especially when learning
  • There are not enough workers in manufacturing (even in China), most of the ones working there spend their time waiting for some expensive capital equipment to finish
  • The automation infrastructure is really old, still using PLCs that refresh and develop really slowly
  • Robots will be important in health care – preserving people’s dignity by allowing them to drive and stay at home longer by having robots that understand force and softness and can do things such as help people out of bed.
  • He has written an excellent 2018 list of dated predictions on the evolution of robotic and AI technologies, highly readable, especially his discussions on how to predict technologies and that we tend to forget the starting points. (And I will add his blog to my Newsblur list.)
  • He certainly doesn’t think much of the trolley problem, but has a great example to understand the issue of what AI can do, based on what Isaac Newton would think if he were transported to our time and given a smartphone – he would assume that it would be able to light a candle, for instance.

Worth a listen..