Requirements bloat fighting

Requirements proliferation must be fought, by both birth control and infanticide.

Frederick P. Brooks. The Design Of Design. 2010. 

Experience and promotion

I recently came across a couple of articles on how promotion and experience are managed in two different (maybe not so much) software development companies.

The first of them is Why I ran a flat company by Jason Fried. I like his position on keeping the organization as flat as possible and the idea of self-managing teams. But what I like most is what he points out as horizontal ambition. "We always try to hire people who yearn to be master craftspeople, that is, designers who want to be great designers, not managers of designers; developers who want to master the art of programming, not management.", I find this quote to express the concept quite clear.

The second article is Why I never let employees negotiate a raise by Joel Spolsky. He explains the compensation policy that they follow at his company and the rationale behind it. He defines a salary scale based on experience, scope of responsibility and skill set. So for each employee, three factors are measured and his/her final level defines the salary.

There is this quote that made me nod my head: "If you worked as a receptionist for six years, for example, you aren't credited with six years of experience; I give you credit for one year." It somehow leverages what I think about experience.

Paternity leave

So it's been a while since I wrote my last post here. The reason is that I've been too busy since February 20th, when my daughter was born. My wife and me have been taking good care of her and that, as any parents already know, requires a lot of time and energy.

This blog is a personal project, thus one of the first things I had to take aside. It's been almost two months since then.

I'm glad that I had the opportunity to invest all those time and energy in my family. It's been hard to adapt to the new situation. Now it's time to take it back.

Straightforwardness

I recently discovered Mimi & Eunice, a comic strip by Nina Paley. It's really inspired most of the time. I really love the simplicity of the drawing and the sharp dialogs.

I felt curious about it and clicked the site's About link and read this:

FREQUENTLY ASKED QUESTIONS:
[...]
Q. I have a great idea for a cartoon. Will you draw it for me?
A. No.

I enjoy the straightforwardness in the answer. You just can't say you don't understand or took it wrong. Easy. Simple. Perfect.

It also reminded me of a Rework essay: "Draw a line in the sand". I find Nina Paley's answer draws a pretty clear line in the sand.

Smoke Tests

I learned what Smoke Tests are. A software smoke test would be the test or set of tests that are made to the software system first after a new build to assure the program performs some basic actions so it is ready for some other more stressful testing.

I've been thinking about it. In some development projects I've been involved, the testing team did not have any smoke testing. But the development team did perform some basic testing before handing a new build to the testing team: just run the program and check it displays basic data in screen when feeding test input.

In a different project, the development included unit tests that where compiled and run together within the build process, making the build process fail if tests do fail. Not performing a smoke test suite on a new build is not a big deal when there is a good set of unit tests compiling and running together with the application build.

Unit testing lowers the probability of a fatal failure on a new build, but it doesn't cancel it at all.

Funny why the name for these tests:

The phrase smoke test comes from hardware testing. You plug in a new board and turn on the power. If you see smoke coming from the board, turn off the power. You don't have to do any more testing.

Kaner, Bach, and Pettichord. "Lessons Learned in Software Testing".

Wiley Computer Publishing, 2002, p. 95.

ISBN 0-471-08112-4 

Syntax highlighting

In my last post, I included some C++ code snippets. I always wondered how to provide syntax highlighting when posting some code, so a quick Google search for html syntax highlighting headed me towards tohtml.com.

It's a really useful and simple web app for the occasional code blogger, since I was afraid of the possibility that I would have to manually edit the blog's template CSS to achieve it.

Loops on STL containers

C++ and STL are my everyday working tools. I have get used to use the same construction to iterate through the elements in an STL container:


I've seen most people use a for instead of a while loop:


I find the following reasons to prefer the first over the second option:

1. The statement for the for loop is too large and usually need to be split into 2 (ugly) or 3 (same as while) lines.
2. In the while option, operations are performed on the variable Object instead of the iterator itElement, yielding a cleaner and more readable coding style. This becomes a greater advantage when the container is a map instead of a vector.
3. If some elements must be removed from the container, the for loop is simply not an option, whereas the while option is the way to go.