Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

When I want to develop a new application, first I'm going to design a UML and specify project details and definition. But when I start development process, I determine that I should change some parts of my idea in order to become more popular software or easier logical steps for my users or simpler process or anything else.

Then, I change my code, redesign some parts of my UML and start/continue development process one time again and sure that this time I have a perfect project definition and UML, but after a while ( this time takes longer ) i determine again I should change something again ! So I get back and change my UML( sometimes not ! just continue the project without changing UML ) and so on. This process will happen over and over until I become tired or find (almost) the best state of the project or have time limitation problem!

So my question is:

  • 'Can I design a perfect UML at the beginning of my project so that describe the best state ever !?'


    - 'Should I swear in God never ever change my UML ( and project definition ) even if there is a better one and write current state to the end!'

Another question "Is changing some parts of a new idea, even if analyzed with hands of the best analyzer in the world, is inevitable ?( in order to find the best state )". I mean we can't fully simulate user experience, can we? We should see it in action.

share|improve this question

7 Answers 7

up vote 1 down vote accepted

I think the approach is wrong. The goal is not an exercise in discipline (following a design no matter what), or to see if you can dream up something perfect the first time. The goal is to create something that is useful, and that can hopefully make some money.

The main point is to define your goal properly. There are many businesses that have gone out of business because they didn't define their business properly. For example steamship companies that defined themselves as "steamship" companies, not "transportation" companies.

Don't stay so focused on blindly sticking to something articifially. Adapt, innovate.

Changing your mind, changing course, adapting, all the great thinkers and doers of the world have had no compunctions about changing their minds and altering their course (Lincolm, Ghandi, Malcom X, etc. etc.!)

share|improve this answer

It is almost always impossibe to design a UML for any non-trivial project that will correctly map the end product. Why would you even want to treat your UML with higher regard than the project itself. Specs always change, so your project should to. A UML, if you have one at all, should be a living document that changes with the needs of the project. This is why many find them unneccessary, since they are not much more than redundant descriptions of the project structure that must be maintained continually.

share|improve this answer
+1 thanks. so, UML is unnecessary at all for new ideas ? What alternative do you suggest ? –  Michel Kogan May 27 '11 at 22:37
Behavior-driven development is a good alternative as you get the benefits of defining "executable" specs to drive the new development. Be sure to also include the inner loop of Unit tests to allow refactoring and change as alluded in Jason Lewis' answer. –  Turnkey May 27 '11 at 22:53
I will still use UML for new components, but just as a very rough map of how things will fit together. –  Morgan Herlocker May 27 '11 at 23:58
UML is not just class diagrams. There are, at the moment, 14 different types of UML diagrams, including use case, activity, and timing diagrams. Many of these are, in fact, quite necessary for serious projects, you don't necessarily have to use UML specifically, but the basic concepts are always the same regardless of the particular design language. –  Aaronaught May 28 '11 at 2:02

Answering the second question separately:

Not only it is fine to be doing reworking of a new idea before it gets to the implementation, it is also to be expected for the system which is completed (sort of) and put into production.

There no such thing as finished software really. Any living software project (web or desktop) is a constant work in progress. You plan for the next version while developing the current one, you listen to the users' feedback and adapt things accordingly, you watch the market and competitors and react to them, always, wherever it is needed. That is the only way to turn your software into something users really want. If you don't your users will be pissed and leave. Competitors are always there to pick up where you dropped it as well.

share|improve this answer
great answer. thanks –  Michel Kogan May 27 '11 at 22:29

I agree with @Developer Art. UML is rarely if ever used in modern development shops. The best way I've found to spec a project is a solid test suite. If you're not familiar with Test-Driven Development, in this methodology, your tests are the Source of All Truth in your project. You first write tests that describe the "code you wish you had", to meet your specification. Then you write the code that makes those tests pass. Then you refactor.

UML is wishful thinking. Unit tests are proof. As long as the tests meet the specs, you just have to make the tests pass. If the requirements change, you change the tests, and refactor your code until they pass the new requirements. It's not a panacea, but it's a MUCH better way of doing things than reproducing the logic of some UML diagram constructed in a Platonic ideal of software development.

share|improve this answer
Unfortunately unit tests are not proof either. Only integration testing with real components will give you the ultimate answer to the question if this thing really works. –  user8685 May 27 '11 at 22:20
You're right, I should have been more thorough. Unit tests are the first step. Proof is having 100% coverage with unit, integration, and functional tests. For extra credit, performance tests are a Good Thing too. –  Jason Lewis May 27 '11 at 22:25

I think that there is nothing wrong with modifying a program design as you develop it. As the time passes you develop a better understanding of the problem at hand, plus you may realize that some approach to the user interface can be improved. Programs are like living organisms and the change through their entire life cycle. You can always find better solutions to the problems. Your task is to judge weather they are worth applying or not.

share|improve this answer

The relevant concept is "evolutionary design", and it's a key element of Agile development. The idea is that you know the absolute least about a system when you start the project, so why lock in all of your false assumptions at the beginning?

What you need is some kind of process that allows you to encourage change, and the incorporation of new knowledge into your design as you proceed through the development. Another thing you want to do is to hold off all decision making to the last possible moment, when you have the most information.

You might find that an iterative approach works best. Build some of the system, stop, and take a look at what you've built and what you've learned about the system. Think about how your design should change to be better and how you'll do it. Build some more and repeat.

share|improve this answer

Many people have found a different solution to this problem. They dropped UML. Many years ago.

As of today it is used in two scenarios:

  • A tool in academia

  • A way to describe some architecture elements of very stable projects

It is by no means a prototyping tool.

Use instead mind mapping techniques, plain textual description of the key moments as well as anything else you find useful and working for you. Another thing to consider is that modeling is not really that essential. In fact, you will find that you can do only one of the two - you either spent most of your time modeling or you do the actual work of development. People with academic inclination like modeling, practitioners keep it to a minimum (but not necessarily avoiding it entirely).

share|improve this answer
I disagree. UML is a great prototyping tool when used properly. You can learn a lot about how classes and objects interact through the proper use of various diagrams. –  Thomas Owens May 27 '11 at 21:59
@Thomas Owens: Theoretically perhaps. I have never experienced that in practice however. –  user8685 May 27 '11 at 22:00
what alternative do you suggest for UML ? –  Michel Kogan May 27 '11 at 22:38

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.