existence, refactored

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…

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…

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…

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]

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…

Copy and paste is a design error.
-David Parnas

Once a developer groks this quote, he/she has already achieved another level of understanding software development.

continue reading…

While I was fixing my Google Reader feed for BusinessWorld‘s IT Matters site (they changed from http://www.itmatters.com.ph/RSS/itmatters.rss to http://www.bworldonline.com/RSS/itmatters.rss), one article caught my eye:

IT needs best practices, too!

My first reaction was, “No sh*t, Sherlock!” After reading the article and finding out that it’s not talking about software engineering practices (which I am sure isn’t being practiced by many local software houses) but the low adoption rates of best practices in Auditing and Risk Management in IT departments, my reaction was still “No sh*t, Sherlock!”. I mean, if you’re dealing with foreign clients and yet you’re not familiar with those processes then you have a big problem on your hands. Either that or you know a good place with steak and strippers.

Since we’re at the topic of Best Practices, I might as well cover it in this post.

continue reading…

In the South Seas there is a cargo cult of people. During the war they saw airplanes with lots of good materials, and they want the same thing to happen now. So they’ve arranged to make things like runways, to put fires along the sides of the runways, to make a wooden hut for a man to sit in, with two wooden pieces on his head for headphones and bars of bamboo sticking out like antennas—he’s the controller—and they wait for the airplanes to land. They’re doing everything right. The form is perfect. It looks exactly the way it looked before. But it doesn’t work. No airplanes land. So I call these things cargo cult science, because they follow all the apparent precepts and forms of scientific investigation, but they’re missing something essential, because the planes don’t land.
— Richard Feynman

Many of the problems shared by business management and software engineering I mentioned in the previous post stem from Cargo Cult Thinking. As mentioned by noted physicist Richard Feynman in his famous speech to CalTech students that even in these modern times, people resort to blindly following how other people do things in the hopes of reaping the same results.

Dr. Feynman used cargo cults to criticize how many scientists fail to follow the scientific method by merely going through the steps of experimentation but not making sure that their process is scientifically sound. The Halo Effect uses cargo cults in the same manner by exposing the mistakes made by best selling management books in their research. The book basically tells the reader to ignore all those pages detailing how the latter conducted its research because no matter how “rigorous” they were conducted, they were never sound to begin with i.e. there were critical flaws in their process from the start.

Cargo cult thinking in the field of software engineering doesn’t even bother with claiming to follow the scientific method. As Steve McConnell writes in his “From the Editor” article in IEEE Software, March/April 2000, some managers are deluded to think that simply following the culture of highly successful companies will result in radical improvements in productivity. On the smaller scale, many novice programmers (and sadly, software teams in general) are deluded to follow cargo cult programming practices without even knowing why they are used successfully by other coders in the first place.

In my opinion, cargo cult thinking isn’t that bad… if only one or two people are affected. As they usually fail in a spectacular fashion, they make the affected people think twice before doing something like that again. If an entire group, or worse, an entire company is blindly following cargo cult thinking… well… either you ramp up your risk management or you start making popcorn for the drama that will unfold.

One of the most important concepts one must understand when entering the IT industry is the fact that Computer Science is different from Software Engineering.

I hold a degree in Computer Science, and like most fresh graduates, once I stepped into the corporate world, I immediately found out that what I have been studying for 4 years has almost nothing to do with real-world software development. For example, the theories in computing that we have studied in college are rarely applicable in real-world applications. Even the approach to programming itself that was taught to us in college was fundamentally flawed – we were never taught how to program in groups, or to program with maintenance in mind.

College teaches us to build dog houses. The real world wants us to build skyscrapers.

So here we arrive at the problem: the misconception that Computer Science knowledge is enough to develop good software. And here’s where Software Engineering steps in.

–

Without going to much into the technical details, we can look at “engineering” as simply the application of science to practically solve problems. Civil Engineers use Physics to create structurally sound buildings (i.e. structures that won’t collapse and kill people). Electronic Engineers also use Physics to build consumer electronics (i.e. devices that don’t blow up and kill people). Chemical Engineers use Chemistry to process chemicals into more useful ones (i.e in plants that don’t blow… you know the drill).

Steve McConnell (my favorite author in the industry), in his book Professional Software Development, uses Physicists to show why making scientists do engineering stuff is a bad idea. In the book, he asks you to imagine what would happen if a person with a PhD in Physics would be asked to “design electrical equipment for commercial sale”.

While the physicist would probably be able to design a working prototype of the device, it is not likely that he will take into account the factors that come in when designing commercial products.

• Will the device be robust enough to withstand day to day use?
• Will it pass safety standards?
• Is the cost of materials and production low enough to produce profit?

As you can see, the problem here is almost the same as the problems I encountered above when I started building real-world applications.

By now the importance of Software Engineering knowledge should be clear to you. If you’re a software developer, it is your responsibility to study the various aspects of SE to improve the quality of your work.

If you’re a manager, not only is it your responsibility to be familiar with the organizational and processes side of SE, it is also your responsibility to train new employees in SE. I would even have to go as to say that you must make them unlearn (brainwash?) some of the “unhealthy” practices that they have learned in college.

As SE (along with Project Management) is my primary focus nowadays, expect to see me post more SE stuff here in the future.