Rabbit 27 Feb 06

Rock on. Who says 37S doesn’t listen? :)

And yes, hooray for iterations! Now my biggest fear is I’m waiting too long to iterate… rather, releasing too much with each iteration.

I trimmed a LOT of fat off this project, but it still feels kind of… fatty. =(

Ryan Ripley 27 Feb 06

It would be interesting to see an example of where 37signals “got it wrong”, and perhaps a description of iteration and how the mistake was fixed…

Perhaps showing the process in action would sway the non-believers.

BTW: I fully buy into the Getting Real lessons. They are practical and very effective.

—Ryan

Buddy Lindsey 27 Feb 06

Problem is you don’t want to take on the GPL/GNU/OpenSource mentality either of release early and release often when you have a product that will make you money.

My question is when is a good time for a release that is effective yet allows for iterations? when the app is done or almost done? though i guess that is more based on the client or the release cycle.

JF 27 Feb 06

It would be interesting to see an example of where 37signals �got it wrong�, and perhaps a description of iteration and how the mistake was fixed�

Come to one of our workshops and we spend a good half-hour on our mistakes.

Jeff Atwood 27 Feb 06

Correct me if I’m wrong, but you guys develop life support systems, right?

niblettes 27 Feb 06

VoR and others also miss another incredibly important thing:

The 37 Signals folks are in the uniquely self-reflexive position of having to be users of their own product in order to make their own products.

So everything they make is automatically tested in the act of making. They also get to internalize and act on this learning immediately without the same communication overhead the rest of us have to pay to share such learning amongst a team.

Furthermore they also naturally empathize with the users (because, again, they are the users). They simply do not experience many of the problems personas were created to address.

37 Signals find themselves in a unique position that grants them productivity boosts that favour the kinds of loose design and development philosophies they write about here. I doubt many of us in product development find ourselves in similar positions. And so the Gospel of 37 Signals may in fact end up being to varying degrees neither relevant nor helpful the further removed we are from such a position.

In other words, fascinating stuff from an extreme perspective, but your mileage will certainly vary.

JF 27 Feb 06

your mileage will certainly vary

Absolutely. This is what works for us. Take whatever value you find and leave the rest behind.

RS 27 Feb 06

My question is when is a good time for a release that is effective yet allows for iterations? when the app is done or almost done?

Hopefully you started your app with a problem in mind, with some kind of pain you want to remove. How’s that pain? If you can eliminate a pain for someone, you are surely providing value.

Andrew 27 Feb 06

Why can’t Getting Real be the new process of software development?

In my experience the kind of “repeatable processes” I see in large beaurocratic organisations are simply used as the “safe option” (they are “proven to work”, didn’t you know??), but end up producing bloated cruftware that people want to avoid.

ReinierMeenhorst / Djust.nl 27 Feb 06

My fear i we’ll be waitin for
‘Getting real’ way too long!

Ryan Ripley 27 Feb 06

JF: Open up a seat and I’ll come.

:-)

—Ryan

CR 27 Feb 06

I read the post by Voice of Reason as more of complement to 37 Signals than a criticism of your Getting Real process. I thought the only thing he was saying was that you have some exceptional talent working for your company and that the process may not work with everyone. Now, if you were a group of mediocre talent that followed a process that someone else came up with and still achieved what you have, I would be less apt to agree. I’m also pretty positive that you have never claimed that Getting Real will make everyone into the next 37 Signals, so it may just be time for a group hug.

Hillary Johnson 27 Feb 06

I think our comfort level with innovation is largely determined by personality type. Innovators are relatively rare creatures, and as a result have very few tools designed for them. When your type is in the minority (according to the Meyers-Briggs test, innovators are something like 2-3% of the population, as I recall), there’s a tendency for the majority to label your views, methods and habits as “wrong.” But you’re not wrong—you’re just the long tail, wagging the dog.

JF 27 Feb 06

Ryan, 2 seats to the workshop are available due to cancellations.

adam 27 Feb 06

Where did he say that “Getting Real” was dangerous?

this was his quote:

It�s pretty dangerous to preach that you can capture an entire interaction, which usually has multiple steps and/or states, with a single, static sketch.

ML 27 Feb 06

Adam, he also said, “The Dr. Phil type advice you guys throw out on a weekly basis is just *dangerous*.”

Steve 27 Feb 06

I agree, in part with what they were saying. However, as has been pointed out many times, this approach is only applicable to a certain type of system or software application. In this case, it is web applications.

Two ways I could ever see this approach becoming �dangerous�:

