Tag: Steve McConnell

Code Conventions

Traffic lights highlight the importance of conventions. What would you do if you encounter a traffic light colored purple, white, and orange?

Like revision control, fresh graduates are introduced to the foreign concept of code conventions (or “coding standards”) once they enter professional software teams. As implied by the term, “code conventions” are a set of standards and guidelines that developers have to follow when coding in their software project.

Contrary to what many people think, code conventions are not there simply to make code style consistent throughout large projects with hundreds of thousands of lines of code. Nor is it simply an unnecessary tool used by senior developers to assert their control over the project that only complicates coding.

In fact, properly defined code conventions help manage complexity.

Continue reading “Code Conventions”

Basic Software Estimation Graphs

Software Estimation: Demystifying the Black Art

Let’s face it, everyone fails at software estimation including yours truly. It’s probably the least understood part of software development simply because the uncertainties in

This post will not deal with software estimation directly. Instead, it will show you the graphs related to software estimation that you should be familiar with. All of these graphs come from Steve McConnell‘s wonderful book Software Estimation: Demystifying the Black Art; the first group of graphs were copy-pasted from the free Construx presentations while the rest of the graphs were drafted using MS Paint.

Continue reading “Basic Software Estimation Graphs”

Tools and Training

backhoe

No Silver Bullet tells us to be skeptical about claims of tools that can provide drastic improvements in productivity. What we can instead hope for from productivity tools are minor, yet still significant, improvements.

However, both lowering our expectations and going with proven technologies aren’t enough to receive productivity benefits when introducing a new tool. Many companies still fail because of a certain classic mistake: Lack of Training.

Continue reading “Tools and Training”

Technical Debt

Technical debt is an important fundamental concept in the software engineering world, mainly because it pops up quite often in most real-world software projects. As much as I’d like to put the concept in my own words and sprinkle some personal experiences on it, Steve McConnell already wrote two good posts on the topic last year.

The term “technical debt” was coined by Ward Cunningham to describe the obligation that a software organization incurs when it chooses a design or construction approach that’s expedient in the short term but that increases complexity and is more costly in the long term.

Ward didn’t develop the metaphor in very much depth. The few other people who have discussed technical debt seem to use the metaphor mainly to communicate the concept to technical staff. I agree that it’s a useful metaphor for communicating with technical staff, but I’m more interested in the metaphor’s incredibly rich ability to explain a critical technical concept to non-technical project stakeholders.

Technical Debt and Technical Debt Decision Making [from 10x Software Development]

Quick Review of the Best SE Books

Code Complete 2

The most annoying part about passing by the Computer section of bookstores is when you realize that all of the books in the bookshelves will be obsolete in 5-10 years. This is why serious software engineers prioritize books on processes and methodologies over books on tools.

One guy (Jurgen Appelo) compiled a list of the best of SE books based on “1) number of Amazon reviews, 2) average Amazon rating, 3) number of Google hits and 4) Jolt awards”. Think SE version of Personal MBA.

Below the cut is the top ten. I’ve included my own mini-reviews for the books that I’ve already read.

Continue reading “Quick Review of the Best SE Books”