Comments on: The Devil’s in Both (the details and the big picture) http://blog.arc90.com/2007/02/12/the-devils-in-both-the-details-and-the-big-picture/ Web Application Design & Development Thu, 29 Jul 2010 10:34:30 -0400 http://wordpress.org/?v=2.9.1 hourly 1 By: Joel http://blog.arc90.com/2007/02/12/the-devils-in-both-the-details-and-the-big-picture/#comment-274 Joel Wed, 14 Feb 2007 03:14:20 +0000 http://blog.daniell.acr90-dev-02/2007/02/12/the-devils-in-both-the-details-and-the-big-picture/#comment-274 I think a singular vision is handy to keep the project on track, but it can also be a very effective way to fully realize a crappy idea. Also, it never happens. I've never had a client's singular vision stay constant during any IT project of any size. People don't know what they want until they try it on for size (aka early prototyping, as you describe), but having at least two people bounce ideas off each other - on the business side as well as the tech side - will immeasurably improve the final product by correcting the course as you go. You may delay the project early on, but discovering just one problem in week 3 instead of week 13 is worth it. The way you described structuring a 15-person project is key: divide the app and establish ironclad interfaces between them. For most apps, the "singular vision" means the business layer. Everything else is plumbing or eye candy. If your app's success relies on your web designer or DBA having a deep understanding of your client's business, you are, generally speaking, in big trouble. I think a singular vision is handy to keep the project on track, but it can also be a very effective way to fully realize a crappy idea. Also, it never happens. I’ve never had a client’s singular vision stay constant during any IT project of any size.
People don’t know what they want until they try it on for size (aka early prototyping, as you describe), but having at least two people bounce ideas off each other – on the business side as well as the tech side – will immeasurably improve the final product by correcting the course as you go. You may delay the project early on, but discovering just one problem in week 3 instead of week 13 is worth it.
The way you described structuring a 15-person project is key: divide the app and establish ironclad interfaces between them. For most apps, the “singular vision” means the business layer. Everything else is plumbing or eye candy. If your app’s success relies on your web designer or DBA having a deep understanding of your client’s business, you are, generally speaking, in big trouble.

]]> By: Jay http://blog.arc90.com/2007/02/12/the-devils-in-both-the-details-and-the-big-picture/#comment-273 Jay Tue, 13 Feb 2007 15:58:46 +0000 http://blog.daniell.acr90-dev-02/2007/02/12/the-devils-in-both-the-details-and-the-big-picture/#comment-273 Very insightful post Tim. I'm going to pick up the book from Amazon right away. Regarding the importance of a singular vision, I can't agree more. At my company, we've used a methodology called Contextual Inquiry (CI) which supports this cause. A small cross-functional team (marketing, product managers, engineers, support) goes out to customers, gathers data by watching users work, synthesizes that data, and visions a response to the need by inventing new software. What is brilliant about this technique is that when a software developer is in the depth of coding, he/she is grounded on real user data that they were a part of gathering. The users infect his/her head, subconsciously directing the developer to keep focused and not over-engineer. As a product manager (the singular keeper of the vision), I may not have the skill set to decide whether a coder should code one way or another, but with CI, I can feel confident that is grounded on the customer need. You not only need: 1. a singular vision 2. a singular keeper of the vision (leader) but also a way for the team to be immersed in that vision and directed by the vision when the leader is not there. Very insightful post Tim. I’m going to pick up the book from Amazon right away.
Regarding the importance of a singular vision, I can’t agree more. At my company, we’ve used a methodology called Contextual Inquiry (CI) which supports this cause. A small cross-functional team (marketing, product managers, engineers, support) goes out to customers, gathers data by watching users work, synthesizes that data, and visions a response to the need by inventing new software.
What is brilliant about this technique is that when a software developer is in the depth of coding, he/she is grounded on real user data that they were a part of gathering. The users infect his/her head, subconsciously directing the developer to keep focused and not over-engineer.
As a product manager (the singular keeper of the vision), I may not have the skill set to decide whether a coder should code one way or another, but with CI, I can feel confident that is grounded on the customer need.
You not only need:
1. a singular vision
2. a singular keeper of the vision (leader)
but also a way for the team to be immersed in that vision and directed by the vision when the leader is not there.

]]> By: Tim http://blog.arc90.com/2007/02/12/the-devils-in-both-the-details-and-the-big-picture/#comment-272 Tim Tue, 13 Feb 2007 14:52:02 +0000 http://blog.daniell.acr90-dev-02/2007/02/12/the-devils-in-both-the-details-and-the-big-picture/#comment-272 Avi: wouldn't you agree that even though Keynote addresses an existing concept (presentations) it does it in a way that would be considered 'new'? <a href="http://www.presentationzen.com/presentationzen/2005/11/the_zen_estheti.html" rel="nofollow">I've seen Keynote presentations, and to me they certainly stand apart from those in PowerPoint</a> - and therefore Keynote was "worth making" precisely to enable those differences. Avi: wouldn’t you agree that even though Keynote addresses an existing concept (presentations) it does it in a way that would be considered ‘new’? I’ve seen Keynote presentations, and to me they certainly stand apart from those in PowerPoint – and therefore Keynote was “worth making” precisely to enable those differences.

]]> By: Avi Flax http://blog.arc90.com/2007/02/12/the-devils-in-both-the-details-and-the-big-picture/#comment-271 Avi Flax Tue, 13 Feb 2007 14:42:54 +0000 http://blog.daniell.acr90-dev-02/2007/02/12/the-devils-in-both-the-details-and-the-big-picture/#comment-271 <blockquote>Software is easy to make, except when you want it to do something new. The only software that's worth making is software that does something new. That about says it all.</blockquote> I don't know about that. Sometimes a software program comes along which does not do something new, but it does its thing <em>way better</em> than everything before it. For example: <a href="http://www.apple.com/iwork/keynote/" rel="nofollow">Apple's Keynote</a>. Software which raises the bar in its category is worth making.