1) People start to get lazy because they are accustom to designing and developing solutions in this way and that leads to that person or company designing and developing poor quality software that brings down the whole methodology.
2) People start to apply this approach to areas where it is clearly not to be used or even attempted. My first thought jumped immediately to mission critical systems. Jotting a design down on a piece of paper and then jumping straight into coding clearly is not the way to go in that respect. This is clearly evident. However, I�m sure somewhere down the line, someone will give it a go to save time, money, resources, etc.

Dangerous is maybe a very strong word, but when applied to the correct scenario, the comments become valid. I think in the world of web applications, that do not feature mission critical requirements, this way of developing is clearly able to deliver results if applied correctly and with a small degree of caution.

Ryan Ripley 27 Feb 06

Your merchant acccount is not very debit card friendly, JF…
:-P

—Ryan

Anonymous Coward 27 Feb 06

JF: This idea that it�s �dangerous� to Get Real is silly because Getting Real has a built-in safety net: iterations. It�s unrealistic to expect perfection out of the gate.

Just to give an example - can you imagine the control system for an air traffic control tower using this approach? Close to perfection out of the gate is certainly expected in this case. It is not always delivered, but it is expected.

In this situation, yes, the �Getting Real� design paradigm falls flat on its face. It was not intended to be used against this type of system. It works for web applications that have a user focused, non critical, requirement to fill.

Steve 27 Feb 06

Sorry, that is my comment above.

Jens Alfke 27 Feb 06

Hillary: “(according to the Meyers-Briggs test, innovators are something like 2-3% of the population, as I recall)”

Myers-Briggs doesn’t have a single “innovators” category. “INTP” is the archetypal engineer/architect type, said to be about 1 to 2% of the population (http://intp.org/faq.html#2.6), so maybe that’s what you’re remembering. It’s definitely not the only personality type that would lend itself to innovation, online or off-, though.

In particular, INTP people tend to be poor at user interface design: when frustrated users complain about how ‘normal people don’t think like those computer geeks’, they tend to have INTPs in mind.

random8r 27 Feb 06

Don’t worry guys, I live in your world! ;-)

I think that if someone isn’t a good designer or a good web app creator or a good programmer, we shouldn’t “dumb down” good practices for them - or create rules where common sense should prevail.

Things are the way they are. There’s nothing we can do about this besides accept the way they are, and once we begin to do that, that in itself is the beginning of the process of transforming - or changing - the way things are.

The quicker one can accept the way things are and work with them, the quicker one can work with changing the way things are, or transforming them into a better “way”.

The beauty of 37signals approach is that its primary mandate is “work with the way things are” - “work with what’s real”.

This means working with the real concerns of the person paying for the job if you don’t want to lose the job. It means working on the features the customer REALLY NEEDS. Now, one’s ability to provide this is a direct representation of how experienced and “wise” one is in providing the customer with what they need. It’s the same with the entire of life.

37 Signals approach is to advocate working intelligently with what’s real.

We design things to do whatever is most important first, and then gradually put in the features that are less important. If we were designing an air-traffic control system, obviously we’d need to implement the most important mission-critical features first, and then put in the “nice candy” bit later. Same with everything.

I’m designing real-use applications that are mission critical for my clients. The beauty of the 37signals approach is that we can use very good tools which lend themselves to change. We do a little, we see how the client likes it. We change a little, then we do a little more.

To align oneself with change is the real power of this approach, and it works - oh yes, it works. If you can’t design an interface, then perhaps you should learn how to design interfaces. If you can’t write programs, then perhaps you should learn how to write programs. But don’t blame lack of skill on a very useful pragmatic approach. That would be a very silly thing to do.

Random8r 27 Feb 06

I use pragmatic approaches in all of my designing and programming. Essentially, they’re extreme programming practices - which is essentially also what 37signals is advocating daily in their “Getting Real” assertions.

People don’t seem to be getting the CRUX. What is the crux? It’s “GET RID OF THE DAMN JUNK”. If something works, keep it. If it doesn’t, get rid of it. If you’d read Richard Semler’s work, you’d realise this isn’t a totally new phenomenon at all. But it *DOES* work. It works better than anything else. That’s the WHOLE DAMN POINT!

It’s THAT simple. So you can’t say “it doesn’t work in the real world!” You REALLY can’t. Why? Because the mandate is… IF IT WORKS IN THE REAL WORLD, DO IT. IF IT DOESN’T, DON’T. That’s the whole of it. Right there.

It doesn’t mean do testing. It doesn’t mean don’t show it to the customer. It means “if you’re spending a whole lot of time writing useless documents, and it’d be easier to do a small diagram - DO THAT! DO THE THING THAT WORKS!!!

Steve 27 Feb 06

random8er: …obviously we�d need to implement the most important mission-critical features first, and then put in the �nice candy� bit later.

