We here at Nodeta work incrementally. We standardly split all of our development efforts into smaller and smaller increments in order to better grasp what is planned, what is achieved and how well the two match. We do small things to get big things done.

When you’re making a piece of software, the first version usually sucks. It doesn’t matter, if you whipped the software up in an afternoon, or if you spent thousands of man months to develop it from point Nothing to point Done, it’s gonna suck. Instead, you need to do it in small increments, and then you need to throw most of those increments away and do them again. The bigger the increment is, the more likely it is that it will be made of suck, and you’ll need to do it again.

You need to start with minimal features, then build. Test your ideas early with real users when possible and use that feedback to re-create.

In a personal sense, it’s not always so simple to adopt the concept of incrementality to your work process. Many would like to have their handiwork done, polished, framed and fixated before showing it to anyone.

Team members and incrementality

In Scrum, stories (which group smaller tasks in a single sprint) are given acceptance criteria, so that it’s easy to check how well the story has been completed or implemented. You can use these following criteria to either test your team or potential members for their abilities to work incrementally.

You, as a software developer, need to realize that your code is not valuable in itself, it is only valuable in what it can do, and if what it does is not useful that week, it has no value. No matter how long you pondered to find the best and most beautiful solution to the problem you had. Not even if your code flows down the misty meadows like a clear and concise natural language, if it is not a part of a proven feature, it’s worthless. You need to remove it and move on. Move to the next piece of code. You need to start feeling good about your ability to produce good code, and not about your code itself. Code proudly with the backspace!

You, as a manager, need to understand that your funky new features are worthless if the previous features haven’t been proven good by testing them with actual customers and actual users. Features have no inherent value. If you have a feature that reaks, you need to kill it fast and hop on the do-over train. You also need to appreciate the value of incremental development, and mold the day-to-day working environment to support it.

You, as a product owner, need to be able to plan well often and in variable scopes. Any project should have a road map, on what is sometimes called ‘epic level’. That means you take the contents of the project and try to define them in as broad as terms possible, without restricting development paths. Then you need to be able to chop these epic features up into pieces with the team, and prioritize, prioritize, prioritize.

Special feature

In software development, there are no manufacturing costs. That’s why do-overs are not only possible but smart. Incrementality is a special feature of software development, and one of the reasons why any comparisons to, say, construction development, lead to horrendous distortions of the truth. Think about it, if you could start building your house by simply setting up the planned facade and if you could then change it without material costs, wouldn’t you do it like that? Of course you would.

First came Vim, and next Gaizka added APIdock integration to Emacs. Now perhaps the biggest favorite of most Ruby and Rails developers, myself included: Textmate! Courtesy of one of Nodeta’s own, Ville Lautanala aka Lautis, you can get the Textmate bundles with APIdock goodness for Ruby and Rails from github with just a couple of simple git commands:

Now, the keyboard shortcut

gets you the page for the current word from APIdock.

We have a long track record of sponsoring the university student organizations here in Finland. You can already find our logo from the websites of Computer Science students at Tampere University of Technology, Computer Science students at Helsinki University of Technology, Computer Science students at Helsinki University and the World Championships of Academic Kyykkä.

Next week we’re once again having some great time with our long-time partner, Tietokilta. On February 25th they’re hosting a recruiting event at Helsinki University of Technology (TKK), auditorium TU2.

We have a very tight 30 min. slot, but I’m trying to cover some interesting details about our own Scrum implementation, trying to explain the students why they should be spending their spare time with Ruby on Rails instead of something else, and I’m also going to present a small case study about one of our projects.

Our new home is situated next to a Sibelius Academy building, so pretty much whenever you look out the window, you see young musical talents carrying instrument cases varying in size and shape. I could swear they have a lighter step and a little extra glee compared to the rest of us.

The office itself is shaping up to be a cool place. We’re not even close done decorating the place but we have gathered some basic necessities, like a 46″ LCD TV and Rock Band. We also have a cherry wood meeting table. The new address is Kutomotie 9 C, 00380 Helsinki, Finland.

Specifications and requirements will never be fully understood (Ziv’s law)

Where your mind sees a square, the next guy’s sees a circle. Specifications should be documented but the maker of the specifications has to be fully available for the development team to ask questions and to communicate eye-to-eye. The maker of the specifications, who should be or at least strive to be the best expert of the actual requirements, absolutely cannot be a stranger to the development team.

The users will never know what they want until the system is in production and maybe not even then (Humphrey’s law)

The users may also believe they need something they in actuality have no use for. Users customarily claim they need a feature for a business requirement that can often be covered much better by a very different feature. Users cannot make specifications. Users’ feature requests obviously still need to be heard so the developers can come up with the right feature to cover the business requirement and empower the user to reach his goal. Users’ goals and the software’s business requirements should be crystal clear to the developers and the developers need to show interest towards them.

An interactive system can never be fully specified nor can it ever be fully tested (Wegner’s lemma)

Important to acknowledge, and just as important it is to understand that regardless of the impossibility, full test coverage, automated and manual, should be attempted to achieve. The specification of a software is always a work-in-progress, even after the software itself is ‘completed’. This needs to be accepted and specification documents need to be constantly edited during the process of developing the software.

Our need is somewhat simple: we have several people at the office in Helsinki, and a couple of guys remotely at Espoo or Tampere. We’d like to have a very simple group chat with only the minimum features: chat history and a bell indicating that someone has said something.

Jabber is a nice protocol, but its implementation mostly sucks. We tried Psi because it had received lots of great reviews, but it wasn’t quite what we expected: the user interface looked like my first Java AWT hack and it didn’t even have a way to notify that you’ve received a new message (you know those blinking lights in the taskbar). We also tried some others, but they weren’t any better. Some had nice emoticon sets, though.

Finally we found Spark. It

• has a simple and clean UI
• is written in Java(!)
• supports emoticons(!)
• has incoming message notifications
• shows chat history
• uses a SSL secured connection out-of-the-box
• doesn’t require too much configuration

Basically all we need! Not to mention that the server-side counterpart (Openfire) was really easy to install. Not as good as Skype, but almost there.