comments, corrections and clarifications - Andy Hunt and Dave Thomas are the Pragmatic Programmers, recognized internationally as experts in the development of high-quality software.

Software creation analogies
This summarizes the difference between academia and industry.
- writing
- building
- assembling
- gardening
- constructing
The analogy that software creation is more like gardening then engineering has been around for a while. In short: “In engineering, the final product is defined up front. In software the final product is rarely known up front, and even rarer does it end up like the initial plans call for. It is simply not possible or even desirable in software most projects.

In SE-Radio Episode 149: Difference between Software Engineering and Computer Science with Chuck Connell, the most insightful perspective was that historically we put too much loosely related things into the same bucket:

Computer Science vs. Software Engineering
- Algorithms, Cryptography, Compilers vs. Business Applications, Consumer Applications
- Complexity Analysis, Correctness Proofs vs. Maintainability, Testability
- Formal Specifications vs. Estimation
- Language Syntax/Semantics vs. Design Patterns


Bill Venners: What is the alternative to stratification of job roles?
Dave Thomas: I don't think you can get rid of the layers. I think politically that would be a mistake. The reality is that many people feel comfortable doing things at a certain level. What you can do, however, is stop making the levels an absolute. A designer throws a design over the partition to a set of coders, who scramble for them like they are pieces of bread and they are starving, and they start coding them up. The problem is this entrenched idea that designers and coders are two separate camps. Designers and coders are really just ends of the spectrum, and everybody has elements of both. Similarly with quality assurance (QA). Nobody is just a tester.
What we should be doing is creating an environment in which people get to use all their skills. Maybe as time goes on, people move through the skill set. So today, you're 80% coder 20% designer. On the next project, you're 70% coder and 30% designer. You're moving up a little bit each time, rather than suddenly discovering a letter on your desk that says, "Today you are a designer."

--------------------------------------------------------------------
Avoiding Silo mentality Compartmentalized behaviour and lack of big-picture vision
--------------------------------------------------------------------
The distinction between architecture, design, implementation, and quality assurance is rooted historically in a separation between:
- business analyst
- project manager
- architect,
- designer, and
- coder
- QA tester
These distinctions are not useful or not applicable to Agile methodology or even more to Extreme Programming.
I believe in cohesive cross-functional teams and experts with "multiple hats", rather than compartmentalizing projects and people into particular disciplines.
Looking at it all from the viewpoint of gardening or craftsmanship. There is rather an integrated view of doing things, whereartifacts are typically created by a single individual, working from top to bottom.

On the other hand, in the corporate silo mentality, often, there is no big picture supervision, there is a lack of organic coordination, teams do not share information. I think, it is good to have holistic and big-picture view of the whole, and it should be an important strategic priority.
--------------------------------
The Mythical Man Month
--------------------------------
The Mythical Man Month made popular the analogy: ”It takes 9 months to make a baby, no matter what, you can’t use 9 people to make a baby in a month. Software is the same thing, you can’t always throw developers at a project to complete a project sooner, it takes time.”

----------------------------------
Software gardening
----------------------------------
Rather than construction, software is more like gardening – it is more organic than stone or concrete.
As I started thinking about this and realized they were right. Software is organic. But the authors also didn’t carry this concept far enough. Gardening can be applied to many other areas of development, not just refactoring.
You know what else takes time? Gardens! You can’t make a ROSE in a month. It needs time, needs sun, needs fertilizer, needs water, needs pruning, needs picking, needs time and patience..

In the book "Object Oriented Software Guided by Tests", in the forward, Kent Beck writes:
>>
What if software wasn’t “made”, like we make a paper airplane – finish folding it and fly it away? What if, instead, we treated software more like a valuable, productive plant, to be nurtured, pruned, harvested, fertilized, and watered? Traditional farmers know how to keep plants productive for decades or even centuries. How would software development be different if we treated our programs the same way?
<<