My idea centres on the basic concepts of �Less is more� and �It just doesn�t matter�. Designing such critical systems under these conditions would be wrong. Not adding the three extra safety measures would not really do any harm, but it sure is nice to have them. They are not really needed in the sense that they will almost never get used. They still provide a function that is important to the system and the application as a whole.

If you follow the basic idea of �Getting Real� these parts of the system can really be left out. However, because it is a critical system, the idea of �More is more� tends to be applied. I can see how people could argue that the �Getting Real� concept can be applied to these systems, but in my mind, these systems need extra features and functionality that would otherwise be left out of a �Getting Real� web application. So, in this sense, you cannot apply the �Getting Real� concept to critical systems.

By very definition, systems and application that have safety in mind become very bloated and have extra features and functionality that aid other areas of the system. If I were working on such systems, I would definitely not use the �Getting Real� approach.

Functional specifications become important, as do other technical documents. Deep analysis of the problem and the possible outcomes should be explored. Diagrams and charts should be drawn up to evaluate numerical statistics.

Random8r 27 Feb 06

I totally disagree, Steve. If you have a system whose function is safety, then by its very definition, you’d need those basic things covered FIRST of all. Regardless of how often they get used - the mandate is that they get used when they’re needed - and that the important things are included FIRST.

After all, the idea is not how OFTEN features get used, it’s how CRITICAL (or IMPORTANT) the features are in the context of the system that its being used in.

If my accounting system needs certain reports that I don’t use very OFTEN, but that are critical for my work, then I’m hardly going to see it as not-necessary, am I?

Like I’ve said before, the crux of this idea is “common sense”. Common sense (which ironically perhaps isn’t found very much - making it amusing that it’s called COMMON sense) is a context-sensitive rule-free “attention-based” intelligence which cannot be systematized into a set of dead rules which are no longer relevant!!!! :-)

The idea is “put in what you need”, “use what you need”, “throw out what you don’t”.

Not “put in stuff you need often”, “throw out what you don’t need very often”.

sean coon 28 Feb 06

modeling people’s intent, desires and needs into usage scenarios isn’t a six-month long process. depending on the complexity of the system, a few weeks of research and a few weeks of synthesis. done.

the value?

well, if first impressions or initial usability/usefulness is an issue — as with a make or break brand extension into a saturated space or security software, health systems, etc., respectively — then simply prototyping and iterating doesn’t work. the behavioral gaps that *might* be found in that process, *will* be found in the first few iterations of scenarios (*not* use cases).

if the project is being created in an old-school big company, then these research artifacts and the iterative process (the scenarios themselves and the following projects/scenarios) need to become made available to all aspects of the company to provide the *user-centered* direction of the company.

if the team is small and they closely collaborate and their brand is progressive and extremely forward-thinking (and the product isn’t a health or security product), well, method can be reduced to process or even less.

if, if, if… mileage *always* varies.

so if you truly believe:

Take whatever value you find and leave the rest behind.

then VoR isn’t an “opponent.” if he/she still is, well, you’re *not* listening and you’re obviously more about selling spots at your workshop.

just sayin’

Steve 28 Feb 06

No. This method cannot be applied to such systems. My point was to illustrate the concept of thinking like 37signals do on a regular basis:

Leave only the feature you really need for your 1.0 release and then add things later. Iterating all the time.

Sure, critical systems need all the important features, but there is no way you can iterate to the degree that is suggested on these pages.

Your use of the word crux is very interesting, since, the crux of a safety system defines its complex nature. Try developing a system focused on safety using this method. Forget the complicated documents. Forget the functional specification, forget all that bloat, forget the things that �DONT REALLY MATTER� and then show me your system - fully operational and working to a high degree of functionality and safety.

My example of not putting things in that were used very often was to highlight the idea that �Getting Real� promotes. If only 10% of users need the feature, get rid of it. A good recent example being bold fonts in Campfire.

My point highlights the fact that these systems are very different and, thus, you cannot apply the �Getting Real� idea to this type of software development. In much the same way that Jason points out that this approach works for them, but might not for every one

I understand the points you are trying to make. However, I still think that the �Getting Real� principle, as is often described and talked about on this site, not in any other form, cannot be applied successfully to such systems.

This adds to my point:

Random8r: The idea is �put in what you need�, �use what you need�, �throw out what you don�t�.

This type of system needs the functional specification, it needs the deep thinking and pre planning it needs everything that 37signals advocate leaving out. Does that not go against the basic concept of ‘Getting Real’, since, these system require such development processes?

Steve 28 Feb 06

JF: It�s OK to get it wrong

It is not ok to get it wrong on such critical systems - It costs people their lives

That is not a dig at you, Jason. It is to back up my comments outlined above.

