Don't Code Too Soon

Coding software is analogous to constructing a building. Both require much preliminary work. Constructing a building without a solid and stable foundation will not work. Coding without a solid and stable foundation of requirements and design will not work. Think about how much more difficult it is to modify a building after the foundation is poured!
    Don't be coerced into coding prematurely because management wants to see "progress." Be sure the requirements and design are correct and appropriate before baselining them and certainly before coding the final product. Incidentally, don't conclude from this principle that prototyping is bad. There is nothing wrong with experimenting with coding long before requirements are baselined. Just don't consider it the final product. Manny Lehman adds a counterpoint to this principle: Don't code too late!


Reference:
Berzins, V., and Luqi, Software Engineering with Abstractions, Reading, MA: Addison-Wesley, 1991.

Format Your Programs

The understandability of a program is greatly enhanced by using standard indentation protocols. Which protocol you choose to follow matters little, but, once you select it, use it consistently.

The only thing worse than inconsistent indentations is incorrect indentation (such as, aligning an ELSE with the wrong IF)! To prevent accidental misalignments, use a pretty printer.


Reference:
McConnell, S., Code Complete, Redmond, WA: Microsoft Press, 1993.

Harry Potter and the Order of the Phoenix

Harry Potter and the Order of the Phoenix by J.K. Rowling
My rating: 5 of 5 stars

Harry Potter and the Order of the Phoenix assaulted my emotions more than any of the previous books. There were plenty of unfair issues to feel sympathy for in the earlier books but emotions are more quickly evoked in this book. I do hope that Harry is able to better control his anger in the next book. And Snape is such a sad example of what happens to a person when they can't let go of past grievances. Seriously, a study of Snape should be a required course so people can think about would sort of sad sack they might turn into if they hang onto anger and hate. I am thoroughly enjoying the different characters in this series.

View all my reviews

Language Knowledge Is Not So Important

Good programmers are good regardless of the language used. Poor programmers are poor regardless of the language used. Nobody is a "great Java programmer" and a "poor Python programmer." If they really are poor at Python, they probably were not great at Java! In addition, a really good programmer should be able to learn any new language easily. This is because a really good programmer understands and appreciates the concepts of quality programming, not just the syntactic and semantic idiosyncrasies of some programming language.

So the primary driver of language selection for a project should be appropriateness, not the surge of programmers who whine, "But all we know is Ruby." If some quit because the project selected a different language, the project is probably better off!


Reference:
Boehm, B., Software Engineering Economics, Englewood Cliffs, NJ: Prentice Hall, 1981.

https://www.youtube.com/watch?v=fkY7W6kCRY4

Programming Language Is Not An Excuse

Some projects are forced to use a less-than-ideal programming language. This might be caused by a desire to reduce maintenance costs ("All our maintainers know RPG"), to program fast ("It is so easy to get a fully featured application with Python"), to ensure high reliability ("Ada programs are the most fail-safe"), or to achieve high execution speed ("Our applications are time-critical, we need to use C"). It is possible to write quality programs in any language. In fact, if you are a good programmer, you should be a good programmer in any language; a less-than-ideal language might make you work harder, though.


Reference:
Yourdon, E., How to Manage Structured Programming, New York: Yourdon, Inc., 1976.

Harry Potter and the Goblet of Fire

Harry Potter and the Goblet of Fire by J.K. Rowling
My rating: 5 of 5 stars

Wow! I can see why people raved about the Harry Potter series. There is so much good stuff in here and not just fun adventure but difficult topics like prejudice and death.

View all my reviews

Use Appropriate Languages

Programming languages vary greatly in their ability to help you do your job. Your specific project or product goals will often dictate the appropriate language. The following guidelines are meant to be just that - guidelines, not gospel.

If your number one goal is portability, then use a language that has been demonstrated to be highly portable. If your number one goal is fast development, the use a language that aids in such fast development. If your primary goal is low maintenance, then use a language with many built-in, quality-inducing features. If your application requires a great use of character strings or complex data structures, select a language that supports them. If your product must be maintained by a group of existing maintainers who know language X, then use language X. Finally, if your customer says to use language Y then use language Y or you won't be in business long.

Reference:
McConnell, S., Code Complete, Redmond, WA: Microsoft Press, 1993.

Evita anidar demasiado profundo

El anidamiento de las instrucciones IF-THEN-ELSE simplifica enormemente la lógica de programación. Por otro lado, anidarlos más que, por ejemplo, tres niveles de profundidad reduce en gran medida su capacidad de comprensión. La mente humana es capaz de recordar solo una cierta cantidad de lógica antes de que se confunda. Se puede utilizar una variedad de técnicas simples para reducir el anidamiento.

Don't Nest Too Deep

Nesting IF-THEN-ELSE statements greatly simplifies programming logic. On the other hand, nesting them more than, say, three levels deep decreases their understandability considerably. The human mind is capable of remembering only a certain amount of logic before it becomes confused. A variety of simple techniques can be used to reduce nesting.


Reference:
McConnell, S., Code Complete, Redmond, WA: Microsoft Press, 1993.

Structured Code Is Not Necessarily Good Code

The original definition of structured programming presented by Edsger Dijkstra was provided to facilitate program proving. The constructs he recommended (IF-THEN-ELSE, DO-WHILE, etc) have now become so commonplace (though program proving has not) that their use is now called "programming" rather than "structured programming." It is important to note; however, that not all "structured" programs are good. One can write incredibly obscure programs that are still structured. Structure is almost a necessary, but far from a sufficient, condition for quality programming.


Reference:
Yourdon, E., How to Manage Structured Programming, New York: Yourdon, Inc., 1976.