Can we do that?

Other
May 23, 2007
by Calvin Correli
3 min read

I’ve noticed a pattern that has been annoying me. We’ll be having a conversation about the development of a product, I’m feeling good, things are flowing, we’re coming up with ideas. But then someone asks the question “Can we do that?”, directed at me as the programmer, and my body tightens up and my smile disappears.



This has been going on for a while, and I just couldn’t get a grip on why it happened. At first I didn’t notice when exactly my state changed, so I didn’t catch the connection with the question.



But now that I saw that, I’ve been noticing what’s going on. What happens is that the question puts me into a different frame of mind. From focusing on the user or the business, I’m now asked to focus on the technology. My mind will start racing to find and compare various ways to implement what we’re talking about, comparing their various merits, thinking about which options would be worth the time to do, what the on-going maintenance burden of various options are, what the potential downsides and side-effects are, what paths could this close for the future.



Once I start down this path, it’s hard to return to the free-flowing state I was in before. Often the session will be derailed from here on, at least for a good while, unless, that is, awareness kicks in, so I can consciously get myself back on track.



It’s not that one mindset is better than the other. Both are necessary to build successful software. It’s just that they shouldn’t be mixed.



Alan Cooper said that the same person could easily be both an interaction designer and a programmer. Just not on the same project! Because the technology demands so much of our brain, it’s really difficult to silence the part of your brain that’s thinking about implementation once you’re involved.



I agree with Cooper, but I also find that it can be done, at least to the extent that I become a valuable party to the conversation, but that it requires conscious effort, and it’s extremely difficult to switch back and forth within the same session.



It’s somewhat like the six thinking hats. You need different perspectives, just not all at the same time.



Do you recognize this from your own line of work? How about outside of technology? I’d be curious to hear your experiences.

Like

About Calvin Correli

I've spent the last 17 years learning, growing, healing, and discovering who I truly am, so that I'm now living every day aligned with my life's purpose.

Read more
Read next

The perfect job

14 comments

Mark Aufflick
 

Totally the same. I do find it gets better as a project goes along though. 2003-2004 I worked on a very long project. Basically the same client and codebase for 18 months. I found that I became so immersed in both the code and the business that I could talk with the business and visualise software design, or design/code software and visualise the business roles/actions etc. The funny thing about that question is that there are two parts to the answer, and one part is always the same. Yes we can do it - here'w how much it will cost and how long it will take. You can use that to help deflect the question and stay in creative mode. I say something like: bq. __"Yes we can do that - we can do anything! But determining how much it will cost or how long it will take is not a question I can answer right now. What we need to do is figure out the solution that will best meet your needs and I can discuss any compromises that development and budget practicalities may require at our next meeting."__ Not only does it prevent you from going into the coding mind, it helps educate the client about the different phases of planning. It also means you're not taking their time up in meetings working through the implementation details in your head when you're better off doing that later. That's how I approach the problem in the same space as you. I too would love to hear how others deal with it - especially in a non-software environment. I'm sure people like architects and film directors have exactly the same problem.
Read more
Read less
Reply over 17 years ago
  Cancel
Lars Pind
 

Mark, Your standard answer is exactly right. It's both factually correct, and it addresses the problem of frame of mind pretty directly. I guess I've always felt that the "we can do anything" part was too fluffy and not what the person was asking, but then again, the person probably doesn't know that it's not in his best interest to ask that question, and its my responsibility to educate him. One thing that's been holding me back from doing this is some deep-seated respect for "The Question". Like if someone asks me something, I have to take the question literally and provide a literal answer to that. Sometimes it's a strength, because it means I won't just dabble a canned answer to some question, I'll actually consider what's being asked, and give it real thought. But in situations like these, where it's clearly not in the asker's best interest to get the answer to the question he's actually asking, it's problematic. It reminds me of another Alan Cooper story. There's this guy in a small airplane flying around Seattle, and he gets lost, can't find the airport. Thankfully he passes a tall office building where a guy is sitting by an open window, so he shouts down to him to ask where he is. The person in the building answers "You're in an airplane about 300 feet above ground". "Thank you", replies the man in the airplane, finds the airport, and lands it. How did he know where he was? "Well, the question was perfectly accurate, yet perfectly useless to me, so I knew it had to be an engineer, and since the only tall engineering building is on the Microsoft campus, I knew that's where I was, and I knew the airport was just west of the campus."
Read more
Read less
Reply over 17 years ago
  Cancel
robin
 

