Don’t build. Compose(medium.com)
medium.com
Don’t build. Compose
https://medium.com/on-startups/305a31ff609
17 comments
I agree there's a range, but if you have to abandon an analogy to describe another end of the range, then it's time to find a new analogy. I think one trap in the article's logic is thinking that all structural engineering is at the scale of bay-spanning bridges or skyscrapers. Structural engineering can range from structures that withstand earthquakes down to a shack to stash your garden tools--just because one end of the continuum requires more rigor than the other doesn't make them unrelated.
In software engineering there are still rigorous requirements in fields that run software on other planets or in medical systems, but there's software with looser requirements as well.
The best metaphor I've encountered for the wide variety of software engineering was a talk that covered the book "How Buildings Learn" http://www.amazon.com/How-Buildings-Learn/dp/0140139966 -- there are structures that favor adaptability, and others that favor rigor, but that doesn't mean that structural engineering doesn't happen on one end of the continuum compared to the other.
(To be fair, there are rigorous forms of writing, too, but I think restricting the analogy to only novels is too narrow to be effective.)
In software engineering there are still rigorous requirements in fields that run software on other planets or in medical systems, but there's software with looser requirements as well.
The best metaphor I've encountered for the wide variety of software engineering was a talk that covered the book "How Buildings Learn" http://www.amazon.com/How-Buildings-Learn/dp/0140139966 -- there are structures that favor adaptability, and others that favor rigor, but that doesn't mean that structural engineering doesn't happen on one end of the continuum compared to the other.
(To be fair, there are rigorous forms of writing, too, but I think restricting the analogy to only novels is too narrow to be effective.)
A counterpoint: I write algorithms. I don't have customers that come to me saying, "I want an external sorting algorithm that is tuned to SSDs and APU's;" rather, I take an existing question or open problem, mull it over, arrive at another question, find a few answers along the way, and eventually I find a way to map the math to the metal. It's bottom up, usually, and generally, rather than composing something deeply personal, I eliminate touches I identify as personal until there's nothing of me left in the algorithm. So what I find illuminating about this post is not that most software is unlike building bridges, but that what I do is like building bridges. See also, https://news.ycombinator.com/item?id=3575449
I question the notion that, just because the terms we use match up with another discipline (and this is likely not the only one), we are necessarily drawing a direct comparison with that other discipline by using those terms.
Programming/development/whatever is full of ridiculous terms. We co-opt them from anywhere we want, we make them up, we apply them in multiple outlandish ways. We don't really need a reason, because "we" in this case means "people who decide what to call things," and it's not as though we have a Bureau of Naming for the Computational Applied Sciences running around forcing us to use good metaphors.
I can see it being fun to throw around theories about how we came to use the various terms that occur in our field, but I definitely don't see them as being strict (or even, in most cases, loose) direct references to the same terms' usage in other fields. Sometimes a term works for someone; sometimes the generic terms that work for different people line up in ways that make sense in more than one context.
This just reads too much into that.
Programming/development/whatever is full of ridiculous terms. We co-opt them from anywhere we want, we make them up, we apply them in multiple outlandish ways. We don't really need a reason, because "we" in this case means "people who decide what to call things," and it's not as though we have a Bureau of Naming for the Computational Applied Sciences running around forcing us to use good metaphors.
I can see it being fun to throw around theories about how we came to use the various terms that occur in our field, but I definitely don't see them as being strict (or even, in most cases, loose) direct references to the same terms' usage in other fields. Sometimes a term works for someone; sometimes the generic terms that work for different people line up in ways that make sense in more than one context.
This just reads too much into that.
I surely agree with you in the general, but I enjoy the line of the thinking that the OP is going down. The way I see it is that the language we use dictates how we think about problem solving. Even if we don't port the strict definition of a term one-to-one, we are still anchoring our approach to the mind-space that the other term occupies.
I read this post is as saying that we are no longer using the appropriate metaphors -- we are anchoring on counter-productive terms. These metaphors clearly were relevant at some point, but the field in which product developers play in has changed dramatically. If the game has changed, then it would seem that anchoring our language on new metaphors would make sense. If we use strong metaphors that more closely resemble the work we are doing, it could help us accelerate our problem solving.
As with all ideas, we will see if others agree with the OP. Personally, I think the newly proposed metaphor of composition is more descriptive than that of building.
I read this post is as saying that we are no longer using the appropriate metaphors -- we are anchoring on counter-productive terms. These metaphors clearly were relevant at some point, but the field in which product developers play in has changed dramatically. If the game has changed, then it would seem that anchoring our language on new metaphors would make sense. If we use strong metaphors that more closely resemble the work we are doing, it could help us accelerate our problem solving.
As with all ideas, we will see if others agree with the OP. Personally, I think the newly proposed metaphor of composition is more descriptive than that of building.
Similarly, you could look at what an Artist does with a painting.
I think looking at coding as an art has a few fundamental problems however. It may be extremely appealing to aim for beautiful and elegant code, but it doesn't satisfy the goal of coding. Code has a need of being practical, of working. It is a balance between function and form. I think going to far in either direction will not pay off in most cases. Too much time is either wasted writing a piece seen as acceptable, or re-factoring the code at later stages.
I think looking at coding as an art has a few fundamental problems however. It may be extremely appealing to aim for beautiful and elegant code, but it doesn't satisfy the goal of coding. Code has a need of being practical, of working. It is a balance between function and form. I think going to far in either direction will not pay off in most cases. Too much time is either wasted writing a piece seen as acceptable, or re-factoring the code at later stages.
As someone who works as a software engineer and paints for fun, I've used the analogy once or twice.
But it only holds a little.
It holds in the sense that most of the time you start with an empty canvas. You use the tools you have at hand or the tools you wish to learn more about. You tend to plan ahead enough to prevent structural mistakes, to make sure your work comes out the way you envisioned it. It holds in the sense that only 'a fellow artist' can begin to understand the details of what you did and how that fits or doesn't fit in the work at large. It holds in the sense that you shouldn't ever start out with the details when performing either activity.
When you code something you do it to specification, which could be analogous to one being contracted for a particular piece of art.
The coding and art analogy doesn't hold when I consider the emotions that shape my art and drive me to create it that way, and the different result that it has on different people when they pay attention to it. It doesn't hold when I look at how one does flesh out detail. I myself start out with a general sense of the space that an entity will not be occupying. I describe that space in more and more detail until it approaches the space that it will be occupying. Then I can start placing marks that describe the details of that entity, in increasing detail. Programming has no analogy to that as far as I'm aware. It also rarely holds when you consider particular methods such as the 'test' part of test driven development.
This is probably something that only applies to me though, because everybody who programmes or paints has their own way of working.
It holds in the sense that most of the time you start with an empty canvas. You use the tools you have at hand or the tools you wish to learn more about. You tend to plan ahead enough to prevent structural mistakes, to make sure your work comes out the way you envisioned it. It holds in the sense that only 'a fellow artist' can begin to understand the details of what you did and how that fits or doesn't fit in the work at large. It holds in the sense that you shouldn't ever start out with the details when performing either activity.
When you code something you do it to specification, which could be analogous to one being contracted for a particular piece of art.
The coding and art analogy doesn't hold when I consider the emotions that shape my art and drive me to create it that way, and the different result that it has on different people when they pay attention to it. It doesn't hold when I look at how one does flesh out detail. I myself start out with a general sense of the space that an entity will not be occupying. I describe that space in more and more detail until it approaches the space that it will be occupying. Then I can start placing marks that describe the details of that entity, in increasing detail. Programming has no analogy to that as far as I'm aware. It also rarely holds when you consider particular methods such as the 'test' part of test driven development.
This is probably something that only applies to me though, because everybody who programmes or paints has their own way of working.
I think this is exactly why many of us find the architecture, or "civil engineering", metaphor so appealing. Architecture is neither pure art nor pure science. It's a delicate balance of form and function, beauty and practicality.
In fact, I think the article only manages to make the architecture metaphor appear more fitting. Even when you're building a bridge, you never really "put in the last rivet and make the last weld." Read about any historic bridge and you'll quickly learn that the life of a bridge can be as dynamic as any novel. London bridge was redesigned and rebuilt (refactored?) on several occasions since Roman times. The Brooklyn Bridge was conceived by a man, continued by his son, and completed by his daughter-in-law.
In fact, I think the article only manages to make the architecture metaphor appear more fitting. Even when you're building a bridge, you never really "put in the last rivet and make the last weld." Read about any historic bridge and you'll quickly learn that the life of a bridge can be as dynamic as any novel. London bridge was redesigned and rebuilt (refactored?) on several occasions since Roman times. The Brooklyn Bridge was conceived by a man, continued by his son, and completed by his daughter-in-law.
The problem with the novel authorship metaphor is that it's too close to the literal act of authoring software to be useful. The terms involved in the metaphor (author, editor, publisher, composition, rewrites, etc) all have more specific literal meanings and are therefore confusing. A metaphor should be properly removed from its subject to inspire objectivitity.
For those who haven't seen one of the "tire swing" cartoons mentioned in the article: http://www.projectcartoon.com/create/ and some historical versions: http://www.businessballs.com/treeswing.htm :)
I would agree that certain aspects of programming is quite similar to writing. Both require a certain command of the raw materials and good taste and judgement in how to assemble those
materials into finished form. The analogy works because these are general statements that could apply to many kinds of creative endeavors. However, as soon as one gets so specific as to map the roles of "product guys" and "engineers" and "editors" and "authors", the analogy has long since left the room.
Though I don't think that this analogy fits well, I applaud the OP for it; this kind of analogical thinking is, after all, thinking about what he does and how it relates to other other aspects of life.
Though I don't think that this analogy fits well, I applaud the OP for it; this kind of analogical thinking is, after all, thinking about what he does and how it relates to other other aspects of life.
Let's not confuse product with implementation.
Someone still needs to choose and arrange data-structures and algorithms to fit available resources. That is engineering. Just because the product is ill-defined and subjectively-judged does not lessen that.
You might want an architect to be sensitive to aesthetic/political/whatever concerns, but you pay the engineers to make sure the thing stays standing up. Does a building stand up because of story-arc and character development? No, it is because of understanding of physics and materials. The same holds essentially for getting computation done within time and space.
Someone still needs to choose and arrange data-structures and algorithms to fit available resources. That is engineering. Just because the product is ill-defined and subjectively-judged does not lessen that.
You might want an architect to be sensitive to aesthetic/political/whatever concerns, but you pay the engineers to make sure the thing stays standing up. Does a building stand up because of story-arc and character development? No, it is because of understanding of physics and materials. The same holds essentially for getting computation done within time and space.
I like this writing analogy a lot, because software is subjective. Doneness is subjective according to how its creators define it. User experience is subjective. Even overall quality depends on consensus opinion. Software is an art form.
To someone that doesn't actually write code, sure, it may be just that easy to use terminology alone to draw the parallel.
Your comment seems unduly negative. But, after reading the article it really does seem like a forced analogy.
I suppose in some ways it's quite surprising that writing code is so much different than writing a novel. They are after all linear sequences of statements. But a novel is always trying to draw you toward the end, to a conclusion. The lasting ideas it places in your mind, it does using indirect means. A computer program on the other hand creates something dynamic and non-linear.
What surprised after reading the article is how little I felt writing code, even narrative driven games, is like writing a novel.
I suppose in some ways it's quite surprising that writing code is so much different than writing a novel. They are after all linear sequences of statements. But a novel is always trying to draw you toward the end, to a conclusion. The lasting ideas it places in your mind, it does using indirect means. A computer program on the other hand creates something dynamic and non-linear.
What surprised after reading the article is how little I felt writing code, even narrative driven games, is like writing a novel.
I think that's what struck me most about this, that it felt forced, and also written by someone that doesn't quite understand exactly what programming actually is and is not. Writing a novel? No. I'd say it's much more like building a bridge than writing a novel. We use small machines to build a bigger structure that serves a purpose. That's why I accused the author of not knowing much about programming (indeed, he is a self-described "product guy"). Otherwise he'd be much more likely to draw parallels with building bridges or some other kind of engineering than writing a novel or authoring some other literary product.
Software architecture is like city planning: http://www.windley.com/archives/2003/09/enterprise_arch_4.sh...
Software development is not like manufacturing: http://www.codinghorror.com/blog/2006/10/is-software-develop...
Software development is like manufacturing: http://www.amazon.com/exec/obidos/ASIN/0321150783/codihorr-2...
I believe that software development can be disciplined (development of missile control systems, payroll systems) or be agile (instagram, pinterest, facebook...). I think it all depends on what is considered to be the most valued resource for the organization and the software it is planning to build/compose/manufacture/make.
If we value system resources (real time constraints, compliance, SLA), we tend to be more like building systems. If we value end users experience in the final outcome, it tends be agile and take the notion of the movie/novel et al.