Steve 28 Feb 06

Sorry,

That is not a dig at you, Matt.

It is to back up my comments outlined above.

ek 28 Feb 06

Steve, I could be wrong, but I don’t recall anyone at 37s claiming that their approach is right for every team, every situation or every type of system.

That said, just because a system or application is “mission critical” does not mean that it has to be complex and involve huge teams of programmers, which you seem to be implying in your posts. After all, mission critical is a relative expression — I’m sure that to some firms, Basecamp has become a mission critical application, and 37s’ iterative approach seems to have worked pretty well in that case.

As for your argument that their approach can lead to programmers or product designers getting lazy, I think you’re missing the fundamental link between 37s’ advocacy for iteration and their advocacy for small development teams. It’s a lot harder to slack off when you’re part of a small group in which you know that you’ll be held accountable for your work.

A question for you: What exactly is your definition of “deep thinking,” and how exactly do you quantify the difference between it and shallow thinking? And finally, what is “pre planning” and what differentiates it from plain old planning? In your projects, do you actually set aside time to plan for planning?

Steve 28 Feb 06

Ek: Steve, I could be wrong, but I don�t recall anyone at 37s claiming that their approach is right for every team, every situation or every type of system.

Agreed. That was the point I was looking to make. This type of approach is not right for every team, situation or system. The air traffic control system being my example.

Ek: That said, just because a system or application is �mission critical� does not mean that it has to be complex and involve huge teams of programmers

Again, agreed. Critical systems can still apply some of the methods used in the �Getting Real� approach, but this is where I advise the caution mentioned in my previous post. Automatically assuming that this approach can be applied to all systems can be �dangerous�.

Ek: After all, mission critical is a relative expression

Yes, this is true. That is why I gave the specific example of the air traffic control system.

Ek: What exactly is your definition of �deep thinking,�

When taken in the context of the air traffic control system, deep thinking becomes the process of thinking about every little aspect of the system. Thinking through all the possibilities and possible outcomes, thinking about back up plans and how to control every aspect of the system, from concurrent systems to hardware/ software requirements. Thinking long and hard about the problem to avoid unnecessary loss of life.

Ek: ..do you quantify the difference between it and shallow thinking?

�shallow thinking� as you put it. Extends to the common practice delivered at 37Signals. Sketch it up on paper first, quickly, and then mock it up in HTML. Can you honestly tell me you would be happy if this approach was used to develop an air traffic control system?

�What happened?�
�Why did those planes crash?�
�Show me the technical documents and we can try to work out where our mistake was�

�Technical documents?�
�I just sketched it quickly in the back of my notebook and then started to code�
�I didn�t know I needed that feature�
�I thought I could add it later�

Ek: ..�pre planning� and what differentiates it from plain old planning?

Yes, that should have been planning and not pre planning

bort 28 Feb 06

“Come to one of our workshops and we spend a good half-hour on our mistakes.”

haha i get it now. you have to pay money to see some humility from 37signals.

danny 28 Feb 06

I agree with sean coon that this post says something very interesting about the 37signals philosophy. The need to set up “opponents”, and the marginalisation of critique (let alone user input) under the banner of “realness” (what the hell is that?) points to a particularly masculine ethic that, even as a paying customer, I’ve always been a bit suspicious of. I don’t really see what this post is saying other than “We should be able to do whatever the hell we want, because we can judge what works and then we can fix it”. The smartest guys in the room, indeed.

Well, I’m a little more skeptical. User testing (of *other* users) is not about “utopia”, but a simple realisation that not all people are like us, and will approach even the same functional task somewhat differently. Educational researchers have shown that often enough. The defensive tone of this post makes me think that 37s would rather rebut challenging perspectives, rather than learn from them. In the long term, I think that’s more likely to impact the company’s “sustainablity” than profit or cash flow.

John 28 Feb 06

To me, the main thing that Monsieur VoR is getting caught up on is that you guys have some kind of magic potion (ye olde “midas touch”) that you have had mysteriously bestowed upon you, and that your success relies on it. The success of your products and business can hardly be thrown away as supernatural X-factor ingredient. One only needs to quietly pay attention to the happenings of 37signals for a short while to understand the amount of effort that you have put into building your position.

Considering the amount of knowledge and *experience* you share with you readership, it continually surprises me that you guys have the energy to keep responding to people who either:

a) flat-out disagree with you and feel the need to tell you so after every post, or
b) *supposedly* understand where you are coming from, but scream at you to add disclaimers to everything you write.

I think I’d go mad pretty quickly… that said, I’m sure all the bickering helps you solidify your arguments ;)

The conclusion of this ramble is thus:
Thanks for continuing to write about your experiences. I really appreciate it.