Software is easy to make, except when you want it to do something new. The only software that’s worth making is software that does something new. That about says it all.

I don’t know about that. Sometimes a software program comes along which does not do something new, but it does its thing way better than everything before it. For example: Apple’s Keynote. Software which raises the bar in its category is worth making.

]]> By: Chris LoSacco http://blog.arc90.com/2007/02/12/the-devils-in-both-the-details-and-the-big-picture/#comment-270 Chris LoSacco Tue, 13 Feb 2007 13:02:39 +0000 http://blog.daniell.acr90-dev-02/2007/02/12/the-devils-in-both-the-details-and-the-big-picture/#comment-270 I think this is one of the highlights - <blockquote>Software development is often compared to construction, and the metaphor here is the model, where you build a model of the home before ground is broken. But software "models" are even more powerful, as you can't sleep in the bedroom of the model of the home, but you can fully interact with a good software prototype.</blockquote> This is such a key distinction that is often lost when drawing parallels between software and other industries. An incremental software process produces so much along the way that it's not about (or even desirable to think in terms of) the wait for the "final" version. There are no <em>final</em> versions. There are useful things to be gained by comparison to what's come before, but software is its own beast, and we (as developers, producers, <em>architects</em> in a whole new sense) need to treat it so. Only then will we be able to progress. (By the way, I'm 70 pages in to <em>Dreaming</em>, and already I can see why it's a must-read.) I think this is one of the highlights -

Software development is often compared to construction, and the metaphor here is the model, where you build a model of the home before ground is broken. But software “models” are even more powerful, as you can’t sleep in the bedroom of the model of the home, but you can fully interact with a good software prototype.

This is such a key distinction that is often lost when drawing parallels between software and other industries. An incremental software process produces so much along the way that it’s not about (or even desirable to think in terms of) the wait for the “final” version. There are no final versions. There are useful things to be gained by comparison to what’s come before, but software is its own beast, and we (as developers, producers, architects in a whole new sense) need to treat it so. Only then will we be able to progress.
(By the way, I’m 70 pages in to Dreaming, and already I can see why it’s a must-read.)

]]> By: Tim http://blog.arc90.com/2007/02/12/the-devils-in-both-the-details-and-the-big-picture/#comment-269 Tim Mon, 12 Feb 2007 21:10:10 +0000 http://blog.daniell.acr90-dev-02/2007/02/12/the-devils-in-both-the-details-and-the-big-picture/#comment-269 Good point Chris, I was thinking that this would come up in response to my comment about a singular vision. I suppose it is possible for a group of people to have a singular vision, and collectively be a singular keeper of that vision - but that's tricky. Humans inherently make things their own, draw on their past experiences and strengths, etc. Like I said above, many people can influence and shape a software product, but I maintain that there needs to be a single keeper of the original vision and an arbiter that can correct course when it inevitably veers. As to open source and how that plays in - for one, you definitely should read this book, it addresses this directly (as Chandler is being built open source). Also, my comment above speaks to this, as even Linux, the most heralded of open source efforts, has a <a href="http://www.wired.com/wired/archive/11.11/linus.html" rel="nofollow">benevolent dictator (for life.)</a> Good point Chris, I was thinking that this would come up in response to my comment about a singular vision.
I suppose it is possible for a group of people to have a singular vision, and collectively be a singular keeper of that vision – but that’s tricky. Humans inherently make things their own, draw on their past experiences and strengths, etc. Like I said above, many people can influence and shape a software product, but I maintain that there needs to be a single keeper of the original vision and an arbiter that can correct course when it inevitably veers.
As to open source and how that plays in – for one, you definitely should read this book, it addresses this directly (as Chandler is being built open source). Also, my comment above speaks to this, as even Linux, the most heralded of open source efforts, has a benevolent dictator (for life.)

]]> By: Chris D http://blog.arc90.com/2007/02/12/the-devils-in-both-the-details-and-the-big-picture/#comment-268 Chris D Mon, 12 Feb 2007 20:28:19 +0000 http://blog.daniell.acr90-dev-02/2007/02/12/the-devils-in-both-the-details-and-the-big-picture/#comment-268 Excellent article. I have some questions about one part in particular though: "Good software requires a singular vision, and a singular keeper of that vision." Part of me wants to argue that this is not always beneficial. In general, great ideas do not necessarily all come from one source. I think open source projects have definitely shown this to be true. While there can definitely be the "too many cooks in the kitchen" phenomena in OSS, I feel like overall the benefits outweigh the costs. Many successful open source software groups may not have a singular vision, but pull ideas in from all over the place. The signal to noise ratio as a result is fairly bad, but if an effective system of filtering the good ideas to the top can be implemented, then I feel this is better than a singular keeper of the vision. Excellent article. I have some questions about one part in particular though:
“Good software requires a singular vision, and a singular keeper of that vision.”
Part of me wants to argue that this is not always beneficial. In general, great ideas do not necessarily all come from one source.
I think open source projects have definitely shown this to be true. While there can definitely be the “too many cooks in the kitchen” phenomena in OSS, I feel like overall the benefits outweigh the costs.
Many successful open source software groups may not have a singular vision, but pull ideas in from all over the place. The signal to noise ratio as a result is fairly bad, but if an effective system of filtering the good ideas to the top can be implemented, then I feel this is better than a singular keeper of the vision.

]]>