I studied architecture at university. You could get in two ways: the usual route (one year at uni doing a wide range of different papers, plus a portfolio of work - I did this) or work as a draftsperson (drawing architect's designs) for some years, then apply. Very few people are successful with the second route. My guess is this is because very few draftspeople IMO make good architects. As soon as their design thoughts start kicking around, they are already thinking how to construct the design. Now, this in itself isn't a problem. Where it becomes a problem is when the person concerned has a restricted building vocabulary (most draftspeople are like this, which is what makes them useful for certain tasks) and then they are severely restricted by their thinking. However, a guy I knew (he, his girlfriend and I used to go out for coffee at 2 or 3AM when working on stuff) did a masters degree in architecture and a masters degree in engineering, and he was (is?) able to hold it all together. I asked him why, and he said that he was sick of asking engineers whether something was possible to build or not and battling them to the point where they'd do the work to make it possible (the implication being that initally they'd do some calcs and come up with a simpler - for them - solution that didn't suit design goals but would stand up structurally ok).
Read more
Read less
Reply over 17 years ago
  Cancel
Lars Pind
 

Robin, That's very interesting indeed. Architecture and software certainly have many aspects in common. I think any engineer knows the situation where you say it can't be done, only to have some non-engineer come up with the idea how it could be done. They're not bound by the same constraints you are, so they can be more creative about it. There's always another way to solve a problem, you just have to keep digging, and especially look outside the unnamed constrains. A surgeon once told me that his teacher always taught him to find at least 17 ways to solve any problem he encountered in his work. And she would insist on it, and litarelly go "that's a really good idea, now 14 more!" The connection between language and thinking is important as well. Not sure how it relates to my original question, but it's clear that your vocabulary constrains your thinking about a problem. In software, however, simpler is often the better solution. But the trick is that there's not a single simple solution. There's myriads.
Read more
Read less
Reply over 17 years ago
  Cancel
Mark Aufflick
 

Lars - you're right about avoiding fluffy hand waving answers - I think it's a matter of context. If someone asks "can we do it" a week from final delivery, then they mean "can we do it in time" and it's appropriate to stop the flow and figure that out. Usually though, I find that non-programmers actually don't realise that literally anything they can imagine is possible. It may not be practical, but it really is possible. Perhaps an audacious belief that anything really is possible is necessary (like in your Spielberg post). Robin - that's really interesting. I've been involved in building projects where the builders complain that the architect is asking the impossible, but then they usually seem to make it happen. It's easy to become cynical when you see many building projects fail or fall behind schedule because of an overly ambitious plan I guess. I really like the idea of being both, like your friend, because it let's you avoid both extremes and instead create a result that neither alone would. You can achieve the same if you have a very close relationship between two people. Maybe there is a design just 10% less interesting than the original but 70% cheaper to produce. Conversely maybe there's an interesting twist to a standard technique that adds only minimal cost but yields a much more interesting or useful result. You won't get that perspective unless you understand both, but then we get to Lars' original problem. Lars - I love that 17 ways idea! Sounds like a great idea for a website (but 17ways.com is already registered, I just checked...). I too am convinced about the connection between language and thinking. Unless someone thinks of a better way we all make our concrete thoughts in words. Even taking <a href="http://www.amazon.com/Blink-Power-Thinking-Without/dp/0316010669/">Blink</a> into account, we end up thinking about our impressions in words. That's one reason I really enjoy the Perl coding community - they get language. Larry Wall was a linguist when he designed Perl, and he designed it to be expressive. There are a lot of Perl programmers who are linguists or whatever else first, programmers second. That means they have a need and then they hack prod and squeeze the code until it does what they want. I guess that's the way I think about things - what do I want to see happen, keep searching and trying things out until I find a way to achieve it. Sometimes (well, most times) I fail, but you can't let that reduce the size of your ideas.
Read more
Read less
Reply over 17 years ago
  Cancel
Mark Aufflick
 

Thinking of abstraction and Blink, maybe that's a key part of the solution. Decide before a discussion/meeting what level of abstraction you're willing to go down to. Anything below that level use your immediate instincts. Someone says "can we change the web site to a consumer focussed site instead of a B2B site?". That question has both business and technical implications - both start above my chosen depth of abstraction. So I think about it, and I realise that the whole design of the site will need to change from being based around companies with multiple users, to being user focussed. Can it be done? Of course. Can it be done within the 6 months until completion? Ok so now we're approaching the depth of abstraction. What does my gut instinct tell you? I've done enough of these sorts of projects to know if it's in the order of weeks months or more than a year. If my immediate reaction is weeks, say "yes absolutely" and move on. If my immediate reaction is months then say "we could, but we'd have to drop some other features or push back the delivery date". If my immediate reaction is more than a year say "no way". In fact if this idea has legs, maybe it would be beneficial to alert clients to it up front. I could lay down a rule that anything past a certain granularity I won't even discuss in design meetings and allow everyone in the meeting (business as well) the safety of knowing that you have a week to confirm or change any gut decisions that were made.
Read more
Read less
Reply over 17 years ago
  Cancel
Lars Pind
 

Mark, I love the renaissance perspective that you can be both engineer and designer. I'm a strong believer in the value to that, as demonstrated by both Leornardo da Vinci and "James Dyson":amazon:1587991705. I have myself found that in highly expressive agile development environments like Rails or, I'm sure, Perl, you can indeed switch back and forth pretty effortlessly for many things. But there's always things that go deep, the parts that in "Fred Brooks'":amazon:0201835959 terms are intrinsic to the task of programming, and then you have to start switching. That's okay, though. Thinking about the implementation can give you insights about the design. If one design is 5 lines of code, and another is 45, chances are that the shorter one is a better design, too. Not always, but it's a clue. And thinking about design can give you insights about implementation. The problem arises when there's friction in the room because we're wearing different hats. The solution is to be consciously aware of which hat we're all wearing. I love the Six Thinking Hats idea. I've never actually implemented it verbatim, but I've adopted the general idea. And there's one other part, too. When I'm the only programmer on a project, I often feel lonely in the work of figuring out the implementation. Part of the frustration here is that a large part of that work, it seems, doesn't really require knowledge of things of technical nature. They're more about logic and reasoning, if we collect this info here, and then the user does this, what are we left with. Basic stuff that requires thorough analytical thought, but not a computer science degree. This is a somewhat different matter, but I'd still be curious if others have experienced this.
Read more
Read less
Reply over 17 years ago
  Cancel
robin
 

@Lars: language IMO is the basic building blocks for thought (as opposed to instinct). On simplicty (in software, or anything really): in my experience, simplicity is very difficult. Easy to come up with complex solutions, but simple is hard. Obvious, maybe, when done, but only in retrospect. @Mark: builders and engineers - in the construction industry, rarely seem to achieve anything but the ordinary. Their tasks are suited to solving problems that they are presented with. It is in their nature to want this task to be as easy as possible. Good work is hard. Sometimes it comes quickly (often due to many years of thought, experience and development, which may not be apparent) but it's hard. Oh by the way, I walked past Malcolm Gladwell the other day. Decided not to bug him, but maybe I should have just said hi ...
Read more
Read less
Reply over 17 years ago
  Cancel
Lars Pind
 

@Robin: Where did you see Malcolm Gladwell?
Read more
Read less
Reply over 17 years ago
  Cancel
robin
 

@Lars: Auckland, NZ.
Read more
Read less
Reply over 17 years ago
  Cancel
Mark Aufflick
 

"Whenever an engineer builds something that's over-complicated, that's the mark of an inferior design. Simple is always better." -- Jamie Hyneman, Mythbusters And if you can't trust the Mythbusters, who can you trust :) Do you get the Mythbusters Discovery Channel show in Denmark? Hey Robin that's cool that you saw Malcom Gladwell - I'm going to be in Auckland in a few weeks - maybe I'll bump into him too!
Read more
Read less
Reply over 17 years ago
  Cancel
robin
 

@Mark: you'll need a time-machine :O) What are you doing in Auckland? rob at tohunga dot co dot uk
Read more
Read less
Reply over 17 years ago
  Cancel
RasmusJ
 

A great point to make. And I've experienced it too...been caught up in it, as well as drifted off into contemplating the issue when attending design or technology sessions, where I could sense the lapse into the off-topical. Recently, I did a project management course - on of the more instructional and formalistic kinds. The same topic emerged when we started discussing whether it is an advantage for a project manager to actually have technical domain knowledge beforehand. The exact same topic we touched at Uni, Lars, about ethnometodology and the problem of the external vs. the participatory observer. I'm not sure what the answer is - but regarding certain parts of any project (probably the initial phases) I'm beginning to think that a project manager or design session facilitator (call it whatever you like) needs to be focusing strictly on the meta-level communications. If you're used to doing it, I guess one person could pull off that role - and then delve himself/herself into technical issues on other occasions. But I think it requires so much energy and knowledge distribution to have it succeed on an entire team, that most people give up any strict discipline on the matter. Not to mention, that it feels awkward to actively regulate and "sharpen" the discourse in design sessions that are usually expected to be open, creative and loosely structured.
Read more
Read less
Reply over 17 years ago
  Cancel
Jesper Rønn-Jensen
 

I totally recognize this from my own working days. However, I don't always feel that the frown stays when shifting hats. Usually it can help if you push somebody else into playing the technical role -- we have some enterprise architects at work that are easily pushed into that technical role :)
Read more
Read less
Reply over 17 years ago
  Cancel

Leave a comment