Steve McConnell goes through the code conventions for the if statement in Code Complete II. He argues the main styles used are:

// 1
if (isValid) doSomething();

// 2a
if (isValid) {
    doSomething(); 
}

// 2b
if (isValid)
{
    doSomething();
}

// 3
if (isValid)
    doSomething();

McConnell argues that 2a and 2b are the best ones of those and isn't picky between the two as long as the codebase is consistent. There were no empirical studies on productivity and the if statement that he could draw upon.

I personally prefer 2a as it is the most readable and the most concise. Dropping brackets onto the line below for statements, methods and classes is a bit of a waste of space in my opinion.

I also dislike the not using of braces in statements as well. For multiple reasons. As an example this is hard to read and prone to creating errors;

 if (isValid)
    doSomething();
    doSomethingElse();

An error in indenting can a bug as the doSomethingElse() method is not under the if statement.

Another reason I prefer 2a and the constant use of braces in software code is that when I was working in Javascript and writing photobook code; the javascript was stripped down for production and had all the end of lines removed.

If a javascript function or statement did not have its braces it usually caused a catastrophic error in Internet Explorer and would not load the page at all. Those errors would take three to four days of running jlint to hunt down. It was horrible.

Syntactic completeness is necessary in my opinion and not only for the aiding of readability. (reply)

Creative Class looks at smoking and obesity and discovers that in their demographic they focus on that smoking and obesity are lower:

What this all seems to mean is that places that have transitioned to postindustrialism go beyond economics and innovation. In addition to generating better-paying jobs and having higher levels of income and innovation, these sorts of places appear to have better health outcomes as well, and they do so in ways that go beyond the effects of just higher levels of economic output.

Richard Florida's argument is that the creative class pursue lifestyles and this includes being highly active outside of work; such as the gym, hiking, cycling, etc. The other aspect is that creative work is highly demanding and you have to be fit to be a software engineer in order to survive the brutal project schedules. Software engineers are not alone, most of these 'creative class' professions face long hours and trying schedules. (reply)

I often say, "Projects always win." By the end of a project the team is tired, worn out, and starting to succumb to illness and stress. Projects tend to be brutal, even the well managed ones hit upon tight deadlines and requirements overreach. Hours and the constant pressure build up, leaving the team tired enough to make rookie mistakes in their code even with the buffers of unit testing.

The best way to fight most of that off is by being fit. Good health, constantly working out, running, swimming etc means you are better able to fight off stress, more capable of avoiding colds and flu and leaves you in a better frame of mind as well.

Our group has been on a fitness kick. One of the guys just trained for a half-marathon and several others have gone on weight loss regimes - successfully too.

The rigors of software engineering and project based production are such that you have to be fit to survive it. Project do win, but being in peak fitness dulls the negative effects of stress, illness, tiredness and fatigue. You have to be fit be a software engineer. (more)

I have had this URL and idea hanging around for several years now. I recently started working on it again in both gwt and turbogears. Time to jot down some user stories for it rather than blindly coding.

The impetus for it was my dissatisfaction with Ameritrade. I was annoyed that there was a $10 fee on every transaction so I had to invest $1,000 a time to make that fee minimal. I wanted to be able to invest as little as $50 if I had it.

I also didn't want the complexity of choosing single winners and losers, I largely do coffee house investing and would like that spread across a similar structure.

Additionally I would like to be able to do transactions - swap shares with others - rather than the clunky pull it out, wait a day, then transfer it to my checking account etc. If I needed to pay $1000 for something, I would like to be able to trade shares directly into their account. Sometimes investing is like a second checking account.

Starting off with user stories can be paralyzing, in large teams it is better if someone just writes one and then see if people agree with it or not. The business analysts will make it overly complicated, and engineers will make it overly simple.

Personally I don't think it is important to argue over one word in a user story as the tasks the flow from it end up being the authority in the work and the user story becomes more of a placeholder for completeness than any hard and explicit requirement.

Very interesting article about using environments to define behavior. While the stand out example is of reducing errors in medication being handed out through nurses where a vest that means they cannot be interrupted; there was another example directly relevant to software where the method of a silent cockpit in commercial airlines was adopted:

The IT group decided to try an experiment--they established 'quiet hours' on Tuesday, Thursday, and Friday mornings before noon. The goal was to give coders a sterile cockpit, allowing them to tackle more complex bits of coding without being derailed by periodic interruptions. Even the socially insensitive responded well to the change in the Path. ... And the division VP attributed the success to the sterile cockpit quiet hours: "I do not think we could've made the deadline without it".

Software engineers use the ipod for that purpose, endeavouring to shut out the world and get to focus on the task at hand. The alternate is pair programming where you enjoy distraction with another developer as you work on a solution but where the chatter and interruptions are about the work you are doing.

Our company has moved over to Agile where it is being adopted at all levels of the organization. One of the issues that hasn't been resolved is the cube farm where the engineers work. I have not thought up a solution to that yet. We are sticking our scrum boards up in the cube farm area now, where they were isolated in a conference room down the hall previously, but as to what to do with the cubes - I don't know. Apparently we can do what we want with the area but I haven't been able to think of anything, and neither has anyone else so far it seems.

