The typical software developer is used to start working in its projects with just the idea, but this is not usually the best way to do this.
Let us think you decided to design your software, you created really great diagrams, and they look really… interesting:
But then another person joins your team, and there is a problem, that person doesn’t understand whatever you designed. Both of you can decide a new format for the new design, something both of you can understand. But what would happen if the team continues growing, or simply you need to work with people from other places? Designing becomes a complete mess.
Some years back, the developers struggled with this kind of problem, and to solve this, a group of developers joins forces to create an easy to use and learn design standard.
This standard was called UML, Unified Modeling Language:
This is the all-powerful, general-purpose modeling language for the software design!
But after solving the problem of standardizing the “how to design,” there is always the question in all programmers if we really need to design, the UML website says that:
Models help us by letting us work at a higher level of abstraction. A model may do this by hiding or masking details, bringing out the big picture, or by focusing on different aspects of the prototype.
So basically, it is important to design, it can help us throughout the whole project lifecycle, but at the end of the day is up to us (the developers) to decide if we really want to do it.
A lot of programmers (including myself) decide to design after the creation of the software, just as documentation, but when you design from the beginning, you answer many questions in an early stage, so when you need to program, it is a lot easier.
Also, because of being a standard, you can have the certainty that it is always evolving to give the necessary tools to the continuing changing technologies in the software world. For example, right now, we are using the UML version 2.
I’m going to continue to talk about UML in the next blog post.
4 thoughts on “Design before doing”