Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
How do you prevent agile methodology with monthly sprints/iterations causing a fragmented design. For ex. take the case of design of Manhattan Streets vs Design of Boston streets. The blueprints for Manhattan Streets were designed as a whole resulting in easy manoeverability and driving. Boston streets were designed in a piece meal approach and its a nightmare getting around.
Streets are a bad analogy to use for software. Streets cannot be easily moved, rerouted, or changed without significant effort. Well-written software is an composition of orthogonal components that are easily reorganized and modified as needed.
The reason that agile development works is that both the developers and the software itself are agile. The developers respond quickly to change and the software they write is written in a manner that makes it responsive to change as well.
Refactor, refactor, refactor.
Agile development is not a mandate to throw away over-arching design. It makes a lot of sense to plan 'the big picture' - what the responsibilities of your major components are, and how they will interact, for example. In my own team, I find a reasonable compromise is to agree a broad public API up front, but defer detailed implementation decisions where possible. This allows individual developers the freedom to modify the design as the implementation evolves, while also gaining the benefit of hashing out different approaches at the design level, when changes are much cheaper. Modularity is also key - keep components specific in function and as decoupled from one another as possible. This minimises your overheads when you find you need to make changes to your implementation, and should increase the chances that individual components you write remain useful.
You can have a design phase that decides on the Streets. What buildings get built is determined in each phase.
I think that there is a tendency to do too little design/architecture in scrum projects. You can do constant refactoring but that can be alot of work, if something has not been designed. You can get into the same problem if there is an error in the design.
Use of SOLID principles would result in code which is loosely coupled & highly cohesive.
Remember design is the king.
IMHO analogies of software components with Buildings, Streets are just illogical. None of this is even remotely similar to software development or software design.
There is always a risk that Agile users will suggest adjusting the principals of agile to the situation at hand, however when this subsequently fails this leaves those who support the move to Agile open to criticism because Agile is not being adopted fully.
Fragmented design is a continuous risk with Agile because there is no value on architecture. What is needed is a methodology that uses the advantageous aspects of Agile such as Continuous Delivery but solves problems like the un-scalability of Agile. A possible approach is The Game of Thrones Methodology which does just this.
"Agile methodology" (and I assume you mean SCRUM, here) has little to do with the architecture of your design; the architecture being a property of the software or the system your creating (in the UML world you would maybe call it "artefacts").
"Agile" does not tell you anything about what kind of software you write, it can be used for any and all types of software or even easily for projects that have nothing to do with software at all.
So if you have the feeling that there is a bad software architecture in your agile project(s), then you should be looking around at what the actual cause is. Only because you are agile does not mean that everybody does what he wants without a plan, or that you need no documentation at all. While you won't specifiy every class down to the bit level before starting your work, you still will want a high-level architecture written down, even before the first sprint. Depending on your team size and constituency, you could imagine using your first sprint to even create your architecture.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I'm basically familiar with Agile methodology and Scrum.
But what is "Lean Software Development" and "Kanban"?
Is it safe to say that Scrum, Lean and Kanban are implementations of Agile methodology? Or are Lean and Kanban different methodologies?
Do Lean and Kanban provide a skeleton/guideline (like Agile) and leave the implementation to an adjacent set of practices, like XP and Scrum?
Actually, neither Agile nor Lean have a precise definition. Both cases are rather about a set of principles and practices – in the former case, basing on Agile Manifesto, whilst the latter is based on the Toyota Production System adapted to software/IT industry.
I would say that both Lean and Agile are two flavours of the same movement in the software industry – focusing on effective delivery of products which customers actually need (this is a vast generalization though). The difference lies in the ways this goal is achieved.
With Agile, the focus is placed on establishing a well-organized process, which allows frequent delivery and enables easy adjustments to the customers` needs during the course of development. Lean focuses more on limiting "waste" (including work in progress which is considered as one of types of waste) and making the production and delivery workflow as efficient as possible.
It is often that agile and lean approaches are put into the same bucket, so you will find all sorts of mixing – Scrum + Kanban is the most significant example; refer to Scrumban for more information. Unless you talk with an orthodox it shouldn't be a problem if you label Kanban as an Agile method.
To make some order in labels: Agile and Lean are general concepts. Scrum and XP are specific implementations of Agile, while Lean Software Development and Kanban are specific implementations of Lean.
At least this is how people usually perceive them. It is definitely possible to mix different approaches, or single practices thereof, into one method. Scrum+XP or Scrum+Kanban are probably the most popular combinations.
If you want to dig deeper, I can recommend a great mini-book which compares Kanban to Scrum: "Kanban and Scrum – Making the most of both". The eBook in PDF form can be downloaded for free.
Agile expert Mary Poppendieck wrote about the principles of Lean. Find her credentials here.
Instead of me writing a lot about Kanban, please read what Swedish advisors Crisp say about it.
The practices of Lean are quite different from the hands-on, practical tasks that programming-centric XP asks you to do in your project ("Automate everything", "Have tests", "Meet daily"). Value-stream analysis could give you some new insights and conceptual tools with which to reason about business and tasks to do.
Hope this helps navigating the process-speak. Best of luck!
At the risk of irritating purists, and from a practical perspective, Lean is the highest level of abstraction whose principles and (most) practices can be applied across the entire enterprise. Your CEO will understand and buy-in to Lean. In my experience, linking Agile at the tactical level to Lean at the enterprise level makes for a much easier sell to executives.
Kanban in manufacturing is an inventory queue management technique. As applied in knowledge work (not just IT) it is a workflow visualization and queue restriction technique designed to focus teams on the smallest batch of work possible at a time to speed flow. It can be as simple as sticky notes on a whiteboard with tape lines marking off process step left to right. Or there are electronic Kanban tools available (standalone or add-ons to all of the main ALM tools)
Kanban can be easily applied as a tool for Scrum teams simply by treating the kanban board as representing your iteration. You (try to) only allow work onto the board at the beginning of the iteration and it needs to be in the done lane by the end of the iteration. And, using horizontal swimlanes, you can effectively segment the board into sections for planned work in the iteration and the (sadly inevitable) operations support work that interrupts even the most disciplined teams. This make it very clear what work was committed and what snuck into the sprint.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I am a long time agile advocated but one of the things that bothers me about Agile is that a lot of agile practitioners, especially the younger ones, have thrown out or are missing a whole lot of good (non Scrum, non XP) practices. Alistair Cockburn's style of writing Use Cases springs to mind; orthogonal arrays (pairwise testing) is another.
I read mostly Agile related books and articles and work with mostly Agile folk ... is there anything I'm missing?
It might be interesting in 5-10 years time to see how maintainable these systems are when nobody wrote down why a particular decision was made and all the people involved have left.
is there anything I'm missing?
Yes, I think a lot, but only if you are interested in Softawre Development Processes.
I like this paraphrase:
Each project should be as agile as possible but not more agile.
Not every project can be agile... but I think 80%+ can.
I see Agile as "car of the year". It is very well suited for most of the people, but if you need/want something special, for example car able to speed 300KM/H or car able to carry 20 tons of goods you need something else.
There is also so many cases when one may want something else than "car of the year" that requires a book to write them down :-) I recommend you Agility and Discipline Made Easy: Practices from OpenUP and RUP. In this book you'll find many "missing parts" very well illustrated. The key to understanding is that Agility is only a (requested) property of software development process which sometimes cannot be achieved. The book describes several Key Development Principles (which are basis for RUP) and explains which level of "ceremony" and "iterativeness" follows from using them on different levels of adoption.
An example
Practice: Automate change management and change propagation
In your project you may require very advanced and strict change management and decide to "Automate change management and change propagation" by implementing custom or re-configuring existing tools and by using Change and Control Board.
Effect: This most probably increase level of "ceremony" in your project.
(...) have thrown out or are missing a whole lot of good (non Scrum, non XP) practices.
Scrum is not prescriptive, it's up to you to choose how to do things. In other words, nothing forces you to use User Stories for example (even if User Stories work for lots of teams, there is no consensus) so feel free to use (light) use-cases if you think they are more appropriate in your context. To illustrate this, Jeff Sutherland reported he would never use User Stories again for PDA device projects (they use some kind of "light specifications" in his current company). And the same applies for testing, use whatever works for you. To summarize, if you find XP not flexible enough, use something else... and inspect and adapt.
Iterative development.
In practice, agile teams may do iterations (or anything for that matter, agile is a kind of "true scotsman"), but agile processes don't require or define iterative development sufficiently.
Take RUP, for example - clumsy and bloated, it does compile a few good methods for long-term development that agile misses.
On a general note, agile is a way to steer clear of problems: how to avoid long term planning, how to keep teams small, tasks short, customers involved, etc. It works more often than not, but sometimes you have to face and solve problems: how to reach strict deadline, make big team work, achieve distant and complex goals, make customer refine requirements. That's when one needs to look beyond agile.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
Looking for work at the moment, I'm seeing a lot of places asking for Agile experience, but until I get a job with a team that is using Agile, I suspect I'll never get the experience.
Is it possible to adopt Agile methodologies with just one person?
Sort of answering my own question, there's similar questions at :-
https://stackoverflow.com/questions/1407189/can-agile-scrum-be-used-by-1-or-2-developers
(I guess I should get better at searching.)
You seem to be coming at this from a work experience point of view; if you are looking to build relevant experience to get you a job on an agile project I would probably think a little more laterally.
Firstly could you work with others, maybe on an open source project? That would be a good opportunity to try out agile methods with others who may have more experience.
Secondly, you could look at using some of the common techniques or tools, even if it's just to learn how the tools work - e.g. you could set up a continues integration server to run builds and unit tests when you check in code. If you are working on your own you won't gain much in terms of productivity by doing this but you would gain some skills and have something relevant to say to future employers which would indicate you are committed to the agile style.
Yes
Check out PXP or Personal Extreme Programming.
http://portal.acm.org/citation.cfm?id=1593127
Summary from the paper:
Personal Extreme Programming (PXP) is
a software development process for a
single person team. It is based on the
values of Extreme Programming (XP)
i.e. simplicity, communication,
feedback, and courage. It works by
keeping the important aspects of XP
and refining the values so that they
can fit in a lone programmer
situation. PXP can still be refined
and improved. It is in the tradition
of XP practitioners to vary XP to
encompass whatever works. We hope
that PXP inherits these pragmatic
roots, as well. Giving up XP tenets
like pair programming is not
necessarily a tragedy. We still
believe that following XP strictly is
a more effective way to pursue
multi-person projects. But we are also
convinced that many of the XP
practices and methods can be applied
to individual work. The PXP
approach tries to balance between the
"too heavy" and the "too light"
methodologies. PXP will inject the
right amount of rigor for the
situation without overburdening the
team with unnecessary bureaucracy.
Yes - it is possible to do many agile practices as an individual.
If you already know how to do these, you can do them as a sole developer:
test-driven development - great place to start
refactoring
continuous integration
doing the simplest thing that could possibly work (and evolving it through refactoring)
automated deployment
planning meetings (a team of one plus customer)
Things you can't do on your own:
pair programming
CRC/RRC workshops (... you'd have to talk to yourself quite a lot)
Pair programming would be hard this way :)
Let's check Agile Principles:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
You can do all of those things even while working on some personal project alone. You can use also GTD while working alone, you can develop your product through iterations, you can adopt timeboxing, you can ask some family members or friends to do usability tests with you (and this works really well).
As a conclusion, you can really get tons of Agile experiences alone. I strongly recommend you to read some books first tho, as some of principles can be easily misinterpreted.
Some aspects can be done alone: running a product backlog and using a task board come to mind. See what the secretGeek is doing.
Of course some cannot: pair programming, scrums etc...
I recently interrupted a big project. It was a medical software project. While working on it, I realized some patterns about solo programming. I want to share my experiences here:
Your software's working logic must always reflect the real world. You catch fish with fishing rod, not baseball bat; so forget it.
Always start building from the project element to which all other elements refer. That makes sense if you think that like the function in a software project which is called at most. That might be database modeling. It would be useless if you model data access layer first, before modeling database.
Never mind changing variable names. That's the most written entry in a programmer's diary; so no need to be ashamed.
Methodology changes the world. Make worth of it. Make every single logical process with a function or procedure. When project gets huge you will understand thats the best way.
If you're not designing a language compiler in assembly do not hesitate using huge procedure call chains in which one calls another and that calls another and so on. Use methods everywhere, nearly resemble every single entity with classes and be modular.
Modularity is everything. Set modularity your primary goal. Have i said it is everything meanwhile?
Last word for beginning the project. If you're building an apartment you install main entrance at last. But when using, you enter the building from entrance. Be aware.
These are some of my design principles I learned and learning day by day. I hope having been useful. Do your best.
While some Agile practices are directly targeted at more than one person teams, they are just practices, they are just a mean, not an end. I mean, Agile is not about doing pair programming, stand up meetings, etc. Agile is about maximizing the customer value while minimizing waste to provide the most optimal ROI. Agile is business oriented, practices are just a way to achieve this goal in a given context. So, back to the initial question, it's definitely possible to adopt Agile practices (that make sense in your context) to maximize the delivered value: continuous planning, limiting Work In Progress, Stop-the-Line culture, time boxing, high quality, just enough specifications, just enough and just in time documentation, etc, etc.
Definately. Agile is very flexible in terms of how many people are involved. Some methodologies, like Scrum, focus mostly on doing as much as possible in a limited time, like two weeks (sprints). That includes whatever you want it to. If your team requires QA, then that is part of it. As a loner, you decide what you want to include.
After the scrum sprint, you look at what you could have done differently to get more done, and move to the next one.
Some other methodologies focus more on getting features done in each iteration, say three small features developed, tested and refactored.
As you can see, there are tons of ways to apply agile to any project. You decide which aspects you want. Though obviously one integral part is doing things in small increments.
Yes
XP/TDD scales from one to one thousand. Pair programming is optional.
YES.
Agile is more of a state of mind than just a methodology of software development like waterfall.
Scrum is one of the very popular agile methodologies. You can study below aspects of scrum in detail:
Benefits of Scrum/Agile over Waterfall
How can you create better "products" with Scrum/Agile
What are the types of projects better suited for Scrum
Pros and Cons of Scrum
Scrum Rituals and why are they necessary (What advantage do they
bring)
Different roles in scrums and their responsibilities (Scrum Master,
Product Owner and Development Team)
After you have good understanding of working of scrum and its benefits, try to create a pet project.
You will have to play all the roles yourself. You can try to distinguish between what role you are playing currently by wearing different colored hats for each role.
Example:
Product owner : Think from product perspective, what should be the features in the product and why would they be important for your users etc. Then proceed with all the scrum practices.
Scrum Master: Keep checking if you are following all scrum rituals in the right sense and spirit and are you able to derive benefits out of it.
There will be limitations,example you cannot have Daily stand-up meeting, obviously because you are the only person in the project. But if you follow above, you should be good to secure a job and play your part well in the team.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
Developers can learn a lot from other industries. As a thought exercise, is it possible to build a passenger aircraft using agile techniques?
Forgetting cost for now; how feasible is it to use iterative and incremental development for both the hardware (fuselage, wings, etc) as well as software, and still come out with a working and safe product which meets the customer’s requirements at the time of delivery?
Does it make sense to refactor a plane?
Agile in software and Agile in manufacturing are really quite different, although they share similar principals and values.
Agile in manufacturing emerged in Japan in the 1950s. Read up on W.E. Deming and the Toyota Production System to find out more. It's all about constantly improving the process whereby a product is reproduced.
Agile in software evolved in the early 1990s as a rapid development model. It's all about constantly improving the product.
You can certainly build a plane using Agile manufacturing methods, I've no doubt that some already are. Anything built in Japan definitely will be as Agile manufacturing is very well established there (it's taught in primary schools).
You couldn't build a plane using Agile software methods because you can't afford to rapidly change the product - in software changes and mistakes are cheap and reproduction is free. This isn't the case for aviation.
You could design a prototype plane using something like Agile software methods - but it would have to be standardised in order to be reproduced (a design task in itself).
How would you work using Test Driven Development? Would you automatically build and test a plane every iteration? Would you be able to make a ten minutes build? How easy is to make changes to the airplane? Even if you are really flexible in your desing the building some components need to be sent to special factories so there is not inmmediate feedback.
From de design using CAD software you need to make a mould, take the piece of fiber, put it in the plane. Etc. So here a trivial change has a non trivial cost. In Agile you can make a very little change and have it tested, built and an ready to ship in 20 minutes. If small changes are expensive then the short development cycle and refactoring won't be so usefull. Your feedback can take longer than a week so there is a strong reason for thinking in advance like in the waterfall model. And every attempt has a cost in physical materials unless you are programming. The Idea is not new. Carpenters measure twice. Programmers just first code and then test.
In summary. There may be some similarities but it will definitively be the same.
I'm going to say "kind of". In fact there's one example right now that I think is pretty close to answering this question.
Boeing is attempting to do this now with the new 787 - see following: Boeing 787 - Specification vs. Collaboration (From the 777 to the 787, the initial specifications document supposedly went from 2500 pages to 20 pages with the change in technique.) Suppliers from around the world are working independently to develop the components for this aircraft. (We'll call this the "teams".)
So, I want to say yes, but at the same time, iterations in creating the aircraft has resulted in delays of 2+ years and has resulted in stories like this one - (787 Delayed for 5th Time)
Will the airplane ever get built? Yes, of course it will. But when you look at the rubber hitting the road here, it seems like "integration test" is having one heck of a time.
Edit: At the same time, this shift in technique has resulted in building a new breed of aircraft built out of entirely new materials that will arguably be one of the most advanced in the world. This may be a direct result of the more Agile approach. Maybe that's actually the question - not a "can you?" but a "if Agile delays complex systems, does it provide a more innovative product in the payoff?"
Toyota pioneered Lean Production which Agile methodoligies followed on from. For the building of the hardware of the aircraft lean production would be the way to go and for the software an agile methodology would be the way to go.
Pick the right tools for the job.
A great book following how TPS was created and works
http://www.amazon.com/Machine-That-Changed-World-Production/dp/0060974176
http://en.wikipedia.org/wiki/Toyota_Production_System
I think in this case you are thinking too big. Agile is about breaking things down into more managable pieces and then working against that. The whole idea of Agile (XP in particular) is that you do your testing first so that you cut the number of bugs out and because plane software needs to have a very high code coverage for its testing it fits in quite neatly I think.
You aren't going to 'refactor' the mechanics of the plane but you will tweak them if they are unsafe and thats the whole iterative approach for you.
I have heard of Air Traffic Control software written with Agile Methodologies pushing it forward.
This is taken from http://requirements.seilevel.com/blog/2008/06/incose-2008-can-you-build-airplane-with.html
***Actually, that’s not true,***
My first guess - this probably relates to some of the core differences between systems and software engineering. I am going to over simplify this and just say that it is about scale. Systems projects are just a superset of software and hardware projects, integrating and deploying some combination of these. The teams of people deploying systems projects are quite large. And many of the projects discussed here are for government or regulated systems where specification and traceability is necessary. I could see how subsets of systems projects could in fact be developed using agile (pure software components), but I’m not convinced that an entire end-to-end project can. To put this in context, imagine you are building an airplane - a very commonly referenced type of systems engineering projects. Can you see this working using agile?
All skeptism aside, I do think that iterative development most certainly could work well on systems projects, and most people here would not argue that. In fact, I would love it if we could find examples of agile working on systems projects, because the number one feeling I get at systems engineering conferences is a craving for lighter processes.
I decided to do a little research outside the conference walls, and low-and-behold, I found a great article on this exact topic – “Toward Agile Systems Engineering Processes” by Dr. Richard Turner of the Systems and Software Consortium. The article is very well laid out, and I highly recommend reading it. He defines what agile is and what he believes the issue why most systems engineering projects are not agile. For example, he suggests that executives and program managers tend to believe that the teams involved have perfect knowledge about systems we are building, so we can plan them out in advance and work to a perfect execution against a perfect schedule.
Agile Can Work With Complex Systems
He talks to how to the agile concepts can work in systems projects. Here are a few examples summarized from his article:
Learning based: The traditional V-model implies a one-time trip through, implying one time to re-learn. However, perhaps the model can be re-interpreted to allow multiple iterations through it to fulfill this.
Customer focus: Typically systems engineering processes do not support multiple interactions with the customer throughout the project (just up front to gather requirements). That said, he references a study indicating the known issues with that on systems projects. Therefore, perhaps processes should be adapted to allow for this, particularly allowing for them to help prioritize requirements throughout projects.
Short iterations: Iterations are largely unheard of because the V-model is a one-time pass through the development lifecycle. That said, iterations of prototyping through testing could be done in systems engineering in many cases. The issue is in delivering something complete at the end of each iteration. He suggests that this is not as important to the customer in large deployments as is reducing risk, validating requirements, etc. This is a great point to rememember the airplane example! Could we have even a working part of an airplane after 2 weeks? What about even the software to run a subsystem on the aircraft?
Team ownership: Systems engineering is very process driven, so this one is tricky. Dr. Turner puts the idea out that perhaps allowing the systems engineers to drive it instead of the process to drive them, while more uncomfortable for management, might produce more effective results.
There is this story of an aircraft engine plant (September 1999). Their methods seem quite agile:
http://www.fastcompany.com/magazine/28/ge.html
Yes, you could do it. If you followed Agile Software Development techniques too closely however, it would be astronomically expensive, because of the varying costs of activities.
Consider the relative costs of design and build. If we include coding as part of the software design process, then design is definitely the expensive part and build is ridiculously easy and cheap. Most Agile projects would plan to release every few iterations at least. So we can work in small iterations with a continuous build process. Not so easy when you have to assemble a plane once a fortnight. Worse if you actually plan on "releasing" it. You'd probably need to get the airworthiness & safety people on to an Agile process too.
I'd truly love to see it tried.
Yes, you can use agile techniques for building complex systems, but I don't know if I'd use it for this particular system.
The problem with aircraft is the issue of safety. This means every precaution needs to be taken, from correctly identifying and interpreting the requirements to verifying and validating each and every single line of code.
Additionally, formal methods should probably be used to make sure that the system is truly safe by making sure the programming logic is sound and satisfies its conditions properly.
I'm fairly certain the answer is irrelevant. Even if you could, you would not be allowed to. There are too many safety requirements. You would not even be allowed to develop the flight software using Agile. For instance, you do not have a Software Requirements Specification (SRS) in Agile. Yet, for any avionics software onboard an airplane that can affect flight safety you will need an SRS.
Of course one can refactor a plane.
When one refactor, one modifies the source code, not the binaries. With a plane it's exactly the same thing: one modifies the blueprints, not the plane itself.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I was having a conversation last week with a coworker about architecture (real architecture, as in designing buildings). During our talk it came up that architectural blueprints give an architect, civil engineer, and contractor all the detail they need to build something. It got both of us thinking about the state of software engineering and that there is no universally adopted approach for describing the design of software.
We have UML, but I find that it is often hard to convey enough detail without the diagrams being overly complex. Are there good examples of large software that was designed out using elaborate UML diagrams?
Then again, is having a large set of software blueprints even useful? After all refactoring and rebuilding software is much cheaper than rebuilding a skyscraper. Are architectural blueprints the wrong analogy for software design? Is there a better analogy that you can think of?
I think you can't compare software architecture with real architecture. When you build a house you have to have everything planned in advance and what's more important you also can plan almost everything in advance.
Recently I read that software engineering is more similar to gardening than it is to real architecture. I think this comparison comes closer to reality: you can't know what will work out and what won't; you have to rework things that seemed good in theory but prove to be impractical and you can constantly improve your plan while your garden/software is getting more complete.
In summary: Software blueprints shouldn't have the same level of detail than blueprints for building houses because more often than not you find that you simply cannot stick to your original plan.
Architectural blueprints are a nearly-precise representation of the actual house. They are not - usually - an abstraction conforming to a model of how houses should look, they are a representation of how the house will be.
Contrast that with UML/Flowcharts/Rational Rose/Methodology-of-the-month - those are models. They abstract away implementation details, and presume that a given model(Say, OO) is how software should be, while in reality, software is always breaking those abstractions, because the models are not a good representation.
In a sense, this ties into a question of explanatory power and computability: a house blueprint is a fixed representation with a fixed expression, and a fixed input; whereas a software blueprint must account for variable input, possibly even of potentially unbounded length. Software that permits plugins or other "computing" tie-ins now has what amounts to a Turing machine operator embedded into it, which gives rise to a host of unpredictability. So the input space of software vis-a-vis a house is mathematically larger, meaning the representational techniques must be correspondingly more computationally powerful. And this is where UML et al. falls down - they are not homomorphic with real software.
I'd say that designing software is closer to Mad-Libs than blueprints
One of the arguments made in Software Factories: Assembling Applications with Patterns, Models, Frameworks, and Tools is that UML is not adequate. Even with the addition of constraints, it is still unclear. Among other things, it does not express the authors intent sufficiently that good code could be reliably generated.
UML is fine, but photographs of whiteboard diagrams drawn roughly are just as good or better in practice (in a time/cost sense of things)
So it's more like drawing a strategy in the sand before lanching an attack, that attitude seems to work better in most cases.
Besides half the time UML gets drawn by some guy with lots of imagination and no investment in the actual implementation.
For large, computationally dense, long-lived, safety-critical, software systems like DoD and FAA weapons and sensor systems, blueprints are essential to long term success. (phew, that was a mouthful :)) Without a set of blueprints for these behemoths, maintainers, and even the original developers, will experience distress and frustration when they try to locate/fix bugs or add major features. Without blueprints, incorporating changes, even small ones, will become a high risk game and failure could mean the loss of lives downstream.
Having said that, UML and it's offspring SysML, are (right now) the only game in town. Modeling and abstraction are important tools in the battle against ambiguity and complexity and they'll become more important in the future. The sooner they are embraced by people who want to grow, the better.
Thanx for listening.
I have just completed a successful C#/Sql Server project where I used a UML diagram to flesh out the application design. That UML diagram avoided any misunderstandings about what the application was designed to do and not do. All class relationships along with the class deletion rules (composite, aggregate, none) were spelled out. Along with a couple of easy to understand State diagrams and some OCL (Object Constraint Language), it was a breeze to discuss with the stakeholders how the application was supposed to work. UML and OCL abstract out a tremendous amount of mundane and low level programming that I was able to avoid. UML and OCL are simple enough that users can understand what is going on under the hood. When my users ask how calculations were arrived at, I simply refer them to the UML and OCL. What could be easier? So, yes, IMHO UML is very appropriate in making software blueprints. There is something to said about employing domain driven development.
The combination of Text + Diagrams is usually the best way to explain how your architecture works. Rational Rose can only get you so far.
I think any metaphor is only going to stretch so far. You will get value comparing some aspects of programming to building houses and also from comparing different aspects to gardening / playing chess/ reading the dictionary whilst standing on your head...
I think it is easier in building to specify what level of detail is required for a particular project as there are generally accepted practices, that have been around for some time, for managing a building project.
Maybe in 50 years time, if everyone settles on a methodology, something similar will happen in our industry.
In my experience, uml is garbage.
You can achieve much, more by using TDD and have 10000x more fun.. by jumping in and writing test cases and seeing how your objects interact.
UML designs just suck. I am a coder, not a data entry type person.
Before TDD I used random pieces of paper to sketch out the basic entities and relationships and then jumped right into coding.
I don't see these tools being used commonplace and the popularity of them is whaning.
I'd say that UML is limited. Yes, you can represent basic relationships, but you still don't get much when you think about interactions and constraints (even with OCL)
If you want to give a software team "all the detail they need to build something" then put your efforts into requirements analysis and creating a nailed-down functional specification. This will contain descriptions of every feature that the customer wants. If those descriptions include UML diagrams then all well and good - in many cases UML is a better language than English/French/German/whatever for describing software - but don't get hung up on creating UML diagrams for the sake of it. Joel on Software has a series of feature articles on how to write functional specs and they are well worth reading - start here: http://www.joelonsoftware.com/articles/fog0000000036.html.