software development
Source control is the very bedrock of software development. Without some sort of version control system in place, you can't reasonably call yourself a software engineer. If you're using a source control system of any kind, you're versioning files almost by definition. The concept
programming concepts
Software developers do love to code [https://blog.codinghorror.com/the-best-code-is-no-code-at-all/]. But very few of them, in my experience, can explain why they're coding. Try this exercise on one of your teammates if you don't believe me. Ask them what they're doing. Then ask
game development
I originally discovered the fiendishly addictive Tower Defense as a multiplayer game modification for Warcraft III [http://www.blizzard.com/war3/]. It's a cooperative game mode where you, and a few other players, are presented with a simple maze. A group of monsters appear at the entrance and
software development
Alistair Cockburn maintains that software development is a cooperative game: If software development was really a science, you could apply the scientific method to it. If it was really engineering, then you could apply known engineering techniques. If software development was a matter of producing models, then you could spend
programming practices
As a software developer, you may be familiar with the DRY principle: don't repeat yourself. It's absolute bedrock in software engineering, and it's covered beautifully in The Pragmatic Programmer, and even more succinctly in this brief IEEE software article (pdf). If you haven'
software development
In Microsoft Project and the Gantt Waterfall, many commenters wondered why software projects can't be treated like any other construction or engineering project: I am not sure why it is so difficult to estimate software development? Is it a mystery, magic, is there a man behind the curtain
unit testing
J. Timothy King has a nice piece on the twelve benefits of writing unit tests first. Unfortunately, he seriously undermines his message by ending with this: However, if you are one of the [coders who won't give up code-first], one of those curmudgeon coders who would rather be
software development concepts
Chapter 2 of Software Estimation: Demystifying the Black Art [http://www.amazon.com/exec/obidos/ASIN/0735605351/codihorr-20] opens with a quiz designed to test your estimation abilities. It's an interesting exercise, so I thought everyone might like to give it a shot. * For each question, fill in
software development concepts
One of the central themes in McConnell's Software Estimation: Demystifying the Black Art is the ominously named Cone of Uncertainty. The cone defines statistically predictible levels of project estimate uncertainty at each stage of the project. The cone has several ramifications, the most important of which is that
software development
I'm currently reading Steve McConnell's new book, Software Estimation: Demystifying the Black Art [http://www.amazon.com/exec/obidos/ASIN/0735605351/codihorr-20]. The section on individual expert judgment provided one simple reason why my estimates are often so horribly wrong:> If you ask a developer
software maintenance
Mention the words "maintenance programming" to a group of developers and they'll, to a man (or woman), recoil in horror. Maintenance programming is widely viewed as janitorial work. But maybe that's an unfair characterization. In Software Conflict 2.0 : The Art and Science of
software development
From the IEEE article Why Software Fails: Last October, for instance, the giant British food retailer J Sainsbury had to write off its US $526 million investment in an automated supply-chain management system. Merchandise was stuck in the company's depots and warehouses and was not getting through to