Blog

Kari
Peltola
17 / 10 / 2011

How prototypes create value, Part 1: Communication

In this series of posts, I am going to explore how software prototypes create value. Today, I will explain why I believe effective communication is the key to a successful software project and how prototypes facilitate communication by creating reference points. The topic of the next post will be the validation of business cases with prototypes.

Abstractions are difficult to communicate

Every product development project starts with an idea. Someone perceives a need and then imagines a solution that resolves this need. Sometimes this idea is correct from the start, and sometimes it needs refinement. But every time, it needs to be communicated – first inside and then outside the organization.

As ideas are abstract, they are not easy to communicate. This is especially the case if they truly contain a “new”, “unheard of” or “revolutionary” component. Nevertheless, successful communication is crucial. If we communicate ineffectively, bad things happen:

• We waste our most valuable resource – time
• We waste our second most valuable resource – energy
• We make bad decisions based on wrong perceptions

Variance in individual perceptions and experiences

Now, in order to for us to understand each other, we should define two terms – perception and experience. In this post, I use the term perception to refer to the process of attaining understanding of a concept by organizing and interpreting sensory information. By the term experience, I mean a state or a series of states that are formed in the mind as a result of conscious or unconscious processes, such as thought, perception, memory, emotion and imagination. So, in plain English, we create experiences through perception.

We perceive the world through our senses, namely sight, hearing, taste, touch and smell. Dedicated sensory cells in our bodies receive signals from our environment and direct them to our brains for interpretation. Now, this is where things get a bit complicated. Even if you and I can both see the color blue, my notion of blue will not be your notion of blue. Our brains interpret, that is perceive, the same signal in different ways depending on our unique physique and mental processes. Thus, our experiences will differ.

When you think about a car, what do you see? A parent might see a family car. A rich poker player may see a sports car, such as a Ferrari or a Lamborghini. And what about the details? What is the color of the car, its size, its interior?

We understand that the word “car” can be interpreted in a great number of ways by different people. Therefore, the variance of individual experience for this concept, “car,” is high.

When a concept is new to us, by definition, we don’t have any previous experience with it. Therefore, our perceptions of the concept stem from our associations with previous, unrelated, experiences. Because these associations vary, we have no way of knowing if we are thinking of the same concept as long as we’re communicating it via language alone.

We need to understand that we all perceive the world in our own unique way.

This variance in experience creates problems. The problem is not that we perceive and therefore experience things differently; in fact, I consider that richness in diversity to be a tremendous resource in human beings. The problem arises when we assume that we’re talking about the same thing when we’re not. This assumption, first of all, it makes alignment of resources difficult. For example, if I say, “Make a vehicle,” and the motor expert in my team starts to build a motor for a car and the frame expert in my team builds a frame for an armored vehicle, then we are probably not going the get a scooter, which is what I had in mind. In order to align resources, we must be able to communicate clearly the particulars of our ideas, thus unifying our vision.

Variance in experience makes alignment of resources difficult.

Secondly, the variance in experience makes informed decision making difficult. If people don’t experience the concept in the same way, it is not possible to get valid feedback and exploit all the expertise that contributors possess. The consequent suboptimal decisions endanger the product by directing its development onto a wrong path. This leads to prolonged decision making, wasted resources, decreased job satisfaction and lost revenue.

Misinterpretation leads to suboptimal decisions and waste.

Removing the variance entirely is impossible, because we will experience even the finished product differently. However, we can greatly reduce the negative variance that creates miscommunication early in the process by simulating the intended experience. Usually, this simulation involves exploiting relevant dimensions and channels of perception regarding software product concepts, especially time and visual channels.

Creating a Reference Point

To get everybody on the same page, we need a reference point. It can be an analogy, a drawing, a paper prototype, a visualization, a functional prototype – anything that communicates the concept effectively in relation to the context. For example, I can tell you that I had a fantastic experience when rising to a stage to give a speech to a cheering audience. However, “a fantastic experience” as a concept is very vague. I could draw an analogy and further offer a reference point by saying, “It was just like riding a roller coaster: you feel that crunch in your stomach and the thrilling combination of fear and pleasure as adrenaline rushes through your veins.”

A reference point enables everybody to get on the same page.

Reference points are things we use all the time. Unfortunately, most of the time, we use them badly.

Software projects are all about abstractions. Usually there are, and should be, people with different backgrounds involved in the development process. Developers create something that has never existed before, usually based on their interpretations of someone else’s ideas. In order to communicate critical abstractions, it’s useful to create fast prototypes to bring the idea to life. Prototypes help to establish, crystallize and maintain a clear vision.

A good reference point gets all the relevant stakeholders on the same page. It operates as a mental anchor that effectively directs efforts. It enables fast iterative development, as people understand the concept and are able to give direct feedback. In many cases, a good reference point requires that the user experience of a given concept be concretized.

