Month: February 2012

Retro Black & White Game Pack for Android

I am proud to announce Android version of the Retro Black & White Game Pack!

After making the Windows Phone 7 version I decided it would be interesting to also explore Android. You can check out the result by downloading the free version from the market and get the complete game of plankmen. If you like the trials of the other two games aswell, you can buy the full version of the app over here.

It is supported on android 2.1 and higher for all resolutions.

For more information, please visit this page.

TechDays 2012

Last Thursday and Friday I visited the Microsoft TechDays.

It was very interesting to hear about the new developments for Windows and other Microsoft products. Some of the subjects are known for a while, but it was very meaningful to hear the developers and managers talk about it themselves.

One thing I’m particularly excited about is the new way of asynchronous programming using the “async” and “await” keywords. It allows the compiler to handle callbacks for you and makes parallel programming a lot easier for developers.

Besides the Microsoft lectures there were also a lot of third party talks from people and companies who shared good ideas and tips.

All in all, two days well spend!

In software the race goes to those who go well, not those who go fast.

A very nice story about writing quality software. I did not write it myself but I feel it’s certainly worth quoting:

In software the race goes to those who go well, not those who go fast.

Have you ever been to a tractor pull? Imagine a huge arena filled with mud and churned up soil. Huge tractors tie themselves up to devices of torture and try to pull them accross the arena. The devices get harder to pull the farther they go. They are inclined planes with wheels on the rear and a wide shoe at the front that sits squarely on the ground. There is a huge weight at the rear that is attached to a mechnism that drags the weight up the inclined plane and over the shoe as the wheels turn. This steadily increases the weight over the shoe until the friction overcomes the ability of the tractor.

Writing software is like a tractor pull. You start out fast without a lot of friction. Productivity is high, and you get a lot done. But the more you write the harder it gets to write more. The weight is being dragged up over the shoe. The more you write the more the mess builds. Productivity slows. Overtime increases. Teams grow larger. More and more code is piled up over the shoe, and the development team grinds to a halt unable to pull the huge mass of code any farther through the mud.

Our industry is addicted to speed; and it’s killing us. As we leap out of the starting gate on a new project, if we focus on speed over quality, we sew the cause of our eventual defeat. As an industry, as a profession, we need to seriously re-think the way we do software. In software, speed kills.

The way to go fast, is to go well. Going well means taking time to keep the code clean, to write tests, to refactor, to take care of the code. Going well means taking a deliberate and caring attitude for the code, and the system. Going well means working as a team, communicating frequently, reviewing and inspecting code and designs. Going well means never checking in code that fails unit tests or acceptance tests. Going well means integrating frequently, at least once per day. Going well means staying rested.

There is always time to write tests. There is always time to refactor and keep the code clean. There is always time to review and inspect and pair. There is always time to integrate frequently. Indeed, there is no time not to do these things, because these are the things that keep us going fast. These are the things that keep the weight back over the wheels rather than over the shoe. These are the things that keep our productivity high, and our code flexible and malleable.

Over the years I’ve published a lot about design principles, design patterns, and development practices that can help teams keep their code clean and flexible. However, these principles, patterns, and practices are only of use to the folks who take the time to use them. Interestingly enough, these are the same folks who will get done faster, and better, than those who don’t take the time. Those who don’t take the time just keep dragging the weight up over the shoe.

The next time you say to yourself: “I don’t have time to do it right.” — stop! Rethink the issue. You don’t have time not to do it right!

Where did we get the idea that our companies wanted us to write crap? Aren’t they paying a lot of money for this software? Aren’t they going to depend upon this software for profits? Isn’t this softwareworth a lot? If so, then why would our company want to pay for crap that slows us down? Wouldn’t they rather have good clean code that keeps us running fast?

A few years ago I hired two apprentices. I gave them a project to do. They came back a day later and said they were done and asked if I’d like to see it. I knew this project should take more than a day, so I started asking them about how they had built the project. I asked them whether they had written tests, or whether they had separated concerns. I showed them alternate designs and different coding practices that were better than the ones they had used. They were incredulous. “We feel bad because you are paying us a lot and we want to get this done fast.” they said. I explained to them that the software they were writing was intrinsic to my business, and that it was more important to me that it be done well, than done fast. I explained that if they didn’t do it well, then they’d be maintaining a mess for years, and that maintenance would take much more time and energy than they’d saved by doing it fast. I told them to go back and do it well. And they did.

We often blame managers for schedule pressure. We often complain that our companies set unreasonable deadlines and have unrealistic expectations. This might be true, but it’s only half the problem. The other half, the most important half, is within us. We consider our worth as programmers to be more associated with speed than with quality. And that’s a tragedy; because it leads us to create messes. It leads us down the slower path. By rushing we ruin our chance to truly go fast.

I was with a team the other day, and the manager of the team said to them: “I want this code to be something you’d be willing to hang on your grandmother’s refrigerator. I want it to be high quality. Remember, two years from now all people will see is the mess, they won’t see how fast you got it done. Nobody remembers the speed, they only remember the mess. So do it right”. The programmers looked at him skeptically. Their boss just told them to go well, instead of going fast, and they didn’t believe him. What does it take?

Take my advice: go well, not fast. Care about your code. Take the time to do things right. In software, slow and steady wins the race; and speed kills.