Looking back on some of my recent posts on this blog, I’m a bit annoyed at myself for being too hand-wavy and not saying anything all that original.
I’d like to make an effort, at least in my next few posts, to get more concrete and challenge some of the conventions I’ve observed in the software world. I’ll start with an idea that I think is not all that radical, though it would mark a sigificant departure for most teams I’ve worked on.
How we think about priority
The way most teams prioritize work seems totally sensible on the surface. Essentially, tasks are assigned some priority ranking such as “high”, “medium” or “low”; and then the highest-ranked tasks actually get assigned to people. In a perfect world this would mean that the most important things always get done, and then when there’s a surplus of time a team can “catch up” on issues that aren’t quite as urgent. In practice I think a different reality tends to emerge.
On projects I’ve been a part of, inevitably it turns...
I bet you weren’t expecting any sane developer to make this argument!
Well, to be fair, the title of this post is somewhat intentionally provocative1. But anyway, you’re here now; so it served its purpose. And make no mistake: I am going to defend global state—just possibly not in quite the way you might be expecting.
What we mean by global state
First, some background. If you’re reading this, there’s a good chance you’re a developer so I probably don’t have to explain this; but I think there are at least two forms of global state that come to mind in software. One form is global variables–values that are accessible and can be changed, globally, anywhere, by all of the code in a project. The other is constants–values that may be accessible to potentially every part of a program, but cannot be changed.
These aren’t the only kinds of global state, though. I would argue that globality–apparently that’s actually a word2–is a continuous (as opposed to discrete or binary) property. Meaning...
I never actually worked in an environment like this, but I’ve read enough articles on The Daily WTF to have an image in my head of the old dusty, temperamental servers that companies used to have back in the 90s and early 2000s.
Those were dark days, from what I hear—when your business was victimized at the whim of an unpredictable piece of hardware. If the power went out, or the CPU overheated, or the hard drive failed, your site went down. It was as simple as that.
We live in a different era now, with PaaS and IaaS and all that cloudy good stuff. Your average tech-savvy business owner is going to know there’s no particularly good reason to run your own server anymore if you’re a small company. And if you’re one of the large companies providing these services like Amazon or Google, you have been on top of the hardware problem for a long time, with data centers distributed around the country (or the world) connected in a controllable and reliable way. It’s not an issue...
A few years ago my parents gave me and my wife this knife as a Christmas present:
We weren’t quite sure what to make of it at first, but it wasn’t long before we both loved it. It is a very sharp knife, which makes it a breeze to cut through just about anything. Unfortunately, that anything includes human flesh. I know this because a few months after receiving the knife I was cutting an avocado and the knife slipped in my hand. It was quite a bad cut.
Obviously—I still have all ten fingers—my wound healed eventually. But I do have a pretty clear memory of the incident, which makes me quite fearful of repeating it. Here are two ways I could protect myself from future self-inflicted injury:
Decide the knife is too sharp. I could replace the Shun knife with a duller one, so that if my hand ever slips while cutting again the injury won’t be so bad.
Decide I wasn’t careful enough. In the future I could cut more slowly and be very cautious whenever I’m using...
In a footnote to my post a while ago on SafeYAML1, I established a goal of writing more about my many open source projects, which I have a bad habit of not telling anyone about—sometimes even long after they’re finished!
Here, I’ll give you an example (note: this is probably not going to display properly for those of you on RSS readers; visit the website to see what I’m trying to show you!):
<tableclass="render-to-bar-chart"><tr><th>Method of rendering a chart</th><th>How easy it is (scale from 1 to 10)</th></tr><tr><td>Using Highcharts directly</td><td>3</td></tr><tr><td>Using HighTables</td><td>10</td></tr></table>
Most people outside of the software development profession (and even many on the inside) may not realize that there is some disagreement within the community as to whether or not software development is a form of engineering.
Let’s say you placed software developers along a spectrum, where at one end “engineering” might as well be a foreign word, and at the other end writing software is obviously a form of engineering, in much the same way that painting or sculpture is obviously a form of art.
Personally, I have worked at various points along this spectrum. My first developer job was at a trading company in Philadelphia, which would have fallen pretty close to the extreme left end. At ThoughtWorks I would say the culture was somewhere in the middle, with plenty of developers leaning in both directions (I definitely worked with self-professed “engineers” at ThoughtWorks, as well as individuals who vehemently rejected the label).
When my wife and I moved from Philadelphia to San Francisco in 2010, we brought our espresso machine with us.
Back in Philly, we’d had a modest kitchen with just enough counter space for the machine. On lazy weekend mornings, I’d often turn it on and prepare us each a latte drink. It was a nice little ritual.
So we brought it to San Francisco with us. But our first apartment, a little studio we rented from a friend of a friend, didn’t have the room for it. So the machine went into storage.
Then in 2011, we moved to our current apartment in the Mission. The espresso machine is back; but we don’t have quite the counter space that we did in Philadelphia, so it’s sitting on a little cart underneath our microwave, unplugged.
This isn’t terribly inconvenient. To use it, I only need to pick it up and set it somewhere—say, on our table—then put it back when I’m finished. Still, the fact remains: I haven’t used it once1 since moving here.
It’s natural to think of being smart as an asset. This is obvious in many ways, so I don’t feel I need to enumerate them. But there are also ways that it can be a liability; and since this is the contrarian view, I naturally want to talk about it1.
Before I start, though, a note about the word “smart”: it can mean many things. What I am specifically referring to now is what I will call raw brain power: the capacity of a person’s mind to think quickly, grasp tricky concepts, store a lot of information at once, and so on. If the mind were a computer, in other words, I’d be talking about hardware (CPU, memory, etc.) as opposed to software.
The software of a computer system makes use of the hardware. It isn’t the other way around. Powerful hardware on its own is useless. For the purpose of this argument I propose that we think of being “smart”–i.e., of having a lot of brain power—as analogous to having a computer with powerful hardware. In contrast, having good instincts, solid judgment...
In a strongly-worded blog post back in 2010, David MacIver asserted that there is a fundamental flaw in DataMapper, an ORM library for Ruby. The core of his complaint is1 that DataMapper’s default API for saving records hides errors, making it difficult to diagnose what went wrong when something fails. This in turn increases the likelihood of defects going unnoticed during development and testing, resulting in buggier software.
Borrowing from MacIver’s post2, the below is a boilerplate example of how one might attempt to save a record and report any failures using DataMapper:
my_account=Account.new(:name=>"Jose")ifmy_account.save# my_account is valid and has been savedelsemy_account.errors.eachdo|e|putseendend
The above can be pretty annoying to anyone who expects conciseness from an API. Most developers don’t like the idea of having to write several lines of code just to save a record to a database.