In our prototyping process, we use a Goal-Directed Design based approach to evaluate which elements of user experience are the most valuable. In order to prioritize these elements, we need to understand the requirements of the context, because the goals of the communication might vary from one context to another. In many cases, we might communicate the concept to multiple stakeholder groups by demonstrating the prototype, but there is usually one group that is more important than the others. Therefore, you should focus your effort by asking yourself, “Does this feature communicate the right things to the right stakeholder?” Also, bear in mind that this prioritization management is the most important (and probably the hardest) task when managing the effort you put in to creating the prototype.

Now, let’s look at a concrete example that will help you to get on the same page as me. The challenge is as follows:

The customer travels to numerous conferences, meetings and other happenings where he meets many new people. Oftentimes, he will sit at the meeting table with the people and know nothing more than their names after introductions. If he knew more about them, such as their interests, credentials, common contacts, publications and research, he would create more value by networking and influencing them more effectively. That’s why he would love to have a “Meeting Genius”, a system into which he could simply type the names of the participants at a meeting and view the participants’ relevant information in one glance.

We created a prototype of a web service to answer this challenge. In this service, one can type the subject of the meeting and the names of the participants, and with one “scuup,” get all the relevant information at one’s disposal.

Ok, now you have formed preliminary mental image of the concept, probably accompanied with some notion of whether you would use such a service and what features it should have. Let’s take a look at the reference point we created: scuup.leonidasoy.fi

After trying out this reference point, do you have more opinions about the concept? Would you use such a service? Does it lack features you would want? Is some feature especially neat? This is what a reference point does: it communicates in higher detail and therefore enables informed decisions, aligns product development resources and reduces waste.

Edvard
Majakari
21 / 9 / 2011

Strange Loop 2011: Tuesday

On Tuesday, I didn’t attend that many sessions. Instead I wanted to create a Yet Another Crappy Tutorial On Monads On Some Other Language Than Haskell, created a really crappy, if working, implementation on Maybe and Either type classes. Realizing there has to be existing examples on monads with Ruby, I found a good basis upon which to build stuff by some clever guy and ended up refactoring and extending that instead during the hacking session. However, I did start the morning with an intriguing session regarding startups and Haskell.

Bryan O’Sullivan of RWH fame shared his experiences on starting your own company with other smart enough people, where Haskell plays an important role. BTW, while I did like the style and more idiomatic approach of Learn You A Haskell For Great Good, does have some very nice examples and pragmatic tips; read LYAH first and go to RWH for more details and examples. Bryan is a pretty prolific Haskellist and has published many core components built by his company on Github, not to forget his contribution to GHC to make network I/O faster. I left that session happy and convinced that Haskell is more than mature for serious work.

After the unorthodox detour of creating the Maybe monad for Ruby, I went to check out the language panel, where the audience asked various questions regarding programming languages from the panel consisting of six professionals, including Rich Hickey of Clojure fame and Gerald Sussman of Seriously You Can’t Be Asking Of What fame. Long story cut short, when asked what language one would have wanted to have invented if not his own, Lisp was chosen unanimously. And I’ve heard the same going on for over 10 years or so, and I suppose for a reason.

Next session was pretty deep stuff. I’m still collecting the various bits and bytes trying to combine all of that together; I can’t yet connect all the parts, but it was just PURE AWESOME at the risk of overusing the aforementioned adjective. Want to get your neurons firing fast? Talk to David Nolen and ask about the mapping problem. That stuff got me thinking in the same sense as Erik Meijer’s talk did with all that duality-and-flirting-with-category-theory stuff. I wish to hear more from that guy (going to browser to follow him on Twitter). Now, that’s better. For what I gathered, the main point was that there exists this problem of taking the problem from the problem domain and going to the tool (programming language) abstraction level. Certain languages give much better means/tools of building up the required syntax/mechanisms for more natural mapping, and Nolen used his implementation of pattern matching support for the Clojure language as an example. Cool thing was that it was effectively the same as pattern matching in Haskell, even though the latter has lazy evaluation whereas Clojure does not. Also, I added the book The Art of the Metaobject Protocol to my list of books to acquire.

Penultimate session was by Allen Wirfs-Brock on “Post-PC computing” is not a vision. I actually had drawn the same conclusions like probably hundreds of thousands of others had, so there wasn’t much new there. Maybe the best part was saying out aloud the phenomenon we already see happening: web browser is fading away, kind of; it’s becoming ubiqutous as the computing technology itself. Most modern (all?) OSs already have a set of extracted libraries which together provide the functionality needed to browse the web, so that when opening the application you don’t need to necessarily click the link to see some related web page show in a separate browser, instead, the application is able to render the page in itself due to built-in libraries for retrieving, parsing and rendering web content. Think of your toaster querying the price for sliced bread via REST api and showing it on the panel. That’s future, baby.

Last session was a really, really good one, even though I didn’t agree with everything Rich Hickey said (of course, I am right whenever my opinions differed from his). Rich talked about simple software design, carefully overloading words “Simple” and “Easy” with semantics most (maybe all?) people could agree with. Going deep from etymologies of both words into characteristics of software that is simple, he showed several ways by which we, software developers, creep complexity (complectify?) into code. One of the best lessons I learned there was that regarding simplicity in rather general and abstract level, it is not a question of cardinality; having many instances of something, while internally consistent, does not make something complex. That gives me more rigid basis on arguments regarding if it is actually a good thing to split a complex method into many very simple ones — I always love it when some much smarter-than-me guy me at least semi-formal ways of proving I have been right all the time, if only by intuition >:-)

