In Part 1 we established the idea of the higher-order code smell: how small units of disorder combine to make surprising new problems (and complex odors). Little deferrals of (extra) effort aggregate into more trouble than the sum of their weights. Check it out here to see the first example, the N-dimensional Object — a monster of too many purposes.
Here in Part 2 we’re looking at another — and this one likes to hide until you’re making large, difficult changes. The very moment you least want surprises.
Start by visualizing your application architecture as a set of walkways, sending…
Code smells are a well established idea.
The “smell” part is perfectly descriptive: like opening the fridge after a weekend away. You know when something is off.
There are popular tools to help detect them (Checkstyle, SonarQube, etc). There are research papers giving them a taxonomy, and to measure their relative costs. As a thought exercise, it’s fun to name them and give classifications (and ponder which are the worst), but I’m most interested in how they appear in the wild.
And in the wild, code smells appear in groups. Disorganization spreads disorganization, chaos begets chaos. And different code smells…
With a language this fun to write, is there some cost that must be paid? Will I only realize it when it’s too late?
It’s good to have heuristics for the relatively costly operations in any given language, and to back them up with measurements. Below, we’ll take a look at some samples and the context of execution that makes them interesting. If you’re writing Kotlin and have a concern for performance in some regime, your expectations may be inverted.
I’d like to propose a distinction between a shortcut and a hack.
A shortcut is a compromise that gains immediate partial functionality by deferring a costly (but “correct”) choice until the shortcut can…
Businesses plan budgets and manage deliveries. Any project must have a projected cost and timeline. Is software somehow exempt?
How Much Will It Cost and When Will It Be Done?
Similar to asking “What is north of the North Pole?”, you can expect nonsense for an answer. As a developer, I see this mistake repeated routinely. Your software is not a vehicle to transport your product. It is your product. Creating useful products is a process of discovery and adaptation. Misapplying bad questions to a software project will prevent you from capitalizing on those discoveries while you waste time and…
Inconsistency is a trickster demon, injecting doubt and confusion where there should be none.
Unlike spaghetti code, inconsistent code can sometimes defend itself in code review. There can be multiple good ways to solve a problem, and each approach in isolation may withstand scrutiny. Side by side, however, their differences appear as patchwork and boobytraps. A spineless code reviewer won’t insist on conformity, and a hapless maintainer will never be able to edit with confidence.
Done correctly, your inconsistent code will force a deep-reading of each mismatching implementation, and always prompt the question:
Why is this different?!
Best of all…
But who can blame you when the Google Samples do too?
As the Android ecosystem has grown, Google finally got around to having an opinion on application architecture and provided some useful components for the everyday developer. These components (like LiveData and ViewModel) often get categorized under
Model-View-ViewModel: a broad architecture pattern that addresses some problems with another community favorite pattern,
Model-View-Presenter. However, importing
ViewModel into your project doesn’t mean you’ll actualize their benefits — you have to follow through with the implementation they enable.
In this article, we’ll take a close look at a common mistake developers…
So you’d like to respond programmatically to changes in the spacial orientation of a mobile device. Perhaps you’re writing a feature that directs the user towards a nearby location, or you’d just like to add some surprise and delight parallax to your loading screen.
What is the cost of a bad API? Try multiplying all of your tech debt by your number of users.
In a team environment, the pain of a bad internal API presents itself readily: frustrated developers and delayed delivery. In a public API, the costs are spread across many teams and thereby vastly overpaid. And despite being more costly in total, a bad public API can resist needed improvements. The maintainers may not feel sharp feedback immediately, and downstream developers may have no choice (an org-level mandate) or alternatives (a monopoly).
If you write code, you write APIs. You should…
One of the benefits of separating state from your decision-making code is that the decisions become reproducible.
You don’t want your decision-making functions to change their moment-to-moment behavior based on a history of events preceding them. That increases branching and multiplies the possible causes of misbehavior. Was a bug caused by bad state, bad logic, or a combination of the two?
If you’re not paying attention, it’s easy to let state creep into your view models and pollute your logic.
Consider an example.
Imagine an app with a simple file download feature.