Øredev 2010 - Day 5 - Tim Jeanes

Omg omg omg! It's Nolan Bushnell, the founder of Atari!

Session 1 - The Technical Debt Trap - Michael "Doc" Norton

The term technical debt refers to problems or bad code that you decide you'll fix later but never really do. A little debt early on speeds development. It's fine so long as you pay the debt back soon, but left unattended is like accumulating interest on that debt as the bad code compounds.

Though developers generally hate technical debt in any form, it can be a good thing provided it's managed correctly. It allows for rapid delivery to elicit quick feedback and correct the design.

This isn't an excuse to write code poorly now: if it's debt, you intend to pay it back. You can only do this if you write the code in a way that you can refactor it into a better shape later on. Dirty code is to technical debt as the pawn broker is to financial debt.

If you don't have a plan to get out of the debt you're in, you don't have technical debt, you just have a mess; cruft.

Much technical debt can be avoided; however, much is unintentional. When you look back at your old code you find it full of cruft that needs cleaning up. Unfortunately, how you got into debt doesn't excuse you paying it back.

A lot of handling technical debt comes down to handling expectations. We know we're going to incur it, so we need to balance that against the pressure for speed over quality. Technical debt then compounds as mess is added to mess in order to maintain velocity. Adding clean-up sprints to the dev cycle generally doesn't work. Studies show that the cruft just re-accumulates rapidly afterwards. A better pattern is to clean continuously: try to leave the code cleaner than you found it.

Session 2 - C#'s Greatest Mistakes - Jon Skeet

We love C#, so it's great to hear such an expert on the subject (and someone who loves it even more passionately) talking about what's wrong with it.

This was almost entirely a code-based session, so it's hard to write about without duplicating reams of code.

Ah well.

Session 3 - Fostering Software Craftsmanship - Cory Foy

We saw a few case studies of people who have opted out of the traditional software development career structure to follow instead a more journeyman-type model whereby they spend their time travelling and pairing with people and exchanging ideas.

Historically, software development became increasingly prescriptive from the 1960s onwards. The Agile Manifesto was a massive backlash against this that reoriented programmers' values much more towards being flexible and adaptive. Though the older models were more heavyweight, they did lead to stricter practices.

Empowerment can be defined as sharing information with everyone, creating autonomy through boundaries, and replacing the old hierarchy with self-managed teams.Agile practices often fail when management still works from a carrot-and-stick way of rewarding goals or punishing failures. If we're to work as a team, individual rewards and bonuses are always counter-productive.

Session 4 - Real Options - Olav Maassen

Similar to buying stock options - by purchasing an option now to buy later at a price set now - almost everything can be considered an option by weighing up the benefit against the loss incurred by choosing against the option, whether than cost/ benefit is financial, emotional or moral.

Options have value; options expire; never commit early unless you know why.

Similarly, buying a plane ticket far in advance is much cheaper than buying it at the last moment. The earlier ticket is non-refundable, but the flight is not mandatory: all you've bought is the option to fly then. If you choose not to take the option, you've not lost much.

Being uncertain can often be better than being wrong.

In agile practices, pair programming provides options: two people think of different ways of tackling the same problem.

Scrum backlog provides options: every idea is there. Action is postponed until the time the priority decision needs to be made.

Session 5 - True Tales of the App Store - Making iPhone Apps for (Fun and) Profit - Jack Nutting

Developing apps for any platform's app store let's you skip most of the hard work of selling software - you have no inventory management, payment handling or shipping. However, this has led to a crowded market, so marketing becomes a bigger priority. You can basically run your own software firm from your desk, but marketing isn't something developers normally do that well.

The app store has changed the public's relationship to software - they buy and discard software much more freely now, many of them for the first time.

The lower the price of your app, the more downloads you'll get, but also the more haters you'll get - more low ratings and more negative comments.

The app store is a hit-driven economy: the better you're doing, the better you continue to do. If you're outside the top fifty or so, you can sink without trace. If there were ever a bug in the app store that showed a non-entity app as number one, within a day it would probably actually be number one.

Releasing a "lite" version of your app can help to gain publicity, but Apple have strict rules against non-functional buttons that only tell the user to buy the full version to activate that feature.

Other than making money directly through the app store, advertising can be a revenue stream, but it's generally a slow one. For games, in-game purchasing of additional levels can a;also work.

An alternative is to build free apps that help people use your business: the app doesn't make any money in itself, but acts as direct or indirect advertising to the existing business model.

Before you even write a line of code, be smart: don't reinvent the wheel. Or if you must, at least add something new.

Making an app that people will keep using, then even if they don't spend any more money in it, it lengthens its word-of-mouth viral capacity. People love stories - even (or perhaps especially) stupid ones. This gives you the excuse to continue to add new content. You can add variety by adding mini games (even in games).

Make your app as simple as possible, but not simpler. Unless it's a game or a book, people will want to be in and out of your app as quickly as possible. Eliminate settings wherever possible; if you can make a choice on behalf of your users, do so.