RyanA 28 Feb 06

Jens: I’m apparently INTP and I’m also apparently quite good at user interface design.

Psyche!

Ryan Ripley 28 Feb 06

You guys seem to have the “big corp” mentality engrained in your heads… Honestly, where do all of the wireframes, spec’s, etc end up after a product launches… IF it launches? In my experience (yes, i work in a big corp) they end up out of date and useless within a week. Never to be looked at again. Bottom line EVERYWHERE is deliver a killer product and the rest does NOT MATTER!

Just my .02,

—Ryan

Christopher Fahey 28 Feb 06

There are two kinds of people in the world: Those who want to achieve excellence and those who emphatically want to avoid it because of the risks involved. Plenty of people and businesses “get by” plenty well and make tons of money doing exactly what 37s recommends against. Their end product is sometimes good, but more often it’s just enough to “get by”

If you personally, or your company, are the “get by” type, “getting real” may not be practical or realistic for you. Following this advice at, say, Sony, may indeed end up ruining your project and your job.

But you know what? That’s okay. If you like the idea of smaller, nimbler, smarter teams, then you shouldn’t be working at Sony. And if Sony’s market share plummets because a bunch of 37s readers start practicing the “get real” philosophy in a “get by” company, that’s fine too.

I bought a $100 chef’s knife last year, and I love it. But if my wife and I lived on TV dinners and McDonald’s, owning this knife might be considered a “dangerous” thing. Fortunately, we’re the kind of people who can safely use this knife.

Put it this way: If getting real is for you, you know who you are.

JF 28 Feb 06

Steve, I don’t think anyone’s “web design process” is appropriate for the design of an Air Traffic Control system or the Federal Reserve or the Missile Defense system.

Let’s not get off topic here. We’re talking about building web-based applications for small business and consumers.

Steve 28 Feb 06

I too work for a large company. I am a big fan of the ‘Getting Real’ approach. However, I am simply showing that it is not always easily, if at all, applied to every single given situation.

I agree that all these documents are a waste of time in most cases. In critical systems such as the air traffic control system I mentioned, they are a must. If you disagree that’s fine, but if people are designing systems that guide my plane in to land using the ‘Getting Real’ method and they follow it to the letter, I am not taking another flight in my life.

Yes. Yes. Most of the time this design principle works and it is very, very good. Not all the time, however. It is best applied to web based applications as previously mentioned.

You guys need to understand that, just because someone brings up a negative point about something you feel strongly about, it doesn’t always mean that person is against the idea or way of thinking. I like to try to debate things I have an interest in with other people who show an interest in that subject. This looks like a good place to do that - or am I wrong?

Anonymous Coward 28 Feb 06

JF: Let�s not get off topic here. We�re talking about building web-based applications for small business and consumers.

Point taken

Rahul 28 Feb 06

Pointing out that Getting Real doesn’t apply to the whole universe comes across to me as a tad redundant, especially if you dedicate half a dozen posts to reiterating the same thing. Get over it, move on. We got it (last year). You aren’t saying anything new. It’s not even particularly apt. It’s just redundant.

Aaron Blohowiak 28 Feb 06

Good tests make it safe.

But usability testing is very cool — but can be as simple as asking a guy in the next cube to do something simple (see Don’t Make Me Think by Steven Krug)

scott brookkes 28 Feb 06

If getting real was so dangerous …..would apple be publishing a how to guide for ruby on rails ?

http://developer.apple.com/tools/rubyonrails.html

keep on keeping on boys ….

cheers

Scott

sean coon 28 Feb 06

fahey! what up. i totally agree with your position.

there might be the “go for excellence” people and the “get by” people, but the “go for excellence people caught up within the politics of a get by company” is another issue. behavior is not that type of company, because you’ve designed it to be agile and nimble and smart… a boutique.

as you so aptly put it, try practicing “get real” as a designer within a firm within, say, the financial industry, and you’ll get swallowed up by blind interface requirements from business analysts and developers punching in to knock out code.

sometimes you have to bulk up in order to get into a position to trim down.

just another example of mileage varying.

(and danny is spot on as well. my primary interest in *any* research is the process of uncovering the subtle differences people have in their mental models, goals, desires, approach, etc. realizing those subtle differences often become the roots of innovation)

John 28 Feb 06

JF: Let�s not get off topic here. We�re talking about building web-based applications for small business and consumers.

I attended a Web design awards show in Minneapolis a couple of years ago. Jason was one of the judges. At the awards ceremony, Jason went to great length to praise teams that had created detailed personas, scenarios, sitemaps and wireframes as part of the Web design process. I remember him making the case that these are critical design tools.

