Michael Wolfe provides an excellent answer to the question of why software development estimates are regularly off by a factor of 2-3:
Let’s take a hike on the coast from San Francisco to Los Angeles to visit our friends in Newport Beach.
Light Year Software has been working with CueYou, Ltd. for the last few months on their exciting new app. This morning they were guests on All Sides with Ann Fisher to talk about the product.
A lesson I learned during my years in university and had to re-learn once or twice while working in Silicon Valley is that working long hours is beneficial, but only for a very short period of time. One or two 60 hour weeks is enough, as is even a single all-nighter. When you’re sleep deprived, you don’t make good decisions, and software development is all about good decisions. There is never one solution to a problem. A good engineer picks one of the best solutions through creativity and experience. Sleep deprivation dulls the ability to do either well.
In Don’t be a Hero, Alex Payne makes the additional argument that an individual working these long hours is a sign that your culture has a problem.
Work/life balance is important. These days, I only work long hours if it’s because I made a mistake. Everything I do is, in part, an effort to avoid this: fair and realistic estimates, regular communication with my customers, and not slacking off early in a project.
If you don’t like making up your own mind and prefer to ride the wave of whatever happens to be popular right now, you might think that, when it comes to source control, there are two choices: Subversion and Git, and no middle ground.
(Yes, there are others, but I’m trying to keep this simple.)
This is just not true. Daniel Jalkut addresses this from one perspective in Zealotry For Good And Evil, but I’d like to add to his arguments from the perspective of a single developer or small team.
Subversion works in mostly the same way that source control has worked for decades, so for anyone that’s been in the industry for a while, there are few surprises. This means that, for the most part, the source control system stays out of the way and does the jobs we need it to.
Git was built to solve a different problem: how to provide source control to a globally distributed team, where one centralized, master repository was viewed as a bug, not a feature. Individuals or small teams don’t have this problem.
Fundamentally, though, rather than having arguments about which source control system is “better,” recognize that they are tools, with different strengths, and use the one that feels the best to you and lets you get your work done efficiently.
Personally, I’m experimenting with using Git as a means to version controlling projects for clients where I expect to make changes in many places, but I don’t expect the project to last very long. For these, it seems more trouble than it’s worth to carve out a place in my central Subversion repository, especially because I won’t need to provide outside access to it. Git’s placement of the repository within my working tree is a feature here.
This is a post I’ve been meaning to write for a very long time, but I’ve always had other, more pressing work, to do, and so I never wrote it.
Rands posted his version today, though he’s using my point as an introduction to an Election Day moral than as a post about software development itself.
Still, the first half of his post is spot-on. In software, given enough time, it’s possible to do just about anything. There’s a classic joke in software development circles: fast, cheap and good: pick two. It’s not a question of if, it’s a question of when.
My customers don’t always understand this. A seemingly minor change can have wide-reaching ramifications, perhaps doubling the time (and cost) of a project.
It’s great to have an idea of what you want to build, but it’s just as important to listen to an expert when it comes to implementation. “Can we do this?” is not a good question. The answer is almost always “yes.” “I’d like to do this, but I only want to spend this much (or, I’d like it by this date)” is far better.