Tag Archive for 'human factor'

Some Random Quotes

Published on June 13, 2010 in Software Development. 0 Comments Tags: , , .

Last month I visited silicon valley again. Always nice to be there. Not only for the weather and the surroundings, but also always really good to catch up and work together with my overseas colleagues face to face again. Only the flight from Amsterdam to San Francisco is not a short one, though that leaves you a lot of time for reading. So I took my chance and took with me some various writings, most notably Coders at Work, which I can definitely recommend.

Anyways, all that reading got me to pen down some random but interesting quotes I encountered:

There are two ways to design a system: “One way is to make it so simple that there are obviously no deficiencies and the other ways is to make it so complicated that there are no obvious deficiencies” — C.A.R. Hoare.

“When documents are mostly to enable handoffs, they are evil. When they capture a record that is best not forgotten, they are valuable” —  Tom Poppendieck.

“Its easier to optimize correct code than to correct optimized code” — Joshua Bloch.

“There’s a grand myth about requirements: If you write them down, users will get exactly what they want. That’s not true. At best, users will get exactly what was written down, which may or may not be anything like what they really want.” — Mike Cohn

It’s interesting that only such a small number of words can express such a great deal of experience.

Coding Standards, But Why?

Published on December 21, 2009 in Software Development. 1 Comment Tags: , .

I already had a long standing draft to write something up about coding standards. To be more specific, coding standards about coding style. I’ve had many, no, too many (heated) discussions about coding standards and coding style, so I was — and am — reluctant to say something publicly about the topic. However, sometimes the momentum is just right, and you can’t resist.

As a developer, source code is your deliverable, it is the thing you produce, and you should try to make it look good. But what is good? How should it look? To debate this and find a compromise, you could as well host your own COP15. The results will be as disappointing. There is no such thing as the Best Looking Coding Style.

However, I do firmly believe in uniform coding style. In an independent team, all produced code style should be consistent. At all times. No exceptions. And I mean it: No Exceptions! Use iron fist if needed.

Well that’s what I believe. Do I need arguments? I think not; consistent coding style is intuitively a Good Thing. Unfortunately when talking to other developers, they want arguments. Of course — who doesn’t want arguments when somebody asks you to change habits?

So, to get back to the momentum I started with, while me and a colleague were in an email discussion with a certain module’s author about adapting his code into our team’s code base, the perfect opportunity revealed itself for me to get back to the dust-collecting coding standards post again.

My colleague wrote:

Just let me emphasize that we think style and code readability and consistency really is important, which is different from what a lot of people who write code think: if it works and the design is good, the code is good. This only holds when you’re the only one working on it, as soon as multiple people get involved it’s a very good thing to make all the code look uniformly, and keep the code readable and properly commented.

The main argument is that it helps shared ownership of the code (i.e. other people don’t feel reluctant editing your code to fix bugs, and won’t assume it is crap because it looks messy, to play the broken-window theory: it’s already crap so why should I care fixing it). Having all the code look the same also helps spotting inconsistencies, like parameters or functions that should be private but are public, debug code that is actually not debug code, comments that are misplaced and confusing etc.

It’s all a combination of minor nitpicking, but taking all of it together it definitely adds substantial value to a shared codebase.

Need I say more?

Software Centered Organisation

Published on September 28, 2009 in Software Development. 0 Comments Tags: , , .

I have always been fascinated with the link between software architecture and a company’s organizational structure. For the companies I have worked for so far, I found that the company’s structure can conflict with the software architecture that would work best. For example, a software development department might be organized into separate teams, where each team is working on a separate part of the software. Usually, the software architecture clearly reflects the team structure: the software interfaces have grown to represent the borders between the parts where each team is working on. Suppose the product has evolved over the years, while the teams remained the same. At some point, the existing interfaces might become a major burden to implement new features. This seems to be a common problem, where the software design reflects the initial team structure, while the product is screaming for a new and more appropriate architecture reflecting the evolved product’s structure. As a result, team organization becomes detrimental for product progression.

This concept is known as Conway’s Law, named after Mel Conway, who published a paper called “How Do Committees Invent?”. Fred Brooks cited Conway’s paper in his classic “The Mythical Man Month”, and invented the name “Conway’s Law”. Here’s the definition from Conway’s own website (which also has the original paper in full):

Any organization that designs a system (defined more broadly here than just information systems) will inevitably produce a design whose structure is a copy of the organization’s communication structure.

As Conway himself writes, “Brooks recognized that the law has important corollaries in management theory”. Here is one stated in the paper:

Because the design that occurs first is almost never the best possible, the prevailing system concept may need to change. Therefore, flexibility of organization is important to effective design.”

For example, there are many cases, where you want to improve a product and there’s no other way than to redesign its architecture. According to Conway’s Law, that means you will need to start reconsidering your development team organization: it might have to become more software (product) centered.

As a corollary to Conway’s Law I would say: don’t hold on to existing organization structures, if they are in the way. In a software company, it’s the product that sells. So if you want to improve the product and go forward, you will need to be flexible and willing to change: the company and its product should evolve together.