You’ve probably been there too. At the beginning of a project, everybody has lots of good intentions — call them “new project’s resolutions.” Quite often, many of these resolutions are written down in documents. The ones about code end up in the project’s coding standard. During the kick-off meeting, the lead developer goes through the document and, in the best case, everybody agrees that they will try to follow them. Once the project gets underway, though, these good intentions are abandoned, one at a time. When the project is finally delivered the code looks like a mess, and nobody seems to know how it came to be this way.
When did things go wrong? Probably already at the kick-off meeting. Some of the project members didn’t pay attention. Others didn’t understand the point. Worse, some disagreed and were already planning their coding standard rebellion. Finally, some got the point and agreed but, when the pressure in the project got too high, they had to let something go. Well-formatted code doesn’t earn you points with a customer that wants more functionality. Furthermore, following a coding standard can be quite a boring task if it isn’t automated. Just try to indent a messy class by hand to find out for yourself. Continue reading
We all tend to assume that other people think like us. But they don’t. Psychologists call this the false consensus bias. When people think or act differently to us, we’re quite likely to label them (subconsciously) as defective in some way.
This bias explains why programmers have such a hard time putting themselves in the users’ position. Users don’t think like programmers. For a start, they spend much less time using computers. They neither know nor care how a computer works. This means they can’t draw on any of the battery of problem-solving techniques so familiar to programmers. They don’t recognize the patterns and cues programmers use to work with, through, and around an interface. Continue reading
Functional programming has recently enjoyed renewed interest from the mainstream programming community. Part of the reason is because emergent properties of the functional paradigm are well positioned to address the challenges posed by our industry’s shift toward multi-core. However, while that is certainly an important application, it is not the reason this piece admonishes you to know thyfunctional programming.
Mastery of the functional programming paradigm can greatly improve the quality of the code you write in other contexts. If you deeply understand and apply the functional paradigm, your designs will exhibit a much higher degree of referential transparency.
Referential transparency is a very desirable property: It implies that functions consistently yield the same results given the same input, irrespective of where and when they are invoked. That is, function evaluation depends less — ideally, not at all — on the side effects of mutable state.
A leading cause of defects in imperative code is attributable to mutable variables. Everyone reading this will have investigated why some value is not as expected in a particular situation. Visibility semantics can help to mitigate these insidious defects, or at least to drastically narrow down their location, but their true culprit may in fact be the providence of designs that employ inordinate mutability. Continue reading
No matter how comfortable a schedule looks at the beginning of an iteration, you can’t avoid being under pressure some of the time. If you find yourself having to choose between “doing it right” and “doing it quick” it is often appealing to “do it quick” on the understanding that you’ll come back and fix it later. When you make this promise to yourself, your team, and your customer, you mean it. But all too often the next iteration brings new problems and you become focused on them. This sort of deferred work is known as technical debt and it is not your friend. Specifically, Martin Fowler calls this deliberate technical debt in his taxonomy of technical debt, which should not be confused with inadvertent technical debt. Continue reading
Classes are designed to group variables and operations together in coherent modules. Classes have fields, constructors and methods among other attributes. Objects are nothing more than specific instances of a class. This is Object Oriented Programming in a nutshell.
The best way to think about classes and objects is to think about cars. The Car Class contains all possible cars within it. All cars share certain attributes such as having four wheels, an engine, a transmission, seat belts, a steering wheel, etc. When you create an object, it is a specific instance of a car. By default, this object takes on all of the attributes of the Car Class and it can also have its own attributes specific to that particular instance. This is known as inheritance.
If you don’t understand all of it just yet, don’t worry – it will come to you. The point is simply that object oriented programming allows you to inherit certain attributes of a class without having to write that individual code every time you want to use it in your program. In other words, you don’t have to tell your program that a Car object has wheels, a steering wheel, an engine, a transmission, etc. because the program already knows these things because of the attributes defined within the Car Class. Continue reading