If you can’t explain something to a six year-old, you really don’t understand it yourself en 20:25

Hi guys,
How are you? I am really fine. Sorry I haven’t written before now, but I’ve been very busy thinking in my future. It is really amazing that I am 19 years old and I am trying to think in the following 5 years of my life. Although there is nothing else to say about that because I don’t know what to do, I ‘ve decide to wait and also to continue learning the activity I love and you know what I’m talking about: Dancing. No! It was a joke! It is incredible that a lot of friends tell me that they never improve their skills in their careers in their free time but I can’t stop reading or trying something new due to my hyperactivity, curiosity and also I don’t want to be a programmer from 9 AM to 6PM.
The gap between the best software engineering practice and the average practice is very wide – perhaps wider than in any other engineering discipline. Fred Brooks

What’s new?
Two weeks ago, I met Martin Salías and he encouraged me to learn other programming language and also continue improving my programmatic skills. Last week I watched Python and the currently week I am watching Ruby. Next post more information about it. He also loaned a book called Code Complete Second Edition to me.
If you can’t explain something to a six year-old, you really don’t understand it yourself. Albert Einstein
Last quote inspire me to share you some ideas of the book!

· In common usage, construction refers to the process of building such as a house, a school or a building by construction workers. The construction process might include some aspects of planning, designing and checking you work, but mostly “construction” refers to the hands-on part of creating something.
In software development activities, construction is mostly coding and debugging but also involves elements of detailed design, unit testing, integration, testing and other activities.
· Now that we know the meaning of construction, why is software construction important?
Firstly it is the central activity in software development
Requirements and architecture are done before construction so that you can do construction effectively. System testing (in the strict sense of independent testing) is done after construction to verify that construction has been done correctly. Construction is at the center of the software-development process.

Secondly the source code is often the only accurate description of the software
In many projects, the only documentation available to programmers is the code itself. Requirements specifications and design documents can go out of date, but the source code is always up to date. Consequently, it's imperative that the source code be of the highest possible quality.
Thirdly it is the only activity that's guaranteed to be done
The ideal software project goes through careful requirements development and architectural design before construction begins and system testing after construction. However, in real world often skip requirements and design to jump into construction. They drop testing because they have too many errors to fix and they've run out of time. But no matter how rushed or poorly planned a project is, you can't drop construction.
· The power of Metaphors
Some metaphors are better than others. A good metaphor is simple, relates well to other relevant metaphors, and explains much of the experimental evidence. The book uses a lot of metaphors to explain some ideas.
But, what is a software metaphor? It is more like a heuristic than an algorithm. The last one gives you the instructions directly so you can quickly go from point A to point B and a heuristic tells you how to discover the instructions for yourself, it is a technique that helps you look for an answer, but it doesn’t give you the answer.
We use heuristic as a software metaphor because in programming science each program is conceptually unique; it is difficult or impossible to create a general set of directions that lead to a solution in every case. Thus, knowing how to approach problems in general is at least as valuable as knowing specific solutions for specific problems.
Then, the book tells a few metaphors about software development that they are really interesting. For instance, the first metaphor suggest that developing a program (“Writing code”) is like writing a letter and the last one is software accretion which means increase in size by a gradual external addition or inclusion. Accretion describes the way an oyster makes a pearl, by gradually adding small amounts of calcium carbonate. This doesn’t mean that you have to learn how to make code out of waterborne sediment; it means that you have to learn how to add to your software systems a small amount at a time. In incremental development, you first make the simplest possible version of the systemthat will run. It doesn't have to accept realistic input; it doesn't have to perform realistic manipulations on data, it doesn't have to produce realistic output—it just has to be a skeleton strong enough to hold the real system as it's developed. It might call dummy classes for each of the basic functions you have identified. This basic beginning is like the oyster's beginning a pearl with a small grain of sand. After you've formed the skeleton, little by little you lay on the muscle and skin. You change each of the dummy classes to real classes. Instead of having your program pretend to accept input, you drop in code that accepts real input. Instead of having your program pretend to produce output, you drop in code that produces real output. You add a little bit of code at a time until you have a fully working system.
· Software construction: Building software
If you're building a simple structure—a doghouse, say—you can drive to the lumber store and buy some wood and nails. By the end of the afternoon, you'll have a new house for Fido. If you forget to provide for a door or make some other mistake, it's not a big problem; you can fix it or even start over from the beginning. All you've wasted is part of an afternoon. This loose approach is appropriate for small software projects too. If you use the wrong design for 100 lines of code, you can refactor or start over completely without losing much.

If you are building a house, the building process is a more complicated, and so are the consequences of poor design. Move a wall 1 meter, is really expensive.

So you need careful planning, that it doesn’t necessarily mean exhaustive planning or over-planning. A well-planed project improves your ability to change your mind about details later.
A good architecture should fit the problem. When you look at the architecture, you should be pleased by how natural and easy the solution seems. It shouldn’t look as if the problem and the architecture have been forced together with duct tape.
The architecture should describe the motivations for all major decisions. Be wary of “We’ve always done it that way” justifications. If the work is not being done well in the first place, doing more of it will not be useful.
So much of the success or failure of the project has already been determined before construction begins. In software development, you should take into account at the moment of doing requirements. Explicit requirement keep you from guessing what the user wants and also help to avoid arguments. Without good requirements, you can have the right general problem but miss the mark on specific aspects of the problem.

The penalty for failing to define the problem is that you can waste a lot of time solving the wrong problem. This is a double penalty because you don’t solve the right problem.

If you don’t believe me that requirement are really important (and also really boring), think the following: Programmers are at the end of the software food chain. The architect consumes the requirements; the designer consumes the architecture; and the coder consumes the design.
Compare the software food chain to a real food chain. In an ecologically sound environment, seagulls eat fresh salmon. That's nourishing to them because the salmon ate fresh herring, and they in turn ate fresh water bugs. The result is a healthy food chain. In programming, if you have healthy food at each stage in the food chain, the result is healthy code written by happy programmers. So, good requirements make construction easy. Bad requirements make construction almost impossible.
In general, the principle is to find an error as close as possible to the time at which it was introduced. The longer the defect stays in the software food chain, the more damage it causes further down the chain.
As always, feedback is welcome!