Has 37 Signals determined that these steps are no longer necessary? Or is it simply that you are focusing on applications where your domain expertise makes them less important? If you were still in the consulting business, would you bypass these steps when working on a complex project for a new client or unfamiliar industry?

JF 28 Feb 06

That must have been more than a few years ago ;)

I used to do all that stuff (wireframes, personas, sitemaps, etc), but discovered they’re about process, not productivity. In the past few years I’ve come around to being productive and working on what’s real, not working on process and abstractions. That’s what Getting Real is all about. And once you get it, you’ll wonder how you ever did it the other way before.

I would only suggest people do what works for them. Wireframes, personas, sitemaps don’t work for me and never have. I was blinded by process thinking that if I did that stuff then the rest would just fall into place. What I discovered was the only thing that really matters is what’s real — not representations of real, not diagrams describing real, not charts that simulate real, not fake personas that represent real people.

Has 37 Signals determined that these steps are no longer necessary?

For us they are no longer necessary. I think those steps are a complete waste of time. Your mileage may vary, but I’d challenge you to try to do without them. Once you do you’ll realize how insignificant they really are.

ML 28 Feb 06

It is not ok to get it wrong on such critical systems - It costs people their lives.

This is true. Do not use Getting Real if it means you’ll wind up killing people.

I don�t really see what this post is saying other than �We should be able to do whatever the hell we want, because we can judge what works and then we can fix it�.

Not just us though. You too. Or anyone. And I’d rephrase it to: “It’s ok to do things quickly because then you build something real quickly. That means you get to actually see what works in reality and fix what doesn’t.”

The defensive tone of this post makes me think that 37s would rather rebut challenging perspectives, rather than learn from them. In the long term, I think that�s more likely to impact the company�s �sustainablity� than profit or cash flow. I like to try to debate things I have an interest in with other people who show an interest in that subject.

We’re all for a healthy debate and we encourage negative feedback if it’s constructive. That said, it sometimes feel like we can’t win with some people: When we ignore negative comments, we’re considered arrogant and lacking humility. When we respond to them, we’re considered defensive and unwilling to learn.

We’ll say it again: We know that Getting Real is not a blanket solution for every team and every situation. Getting Real works for us but it may not be for everyone. Use at your own risk, mileage may vary, don’t use it if people will die, etc. Do people really want us to end every Getting Real post with disclaimers?

Platte 28 Feb 06

Less Software complements Getting Real. If we don’t overbuild, it’s easier to get right what we do build.

The Voice of Reason 28 Feb 06

“I used to do all that stuff (wireframes, personas, sitemaps, etc), but discovered they�re about process, not productivity. In the past few years I�ve come around to being productive and working on what�s real, not working on process and abstractions. That�s what Getting Real is all about. And once you get it, you�ll wonder how you ever did it the other way before.”

JF - we’re cut from the same cloth, believe it or not. I, too, have stopped relying so heavily on documents, personas, and all that “stuff” that goes into the “proven” process. I, too, frequently produce designs that work without writing a single spec or interviewing a single user. But, much like Sidhartha, it took a long time to see what was right in front of me.

If 37s was a Buddhist colony instead of a web design JF would be the called a Master. People would flock around him, much like they do on SvN, to hear his words of wisdom and back in his glow, much like they do on SvN. And often, those who were new to the path of Enlightenment would walk away confused and empty, much like some innevitably do here on SvN.

It takes a long time to see what’s right in front of you. In the beginning, you have to recognize that processes exist that can help you reach your goals as a designer. Later, you get to know the territory really well, because you’ve spent a lot of time in it, and you can start making educated decisions that are increasingly accurate. And you can start trusting yourself as an authority, and others can start trusting you as an authority. After a while of this, providing you’ve not rested on your laurels and you’ve kept getting better, you can gradually start loosening your grip on the processes that got you where you are, and design things that work quite well without that process. And your designs will still work. And you’ll wonder why you ever did it to begin with, because you’ll forget that enduring all those rough times in rough situations is *exactly* what got you to a point where you can create great work in a much smarter, more effective and efficient way.

To those who have tried to re-explain what I said, thank you. Some of you were right, particularly “CR” and “adam”. I never said Getting Real was dangerous. I said such nuggets of wisdom like the one from two days ago, which live entirely out of context of the grand scheme of Getting Real (which, incidentally, was never even mentioned in the “sketch-to-screen” post), are dangerous to those who do not have the experience you have earned, the expertise you have built up over the years, and the innate ability to design great software with little effort.

It is entirely possible, and even likely, that a great process still leads to bad software. It’s equally likely that a team of rock stars like the 37s crew will create great software without doing any of the same things usually found in a stable web design process. (You’ve proven that. I’ve complimented you on it. Some people who read my comments even noticed. I can’t tell if you noticed or not.)

