Now that I am moving to Amsterdam, I need a new plan. I have learned so very much since the last time I wrote out a plan and I am both excited and terrified.

Previously I was very much against freelance/agency type work due to my frustrating experiences in this field. In the last year I have learned that most of these frustrations weren’t really problems with freelancing or working for an agency, but more a problem with my own experience and abilities. I feel that most of these things will no longer be as frustrating and will only get better as time goes on.

Much of what I have learned has become part of my own theory about how software development should be handled. People throw around words like XP and Agile, but there are some important aspects of these practices that I will be using in my own development:

• Frequent feedback from stakeholders (or customers/clients/whatever-you-want-to-call-them) is absolutely necessary
• Code testing is very important to prevent regressions and give you the ability to safely refactor as necessary as things change and/or requirements become more clear.
• XP is not an excuse to just hack and slash and hope everything works out. Concern must be given to application architecture and design as the project evolves.
• Estimating the time necessary to complete each requirement is quite helpful for discussions involving deadlines, scope, cost, and priorities (this and your basic product management triangle)

Other important things I have learned come from working on 2 fairly-large projects that have been running for a long time. WhoIsNear? and AreYouInterested? are both long-term projects that have had several people touch them. Requirements changed, new features came, old features were removed and designs were changed sometimes frequently. Projects I worked on in Denver only ran for about as long as it took to initially build them for the most part. Many did not get updated after their release while some did not even see the light of day at all. Projects like WhoIsNear? and AreYouInterested? helped to illuminate how important proper XP-like practices are, not just to get the initial project built, but to allow for a healthy project that can continue to be stable and effective years later.

In short-term projects it can be tempting to agree to some short-term wins even it results in a large pile of technical debt. Who cares if you’re only working on the project for a few weeks eh? Effective projects need to be built in such a way that technical debt you acquire initially can be more easily paid off in the future when you can. It’s cool to make use of someone else’s library or framework when necessary, but keep in mind that their code now counts as a part of your total inventory. That giant framework you’re only going to use a part of? That’s all your code now. It’s all part of your project. Either you need to be willing to accept this code, contribute to it, and get involved in the inner workings or your project needs to be designed in such a way that that library/framework can be replaced later when you have the opportunity.

A classic example for iOS developers comes from the three20 framework. When it was initially released, many developers jumped to use it in their new projects without truly owning the code inside. Months after its release, all of those initial developers were denied entrance to the App Store because of code in three20 (undocumented code for the win). They did not own the code and become involved in the inner workings and got slapped in return. Three20 was also such a substantial framework that it became very difficult for developers to remove the code from their apps even if they wanted to. To this day, there are still plenty of active projects that have been using three20 for the last 2-3 years because no one had the time to take on the monumental task of removing three20 from their applications.

So with all of this, I will be taking on freelance projects in Amsterdam while I work on some of my own ideas. I’m looking forward to using these smallish projects as an opportunity to try different types of architecture and design while also perfecting my business/dev-process methods. Turns out making awesome code is way more than simply knowing how to do some nifty things in code. There’s a whole world to it beyond just going clickety-clack on your keyboard and expecting amazingness to come about. Should be fun :)