Articles about Software Development

Read the Diffs ()
Requirements ()
Advocating the use of code coverage ()
Yours, Mine and Ours ()
My life as a Code Economist ()
Scalability Story ()
My comments on "Hitting the High Notes" ()
Thoughts on development methodologies ()
Great Hacker != Great Hire ()
When great hackers are as fussy as Graham says they are, they're not worth the trouble.  We want the super-productivity, and we want the innate love of software development, but we don't want all the extra baggage.
Single User Source Control ()
For any team of two or more people, I can credibly argue the benefits of a good source control tool.  And as the team gets even larger, source control evolves from "beneficial" to "compelling" to "necessary" and finally to "you are a complete bozo if you don't use it".
F5 ()
And then I realized that my lousy problem-solving skills are actually Visual Studio's fault.
Career Calculus ()
I submit that worrying about how others perceive your C value is a waste of time. The key to a great career is to focus on L, the first derivative of the equation. L is the rate at which your cluefulness is changing over time. The actual value of C at any given moment is usually a distraction. Only one question matters: With each day that goes by, are you getting more clueful, or less clueful? Or are you just stuck?
Beyond CheckOut and CheckIn ()
Many people use only a small portion of the features of the version control system. If you use little more than checkout and checkin, you might actually be in the majority. A Vault user recently asked me to explain why anyone would use things like Share, Branch, Label, Cloak, and Merge Branch Into Trunk. I had fun writing my response, so I thought I would re-post it here. Beware, this writeup doesn't even attempt to be objective about which version control product is most neato. :-)
Small ISVs:  You need Developers, not Programmers ()
For the purpose of this article, a "programmer" is someone who does nothing but code new features and [if you're lucky] fix bugs. They don't write specs.  They don't write automated test scripts.  They don't help keep the automated build system up to date. They don't help customers work out tough problems. They don't help write documentation. They don't help with testing. They don't even read code. All they do is write new code. In a small ISV, you don't want any of these people in your company.
What is a Small ISV? ()
On this weblog I often use the term "small ISV". It's time to define what I mean.
Followups on The .NET Abstraction Pile ()
Near the bottom of my article on The .NET Abstraction Pile, I mention that we've had some bad experiences with Java here at SourceGear. Yesterday I was pleasantly surprised when Joel Spolsky linked my article (thanks Joel). Today my mailbox is filled with email from Java fans telling me my remarks were unfair and incorrect.
Iceberg Sneak-Ins ()
Good project managers are made entirely out of paranoia, but the truly extraordinary project managers have a streak of courage.
The .NET Abstraction Pile ()
This success stands as a testimony to how incredible .NET really is. We built a reasonably full-featured version control system in 14 months, and it works. Sure, we had some trouble. Layers 25, 37 and 40 didn't always behave like they should. But layer 11 was problem-free, quite unlike its Java counterpart. Considering the productivity gains we received, I never expected things to go so smoothly.
Are Programmers Engineers? ()
Our universities call us engineers because there is no college where we fit. I don't blame them for that, but I have no desire to borrow the word engineer as an attempt to make myself sound more credible.