Becoming great is a long haul. Every member of the 37s team got there through blood, sweat, and tears. And now that they’re great, they denounce the things that helped make them great in favor of catch-phrases and axioms that anyone can read but few can apply with the same grand success that 37s has achieved.

jonto 28 Feb 06

It’s funny that we both referenced Asian philosophy yet have slightly different thoughts on the matter.

==============
The Voice of Reason
“I said such nuggets of wisdom … are dangerous to those who do not have the experience you have earned, the expertise you have built up over the years, and the innate ability to design great software with little effort.”
==============

I don’t think that Bruce would have agreed with this agrument as it related to his novice students. I would bet that “Master” Lee would probably have viewed it quite differently. They he was helping them from getting bogged down with the mechanistic nature of other disciplines.

JF 28 Feb 06

Hey reason, I doubt we’re cut from the same cloth if you’re suggesting that the paperwork/chart/diagram/testing process is “proven.”

sean coon 28 Feb 06

VoR, i feel you. if only we all could *understand* the river. ;-)

The Voice of Reason 28 Feb 06

I don’t get it.

My comments were well thought-out, constructive, polite, and even complimentary (again). I haven’t insulted you or 37s in any way. I’ve done quite the contrary. And 37s crew members seem to be reacting as though I am insulting everything about their solutions, which, clearly, I am not.

I’m sorry you feel the need to defend yourself to such great lengths. Apparently my signal hasn’t gotten through your noise.

Ryan Hagan 28 Feb 06

Here’s how I see it. I tend to lean towards VoR’s argument. I know that 37S has had great success with Getting Real, but the problem that I see is you preach Getting Real as gospel truth when, in fact, it’s just another process.

I, myself, run a very successful web development company and we have a process (it’s pretty much what you 37S says never works, lots of design docs, paperwork, meetings, etc.) which works extremely well for us. We have plenty of clients, plenty of cash, we get projects done when we say we’re going to get them done, and our clients love the way we keep them involved during the process.

I’m not saying Getting Real doesn’t work. It obviously has for you and I think that’s great. Anytime a web dev company figures it out and becomes successful, I’m happy.

But why do you complain about people arguing with you when you so obviously invite controversy? You know as well as I do that Getting Real is not the only way, but you constantly preach it as such and then you complain about people who disagree with you. It really is amazing.

Niklas 28 Feb 06

Murphys Law: If anything can go wrong, it will

So I think it’s better Getting Real and discover that error/failure fast, than spend time on bureaucracy and abstraction before discoering the error ;)

dmr 28 Feb 06

Get real and go outside. You people need to do something else for a few days besides debate process. That includes the 37 crew. Don’t sweat this stuff; clearly not everybody gets it.

ML 28 Feb 06

And 37s crew members seem to be reacting as though I am insulting everything about their solutions, which, clearly, I am not.

VoR, we don’t think you are insulting us. Thank you for your opinions.

Getting Real is not the only way, but you constantly preach it as such and then you complain about people who disagree with you.

We don’t think it’s the only way. We realize that. And we don’t complain about people who thoughtfully disagree with our ideas. We do get frustrated by people who seem to be unhappy no matter what we say/do. But oh well. We get over it.

JF 28 Feb 06

but the problem that I see is you preach Getting Real as gospel truth when, in fact, it�s just another process.

Holy shit. This is actually getting funny. We’ll say it for the 100th time: We don’t think this is the only way. We never have and never will. It’s one way out of a thousand ways. It’s what works for us and we share it in hopes that it may be able to help others. Take what value you find and leave the rest behind.

Elsie 28 Feb 06

I doubt we�re cut from the same cloth if you�re suggesting that the paperwork/chart/diagram/testing process is �proven.�

I think that VoR was using the term “proven” (with quotes) to reference the way that this process that involves all that “stuff” (that VoR also mentioned) is so preached about by many usability professionals and taught to us college students that are in this field.

Good times 28 Feb 06

JF and the boys are an enigma. They build products for themselves, tell everyone about the rules they use to build products for themselves, somehow manage to listen to their customers while building products for themselves, and then laugh all the way to the bank as we happily drink the kool-aid. Doesn’t matter if they’re the luckiest SOBs on the planet or if they’re really that good -we’re all using their products regardless.

Too bad we can’t all build products for ourselves.

JF 28 Feb 06

Too bad we can�t all build products for ourselves.

And why not? Who said we could and you couldn’t? You can do whatever you want to do.

Kenny 28 Feb 06

I know the Myers-Briggs INTP comment is way up the list, but as an INTP who considers himself not bad at interface design, I feel compelled to defend myself ;)