All in all, I feel kind of ambivalent on getting back to home. I do miss my kids, friends and co-workers, but I also feel sad to leave. St. Louis was a city one could easily learn to love, not least due to genuinely friendly people, good food and plain awesome (sorry! that word again) Jazz. I was also lucky to meet a sweet, charming lady doing pretty involved statistical analysis with Fortran language, both of which I would have wanted to talk about way much longer if it had been possible. I also miss the guys we talked with during breaks on some of the sessions, especially the folks on the “Those Guys” team. Sniff.

Day 1: Monday

Edvard
Majakari
20 / 9 / 2011

Strange Loop 2011: Monday

Ok, first day seemed to have lots of interesting talks.

Erik Meijer started a keynote talking about Category Theory, Big Data and Monads. It seemed like there was not sufficient time to talk about monads, but his view on three orthogonal dimensions of Big Data and especially dual nature on SQL and NoSQL blew my mind. The main thing was, SQL and NoSQL are not opposite but dual in nature (dual as in dual in category theory); just reverse the direction of arrows in SQL relations and key-value stores, and you see the point. As always, you just have to love Erik’s style on giving presentations.

Then Neil Ford gave presentation on Functional Thinking. I have to say the presentation was a lackluster. The presentation in itself was good and the guy obviously could have shared lots of wisdom and knowledge, but it was really like FP 101. I guess that if some Java coder who has always refused to learn anything about FP and by some random coincidence entered the wrong room and listened to the session, he would’ve probably learned some new stuff.

About next session – I’m so annoyed I chose another session first! I really didn’t get anything out of it, as the pace was just too high and it was so specific to JVM that it just wasn’t for me. In the end I went to listen the end of Daniel Spiewak’s extreme cleverness which just made my day. This guy just rocks! Combine deep knowledge, wits, intelligence and extremely energetic (which you’ll just love) style of presentation and that’s Daniel Spiewak standing right there. Not only fascinated by the session, I learned a few new functional programming data structures on the way, but most of all, I got elated for the rest of the day — Spiewak did that just that. Seriously.

Another part in the Mindboggling Lectures series, next up was Scalaz: Purely Functional Programming in Scala by Runar Bjarnason. That certainly should have enlightened many people trying to get their heads around monads, as Bjarnason presented how some type classes were implemented in Scalaz, starting from semigroups, going to monoids, applicative functors and sneaking in monads without actually mentioning it until later in a sidenote. That stuff was pure.. um, adamantium or something — one of the best presentations. At last that made me pretty interested in Scala itself as well.

Parser Combinators: How to Parse (nearly) Anything by Nate Young was pretty good as well. Nate seemed to be pretty relaxed, informal but knew his stuff and at least I got a good intuition of how to make different parsers by combining very simple parsers using just four constant outcomes along with the unparsed part. I had read some parsec stuff before but never soiled my feet in it, and Nate’s Clojure examples were well done. Added simple regexp parser using parser combinators to my personal todo list :)

Final session I chose before ending keynote for Monday was about Making Monads Easy by Jim Duey, this time implemented in Clojure. There wasn’t anything new to me — with the exception of some Clojure syntax as I’m not that familiar with the language — but it was kinda fun to see how people learning about monads on the second or third round just don’t get it yet, because it often takes about 5 attempts or so and then you go like “come on, it was this easy?”, create a blog post about it ending up confusing the beginners with exactly the same oversimplified (or unnecessarily complex) example. Not that Jim didn’t do a good job (he did), but it just takes a few rounds to get the hang of it.

Day ended with a keynote by Gerald Jay Sussman. I do believe I got the idea, but the idea was a bit too distant for me. Basically, it was about totally different computing model, but in the end, the proporal wasn’t /that/ radical and there are already comparable systems with similar functionality. There were some very good points, naturally, and the problem described is really an interesting one. Check https://thestrangeloop.com/sessions/we-really-dont-know-how-to-compute for more.

Day 2: Tuesday

Edvard
Majakari
31 / 3 / 2011

On Software Quality and the Next Big Language, Part II

The second part is long overdue. I wanted to finish this before TextMate 2 — aka Duke Nukem of the Editors — is released, so here we go. I promised to share my best guess about the Next Big Language. Here it is.

Read more…

Aleksi
Kopponen
20 / 1 / 2011

Get Your Invite to SoturiSauna

As Kari said in his previous post, we’re looking for new achievers to join our team. Thus, I’m excited to announce our upcoming event, SoturiSauna, to which we invite developers to meet our warriors and discuss job opportunities. SoturiSauna will be held on February 10 at Teekkarisauna (Tekniikankatu 9, 33720 Tampere).

To receive an invitation, please send an application to Spartiates@LeonidasOy.fi. Describe how you will raise us to the next level. Attach your CV, and we will get back to you as soon as possible.

See you in SoturiSauna!

-Aleksi