We are using Bamboo for continuous integration. Not by choice, the company I am with is using JIRA for their issue tracking and bought Bamboo, Clover, etc along with the suite of tools. Apparently Atlassian is Australian. One of the SEM guys calls them "down there" when he speaks or emails with their support group.

Bamboo polls rather than having an event driven model. Our SEM guy has written a python module which uses subversion's pre-commit hook to match a commit up to a JIRA ticket though it is a bit clumsy on the regexp side of things - rejecting IE-7 and non-assigned tickets in the description, for instance, from physical merges.

But on the Bamboo side of things we are stuck with a 180 second polling of the source code repository and then using its project dependency model in the plans for having other projects build off others.

We were chatting with the SEM guy today to work out if Atlassian offered a tool or plug-in where we could fail a commit before it was committed to the repository. We can do it with a subversion pre-commit hook and then firing off ant build scripts (or MS-Build scripts depending on the project), not allowing the commit if the builds, unit tests and eventually the functional tests fail. The latter will be difficult as it is a distributed system and runs on a proprietary j2EE system.

It does not appear that Atlassian has anything like that, so we might have to end up rolling our own. One of the reasons we are pursuing this is because if we can get this working, then dev and a branch are as stable as stage (albeit with less data due to PCI concerns) and we can drop an entire environment from the dev to production process. Not allowing bad commits in will mean that the development integration environment is never broken and always stable - if not production ready.

We have some work today but we can see a day in the near future when that is possible, it may even be within the bounds of the next project. We are that close ...

We are at the stage in our project when use cases are being finalized as working code and the third party we are integrating with is at the same point. A flurry of bug fixes are coming in as we shake out issues in the software with each new functional test and discovering unintended edge cases and differences in the two system that have to be reconciled. No amount of planning or unit testing will solve those kind of functional issues.

Our dev integration environment is screaming along and the third party is now doing daily deployments into it. You would think that with that type of velocity it would be a recipe for volatility but software is a strange counter intuitive beast and it is now the most complete, stable and up to date environment we have. QA, staging and even prod appear archaic in comparison - even wasteful to expend energy on.

We did the final merge from the main trunk today and our branch will soon be main itself. Pretty cool feeling to cross the finish line in a surge of confidence and no crunch period in sight. Next for us will be an increasing barrage of functional tests that will make any future deployment of the code self-testing so that we can revert an environment if a single test fails. Continuous deployment here we come. First step forward. Awesome.

I haven't been having much luck with code coverage tools. Recently I have tried Clover and EclEmma with eclipse and haven't managed to get either working properly. We structure our code and unit tests in the format:

src
test

with the src handling source code duties and the test package having the unit tests in it under the same package structure as the working code. For whatever reason the coverage interceptors aren't picking those up. EclEmma ran its code coverage over our test packages. I guess we will keep looking until we find one that suits us.

An interesting essay on Test Driven Development [TDD] which links to an empirical study [pdf] on the effectiveness of TDD in projects and its impact on quality and development speed. The abstract included:

Based on the findings of the existing studies, it can be concluded that TDD seems to improve software quality, especially when employed in an industrial context.

Industrial there seems to mean out in the real world of development at corporations and software shops. Of the thirteen studies that were looked at in this study only three were in a production environment, the rest were academic or computer science students or the voluntary participation of professional developers. Which limits the usefulness of the results. However of the industrial studies:

It is especially significant that all industrial case studies reported considerably reduced defect rates, as much as 40 to 50 % less. The productivity effects were not that obvious: ... report TDD significantly decreasing the lead-time while the ... other ... study shows TDD to have no difference or only slight impact to the developer productivity.

One of the benefits of TDD is that it espouses 100% test coverage. If you are doing tests first and API second then you are guaranteed to have 100% test coverage of your code which I do not doubt reduces defect rates. Unit testing is pretty powerful when done well and when it covers the cyclomatic complexity of code.

I personally do not use TDD, I prefer to muck around with the code first and get something in place first before locking it down with unit tests. I agree with the original essay that TDD tends to freeze the API in place to early. Some freedom is needed to 'feel out' the design of the code in my not so humble opinion.

The counter argument is that you can refactor with confidence once there is 100% coverage in place and then improve the design under the umbrella of passing tests.

Release processes can be horribly manual and laborious. Rafe Colburn lists a few reasons why releases can suck.

The previous place I was at release day was on the second Tuesday morning of the month and releases went through at 11:00am which included draining over a couple of hundred webservers. Odds first, then evens, until twenty four hours later the entire web facing servers were on the new release code base.

It was a pretty slick operation and the main reason for the success of the release team was automation. They had scripted the whole process, nothing was manual.

The main reason releases suck is because the whole thing is manual and requires too many people to do something to make the release happen. This exponentially increases the margin for human error.

A simple rule in software engineering is if you do something twice, then script or code it. If you do it three times and haven't got it coded and in the source code repository you are not a software engineer...

Releases happen constantly so there is really no excuse for it not being automated in a company. There are plenty of chances to get the automation down as well as code bases go from dev to QA to stage to production. Really there is no excuse in this day and age for releases to suck.

If you look at continuous deployment it is an argument for automation taken to extreme lengths. Releases don't suck when they are automated. They do when they are manual.