I’m sure there is truth in what you say, but in my experience, INTPs can be quite suited to i/f design and “getting real” for a couple of reasons:

- N’s have a more “big picture” view which helps
- P’s are much more likely to be comfortable with an interative approach vs a rigis product plan.

In my experience (which may be skewed), most developers are actually ISTPs anyway with a spattering of other types, particularly ISTJs.

That said, there are almost no F’s in software engineering and people tend to be *very strongly* on the T side and I think this can be the issue as F’s automatically consider the human impact of everything they do. I always found getting some F’s into the team helped with interface design (even though they’re not usually suited to coding).

E’s are also handy as they’re more likely to actually interact with the “users” ;)

matt 28 Feb 06

Instead of defending “Getting Real,” it would be even more awesomer if you guys rocked the rapid iteration you’ve been preaching lately.

This is no dig—your products have changed the way people use the web, but there’s still lots room for improvement. Keep ‘Getting Real’ and give Basecamp and Backpack some love.

Rabbit 28 Feb 06

I’m an INFP.

I love interface design.

I’m pretty damn good at it, too.

JF 28 Feb 06

Matt, there’s always room for improvement and we’re working hard on it every day. We’ve got some great Basecamp stuff coming up, then Campfire, then Backpack. We’re also making some significant behind the scene changes to increase speed and reliability. There’s lots of stuff you don’t see that needs to be done. Stay tuned.

dmr 28 Feb 06

“Too bad we can�t all build products for ourselves.”

I’m sick of this perspective. Do you make stuff for robots? Who uses your stuff? Someone talked about being more abstract, so let’s go with it. We’re all people, so build products for people, not nerds.

Jammy 28 Feb 06

So why does everyone continue to knock Microsoft, they’ve been shipping partially completed software for years.

jonto 28 Feb 06

R&D intensive companies of all sizes should keep a portfolio approach to their projects as they have to keep a balance between trailblazing new products and incremental advancements to exsisting ones. Short projects should be included with long term ones. Balance is crucial. The innovation pipeline must always be full.

Once again, think Apple’s amazing cycle. They keep introducing new at breakneck speeds. Everyone continues to knock Microsoft because they are becoming laggards in the industry that they helped create.

Master Q 28 Feb 06

Man … lets not bash microsoft….windows is sooo deep…im still finding new things about it per day…

jonto 28 Feb 06

I don’t know about anyone else, but I’m not knocking Microsoft. I’m simply replying to two different comments.

========
matt “Keep �Getting Real� and give Basecamp and Backpack some love.”

&

Jammy “So why does everyone continue to knock Microsoft, they�ve been shipping partially completed software for years.”
========

Speed is a factor when it comes to innovation. While Microsoft does seem to be “in the weeds” when it comes to their next OS (Can’t keep track of the name anymore). They seem to be doing something right in that department when it comes to their new web offerings. Has anyone read TechCrunch today?

Mike 01 Mar 06

Folks, it’s real simple: The process is not the product. What ever helps you get the product you need, with the team you’ve got, do it!

I coach (American) Football for my love job. There’s all kinds of schemes for offense & defense, but when you get down to it the basics are simple. For the players: If you out block ‘em, out tackle ‘em, and out condition ‘em and your talent in nearly equal or better, you win. For the coaches: if you adapt what you try to do to the talent you have, only do what your players understand, and prepare them well, you win, and you’ll beat some teams with better talent along the way.

It all applies in software: do the blocking (test-driven development) and tackling (continuous integration). Lay out a plan to attack the problem with the talent you’ve got and other things being equal, you win. My bias is to the agile appoach for too many reasons to go into here, but in the end it’s the execution that counts. whether you use a veer option or spread attack in football, or a plan-driven process or iterative/agile approach for software. It’s all about the execution.

Charlie Triplett 02 Mar 06

And often, those who were new to the path of Enlightenment would walk away confused and empty, much like some innevitably do here on SvN.

Well, people who do that don’t have a very good process for LEARNING (i.e. read things in context) do they?

It’s like basing your understanding of Christianity on a single scripture of the Bible. Any reasonable person would agree that historical and Biblical context aid in understanding. But God didn’t create an index and margin references; He expected us to do that on our own and actually read what’s there.

In the end, if someone tears off in a misguided direction, and fails to produce a successful application, that’s because they lacked the discipline to think things through.

Audrey 10 Oct 06

I have to say… very late comment, but I’m at a startup and they are citing “Getting Real” as a reason not to do any up-front research, that we’ll just get it out and then iterate.

Hard to imagine that’s the message, but dangerous nevertheless, if for no other reason than 8 people spent an hour and a half arguing about whether 10 hour-long interviews with potential customers might yield some useful information. >sigh