In The Myth of Code Anyone Can Read, I introduced the idea that least common denominator code (LCDC) is not a good approach to writing software. Among other things, this approach ignores programmer specialization that happens in any team of more than two developers. Mental Caching As a project becomes larger than one person can… Read More »
In LCDC: Fundamental Knowledge, I explained how hard it is to specify a minimum level of knowledge or experience for all programmers. This minimum level would be needed to determine what is allowable for Lowest Common Denominator Code (LCDC). Anyone who has been programming for any time is probably shouting at the screen, calling me… Read More »
In The Myth of Code Anyone Can Read, I introduced the idea that least common denominator code (LCDC) is not a good approach to writing software. One reason for this problem is caused by the knowledge base of your average programmer. Different Programmers Have Different Backgrounds Programming is still a relatively new field. It’s also… Read More »
I got into a conversation recently coming out of the Houston.pm user group meeting. As usual, we wandered over numerous technical topics, but one stuck out in my mind: whether or not to use more advanced or more complicated language idioms. I’ve written about programming idioms and advanced code many times in the past (see… Read More »
One of the design ideas that came out of the early days of the agile movement was YAGNI. As I have written before, this idea is push back against the tendency of many programmers to over-engineer or over-complicate our designs. We normally use some variation of the flexibility argument to justify this tendency. In fact,… Read More »
One of the classic mistakes of software development results from thinking we know what we are doing. Entirely too many people in software start off each project believing they know enough about the project to lay out the whole design. Except in the rare circumstance that you are building an exact copy of something you… Read More »
It is written We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. —Donald Knuth Most people forget the very next thing he said: Yet we should not pass up our opportunities in that critical 3%. Many developers have lost the original meaning of premature… Read More »
In a recent blog post, I suggested that the most important result of a developer writing code is the understanding of the problem/solution. Most of the reason for suggesting this change in focus is to help people understand that throwing away code that no longer serves a purpose is a good thing, not a loss.… Read More »
Every bit of code we write is the result of trade-offs. Some seem like no-brainers: what language to use, which paradigm to use. Others are more subtle: how important is speed/maintainability/memory, fail fast or never fail, fix a bug quickly or rewrite to prevent that class of bugs. One of the big trade-offs is between… Read More »
A few years ago, I first became aware of the concept of Value Objects. Unlike most objects you might use in a design, the identity of a value object is completely unimportant. Instead, the value of the object is all that is important. This leads to a couple of interesting design decisions: Value objects tend… Read More »