Design and programming are human activities; forget that and all is lost. – Bjarne Stroustrup, 1991.
The fact that we did not have a database running for 18 months of development meant that, for 18 months, we did not have schema issues, query issues, database server issues, password issues, connection time issues, and all the other nasty issues that raise their ugly heads when you fire up a database. It also meant that all our tests ran fast, because there was no database to slow them down.
Programmers can practice in a similar fashion using a game known as ping-pong. The two partners choose a kata, or a simple problem. One programmer writes a unit test, and then the other must make it pass. Then they reverse roles.
A use case is a description of the way that an automated system is used. It specifies the input to be provided by the user, the output to be returned to the user, and the processing steps involved in producing that output. A use case describes application-specific business rules as opposed to the Critical Business Rules within the Entities.
For example, class names including weasel words like Processor or Manager or Super often hint at unfortunate aggregation of responsibilities.
Some folks think that Agile is about going fast. It’s not. It’s never been about going fast. Agile is about knowing, as early as possible, just how screwed we are.
In fact, wrapping third-party APIs is a best practice. When you wrap a third-party API, you minimize your dependencies upon it:.
Flag arguments are ugly. Passing a boolean into a function is a truly terrible practice.
The problem that Dijkstra recognized, early on, was that programming is hard, and that programmers don’t do it very well.
We are confidently commanding, in precise detail, the behaviors of a machine that could otherwise do incalculable damage. And so, programming is an act of supreme arrogance.
If you are tired or distracted, do not code.
The first value of software – behavior – is urgent but not always particularly important. The second value of software – architecture – is important but never particularly urgent.
The folks who think that code will one day disappear are like mathematicians who hope one day to discover a mathematics that does not have to be formal. They are hoping that one day we will discover a way to create machines that can do what we want rather than what we say. These machines will have to be able to understand us so well that they can translate vaguely specified needs into perfectly executing programs that precisely meet those needs. This will never happen.
This is the philosophy of YAGNI: “You aren’t going to need it.” There is wisdom in this message, since over-engineering is often much worse than under-engineering. On the other hand, when you discover that you truly do need an architectural boundary where none exists, the costs and risks can be very high to add such a boundary.
You should plan on working 60 hours per week. The first 40 are for your employer. The remaining 20 are for you. During this remaining 20 hours you should be reading, practicing, learning, and otherwise enhancing your career.
Consider, for example, the truly hideous practice of creating a variable named klass just because the name class was used for something else.
If we all checked-in our code a little cleaner than when we checked it out, the code simply could not rot.
A system that is comprehensively tested and passes all of its tests all of the time is a testable system. That’s an obvious statement, but an important one. Systems that aren’t testable aren’t verifiable. Arguably, a system that cannot be verified should never be deployed.
Say what you mean. Mean what you say.
These comments are so noisy that we learn to ignore them. As we read through code, our eyes simply skip over them. Eventually the comments begin to lie as the code around them changes.