Great Interview with Kent Beck

I frequently suggest that software development is a social problem, not a technical problem. Kent explores this idea in this interview, and shows that his thinking on the topic is clearer and deeper than mine!

Design Improvement Workshop

The January EAT workshop was a great success, so we've decided to do it again. I'm pleased to announce that Marty Andrews will be presenting our Design Improvement workshop on March 24. As with our previous workshop, we're limited to 10 places and pricing will be determined using an auction process. You can see the latest bids and access the workshop details on our
wiki.

Roles and titles

In general, I've been opposed to giving people titles on projects, especially titles such as architect, senior designer, or even tester. I've been opposed because I didn't want the titles to lead other people in the team to feel that they didn't have responsibilities in these areas. My preference is that everyone feel responsibility for every aspect of the project - that the team own all the problems.

Of course people who worked with me at IBS are now saying "hang on, there were people with specific titles/reponsibilities", and there were. For each team we identified three different lead roles, each of which required different skills sets. Let's say that they were design-focussed, people-focussed, and process-focussed. The argument was that when everything was working well things were a team responsibility, but if something went pear shaped I, as a manager, wanted to be able to go to one person and say "what's going on?" - I was trying to handle the failure modes. I don't think this worked as well as it should have, mainly because in my time at IBS I spent most of my time working as a recruiter or a fire fighter, and not really much as a manager (and I need to take the blame for that).

So where am I going with this? In the project I'm currently involved with we have titles/relatively strong roles, and I'm enjoying it. We have two people in the BA role, a test manager, an architect, and me (I'm nominally the development lead, but I haven't really figured out what I do that isn't covered by someone else yet, but I'm sure I will eventually). What I'm enjoying is being able to leave certain things to other people - in some sense to be able to flick them over the wall and not think about them at all. Now don't get the impression that we're sitting in bunkers lobbing artillery shells - that's definitely not the case. There's plenty of collaboration, and we definitely help each other out where we can, but we're also willing to trust other people to do their bits, ask questions where they need to, and keep the rest of the team informed (this is helped by all being in a project room and not having cubicles).

Reluctantly, I think I was avoiding titles because I didn't trust everyone on the team. Not in a suspicious, I-have-to-keep-an-eye-on-you kind of way, but at a level I wasn't really aware of. Still, if you're read the first paragraph carefully you can sense the distrust, either towards people's sense of responsibility or towards their technical ability. I think there are certainly times when that's appropriate - if I had a team of grads I don't think I would give them some roles and 'flick things over the wall'. I'd want to assign tasks, monitor them fairly closely and see how things went. I think that my mistake was trying to create a blanket rule, rather than assessing each case individually, which is a manager's job after all.

If I get a chance to do this again, I think I'd prefer to more formally acknowledge roles within the team. If it turns out that one person has all the lead roles, then lets say so openly - it certainly tells us a lot about the current skills mix within the team and how we need to change it. If a team is mature enough to handle having no formal roles, I think they'll be mature enough to handle having formal roles as well.

Weasel words

In the Development Team of the Future (DTOTF, copyright pending), all communication will be clear, open, forthright and well articulated. Sadly, our current development teams still consist of human beings, using writing and the spoken word, so there's not much hope of transitioning to DTOTF any time soon.

Ok, funny intro (at least I hope so), but what's the point? As I've said before, I think that most commercial software development is a social problem, not a technical problem, in the sense that we know we can build something but we need to figure out how to build it as effectively as possible with the team that we have. It's about people, and people are often poor communicators.

One of the things I encounter fairly often is people using what I think of as "weasel words". They're words that hide conflict under the cloak of respectability. When you're hit with a weasel word you need to choose between abdicating your position (often with some new emotional baggage) or moving to open contradiction and conflict. If you're inadvertently flinging weasel words around you may be surprised by the results!

So what are the weasel words? There are lots, but my list starts with these: "just", "must", "have to", "pragmatically", "realistically", "in the real world", "in practice". "Just" diminishes, trivialising the problem; "must" and "have to" beg the question "or what?"; "pragmatically" and "realistically" imply that the other person isn't being either; "in the real world" and "in practice" label the other position as somehow irrelevant. They all have uses in the right context, but they're also frequently disrespectful.

If you find yourself about to use one of these words (and these are just examples, not an exhaustive list) ask yourself if they're necessary, if they're adding value to your expression. Or try living without them for a while and see how things go. My personal quest for the last 18 months has been to eliminate "just" from my vocabulary, or at least minimise my usage. After all, it's just one word - how hard can that be?

Whose problem?

This post takes me back to my earlier theme of developers as change agents, which had a holiday while I was thinking about the EAT workshop. In my earlier posts, I talked about different people perceiving a problem differently, but there's a particular aspect of this that deserves more attention - even if we all see a problem, who's problem is it? To mangle a Mel Brooks quote, "My problem is a tragedy, but yours is a comedy".

The best way I can describe this is to talk about a real life situation. It's not a once off situation, so I don't have to reveal any secrets or worry about offending individuals. This sort of thing happens all the time. It happens when management is unhappy about development for some reason, but are a little vague about the exact problem. "We have to do better!" echoes around the table in closed door meetings around the board table. Perhaps it's the sales folk speaking loudest, "We're not meeting customer expectations" they say. This message gets passed down the hierarchy; "Make it better" is the refrain.

There are a few layers involved, but eventually the message trickles down to the developers on the front line. Their team leader gets the message clearly (sort of), "Job number one is to make the development process better", and heads off to do so. She has a meeting with the team to tell them that she wants them to do better, but they're quite happy with the way they develop software at the moment, thank you very much. They feel they have a pretty good idea of what needs to be done, defect rates are manageable, hours are pretty good, they get to solve some cool technical problems, and they've each got some nifty noise cancelling headphones. The message falls on deaf ears. As time goes by, each of the team leader's initiatives fall by the wayside, and management sees no change at all.

What's happened? Two things that I can see - the people who needed to live the change didn't actually have a problem. They were quite content, thank you very much. The message "management has a problem, you need to suffer some discomfort" doesn't really resonate very well. Although most of use help our neighbours to some extent, our selfish genes respond most fiercely when they're directly threatened, not just indirectly. So one of management's responsibilities (and I use 'management' in a very broad sense) is to make sure that people are motivated to solve personal problems. The simplest way is to translate problems into actual threats - "do this or you're fired", but it only works in the short term and not very well even then. Regardless, as a colleague many years ago said in reference to our startup CEO "I'm not working my ass off to make him rich". He would have worked his ass off to make himself rich though!

The second thing is that even after we all agree a problems exists and we all need to act, we still need to agree on how we'll measure progress. We need a metric, even if it's a very approximate one. Once we have a metric we can be involved in selecting as well as implementing change strategies, because we can try them out and see what worked, possibly in near-real time. Without that, we're reduced to following change implementation orders - not only is this less than fun, it doesn't give everyone the chance to suggest changes, and as well all know, all of us is smarter than any one of us! It's also helpful to have other metrics in place so we have a chance to measure unintended consequences of our changes.

So if you want some other folks to change their behaviour, make it personal and make it measurable. Encourage them to feel your pain, and help you to assuage it, rather than sitting pack entertained by the comedy of your suffering.

First EAT workshop

We ran the first EAT workshop on Saturday, and it went very well. The setup at the venue wasn't perfect, but we think we have a way to set it up better next time. I like an environment with plenty of light, but if anything we had too much yesterday (at least for projection) so we'll try setting up in the ante room, which has blackout curtains, next time.
And the feedback from the participants was very good. Thanks very much to Marty for co-teaching and for providing the data projector, and to Nigel for coming along and adding his expertise. I'm getting used to working on my MacBook, so I'll gradually get better as well. Alec Clews, one of our attendees, has posted his comments.

 

 

Although the examples and discussion for this workshop were in Java, we're now able to offer the workshop in .NET as well. We're unlikely to run the TDD workshop again for a while, but we'll probably run a design improvement workshop in March - contact us if you'd be interested in that.

Testing images

This is a photo I took while travelling in the US.

I hope it posts ok, but no luck so far.

Best Practices - Global or Local?

I came across "Debating the merits of pair programming" this week, and found it irritating. Lest anyone think I'm picking on a particular piece or author, it's just the latest irritant in a series. You could conclude that I was a just a grumpy old man, or that it was very early in the morning and I hadn't gotten my 'day face' on (and there'd be an element of truth to both these thoughts), but let me try to explain myself.

The article presents quotes both supporting and opposing the practice of pair programming, based on personal experience, and some academic work along with critiques o that work. Implicit is that we should be able to somehow look at both sides of the argument and decide which is right and which is wrong. This is the process that someone might be going through if they were trying to decide if pair programming (and by the way, I think it should be called 'pair development', but that's another story) was an industry best practice (you should be able to hear the fanfare in the background).

I have a problem with the idea of industry best practice, and as a corollary with arguments about whether something is industry best practice or not. Fundamentally, it's a problem of context. When we hear about a best practice, what we're usually hearing is someone saying "that worked in my context", where the context may include the developers, the technology, the customers and a plethora of other things. And I love to hear about what worked (or didn't work) in your context - it's the first step to deciding if that might work for me too. The second step is to understand the similiarities and differences between our contexts.

There's another problem with the presentation of the arguments about best practices, especially when there's a bun fight between the relativists and the absolutists. Absolutists are the people looking for industry best practice - one practice to rule them all, one practice to bind them. Relativists are the folks saying "this works sometimes - it worked for me", or "sometimes this doesn't work". When I talk about pairing, or agile development in general, I try to be a relativist. I can say that it has worked for me. I can try to describe the context in which it worked, how it might work in different contexts, and how it might fail in some contexts. Then I come up against an absolutist saying "Pairing doesn't work", "agile development doesn't work". Come on dude, I just told you that I have a proof by existence - it worked for me! Most times I walk away feeling like I've just been called, indirectly and implicitly, a liar. And sometimes I get a bit heated when I feel like that :-)

So here's my proposal. How about we stop looking for industry best practices, and put some more energy into looking at practices which some of us have seen work and figuring out what contexts encourage or discourage these practices. I'm game, how about you?

PS. Apologies for turning off comments in recent posts - I'm using a new tool and I missed setting an option properly.

Test Driven Development workshop notes

I've just finished porting my TDD workshop notes to S5, adding all the code examples, and in general buffing them up for the EAT workshop on Saturday. As usual, I feel that the value of the workshop comes from the dialogue and the interaction, not just from the slides, so I'm happy to make those publicly available, provided you leave the accreditation in place. I'm very interested in any feedback you might have - for example, I've just realised I need to add some Creative Commons licensing to the material, but I'm sure you'll have other things to say!

Do you really have a problem?

In the last post I talked about change capital, a way to think about how many changes you can confidently make and which changes they should be. However, once you've decided where to make your change investments you need to think about how to implement the change.

Most changes are triggered by a perceived problem. However you need to keep in mind that not everyone thinks there is a problem worth solving - they may be quite happy with the current situation, see a different problem, or agree that there is a problem but not think it's worth solving. So your first step is to articulate the problem that you are trying to solve, and then form a consensus around the problem description.

If you're anything like me articulating the problem, even just to yourself, is a very useful exercise. It takes an intuitive understanding and transforms it into something a little more rigorous. It forces you to consider your terminology, establish some consistency, and gives you a chance to check your reasoning. Including quantification of the problem, answering how much this is costing you, can also be very enlightening - sometimes problems are very annoying, but don't actually cost you very much. If that's the case you might want to put more effort into quantifying the annoyance - does that have an economic cost as well? I frequently find that articulating and quantifying the problem forces me to acknowledge that there isn't a significant problem - at least no one worth investing my precious change capital on.

Even after you've convinced yourself that you've got a problem, you need to remember that not everyone else sees the same problem. Some people will probably agree with you, some people will see the same problem but won't think it's worth fixing (especially compared to other problems), and some people won't see any problem at all. And maybe they're right! Maybe there are benefits to the current situation that you haven't seen. Perhaps the benefits accrue to other people, so it's worth bearing the apparent pain. Maybe there's something else that makes the situation fine in a larger context. Software developers frequently believe that their employer should be focussed on optimising software development, but that's often not the most important thing at a corporate level. Maybe it's more important to leverage other staff, even it's detrimental to software development. Try to see things from other people's perspective. You'll know you're doing a reasonable job of this when you can paraphrase their position, echo it back to them, and see them nodding their heads.

It's really only when you get to this point - where you understand the other person's position well enough to describe it accurately to them, and you still believe that there's a problem, that you can start to move towards a solution.

EAT update

With just over a week to run, we've got 10 bids for the Test Driven Development workshop, which is great - this means that bidding will close on midnight Friday. If there's sufficient demand in the next few days I'll look at running this workshop again in February.

EAT details

BarCamp Melbourne

I've read about BarCamp, especially in the blogs of Kathy Sierra and Tara Hunt, so it's good to see that there will be a BarCamp Melbourne in a few months. I hope to be able to attend but I'm not sure about that at the moment, which is why I'm not on the attendee list.

Marty Andrews co-teaching TDD course

I'm pleased to announce that Marty Andrews/ will be teaching the EAT TDD course with me on January 20. Marty has a wealth of experience in agile development, particularly TDD, and it will be valuable for people to get both our perspectives.

So, you want to be a change agent

Most software developers would say that they're not interested in being a change agent, that all they want is to be left alone to do their own work. In one extreme case I had someone tell me that they actively didn't want anyone else to learn how they worked, because that was their individual competitive advantage!

The trouble with this model is that most of us work in teams, even if the team is virtual and distributed, and most teams agree that they need to have consistency or, oh the horror!, standards. That means that if you come up with a new idea, you'll frequently need to convince other people to go along with it, or at least not oppose it, so you need to be a change agent.

The first thing to realise as a change agent is that you can only achieve so much. I think of myself as having a limited amount of change capital, that I need to spend wisely. Some changes have relatively low benefit, but require so little investment that you can and should do them straight away. On the other hand, some changes will have enormous benefits but will be difficult to achieve and may make the team resistant to further changes - this is frequently the case when a manager forces a change on a reluctant team. You need to pay attention to the return on your change capital investment, and investment it appropriately. Another common mistake is to try to make many simultaneous changes, spreading change capital thin and putting all the initiatives at risk. Successful changes generally depend on some minimum investment, and if you're not willing to make that investment you're better off doing nothing at all. Also, although some people are more resistant to change than others, everyone has a limit to the number of changes they can deal with and at some point people are liable to say "enough!". Flexibility is important, but so is stability and predictability and we need to make sure that we have the right balance.

So regardless of the quality of your approach, which I'll talk about in another post, you also need to pay attention to the quantity of change.

Do unto others...

Ron Jeffries enigmatically once said of the XP practices, "they're only rules". What I think he meant was that the practices are a social contract within the team - everyone is expected to abide by the contract, but the team is also free to change the contract when that's appropriate. What we don't want on an XP team is someone unilaterally deciding that the rules don't apply to them. Instead, we want them to raise an issue in a retrospective so the team can hear why some rule isn't working for that person, so that the team can provide advice, support, suggestions, or possibly change the rule.

Developers understand this in the development team context, and also with regard to the rules covering the interactions of the customer management teams with the developers, but I find that they are rather more tolerant of the rules covering the interactions going the other way. In particular, I regularly hear people suggesting that although the customer/project man ager wants to do things a certain way, the developers have decided to do something else "in the interests of the project". What's worse, I feel the urge to do this sort of thing myself!

This pattern appears mainly in two contexts - priorities, and quality. When developers know better, the choose to implement features in an order different to the order requested by the customer, usually because it will be "more efficient". This is fine when everything gets done but if there are some hiccups the customer may be left with features they didn't really need while also missing features they think are more important. While one order may truly be more efficient, that may not be the most important thing from the business perspective and if there's disagreement the final decision on priority rests with the customer.

The equivalent behaviour regarding quality is harder to detect. Sometimes the developers decide to implement lower quality than the customer requested, but more often I see the developers decide to implement higher quality. The context is usually that the developers have two approaches - one can be implemented quickly but hard to change/maintain, and the other is slower to implement but easier to maintain - and the customer prefers the "quick and dirty" approach. In spite of this, the developers decide to implement the "nice" approach. Once again, this is fine if the developers can somehow do it in the same timeframe (overtime perhaps?), but not if it's done at the cost of other features.

Developers need to recognise (intellectually and emotionally) that they are in a service industry, and when push comes to shove they take direction from the business, represented by the customers and management. Developers have a responsibility to present their views and recommendations, with all the supporting information, and then let the business make the business decisions, which include how to spend time/money. When business and development don't agree there are two main reasons - development haven't presented their position in a way that the business understands, in which case the developers need to improve their presentation and influence skills, or business understands the development position quite well but it isn't the most critical factor in the outcome. Sometimes developers don't have the big picture! In neither case the problem that "the business is stupid" or "the business made the wrong decision", though they certainly may make decisions that the developers don't agree with (it undoubtedly happens the other way around as well!).

Of course, none of this applies when people are trying to make decisions that they aren't actually responsible for - in that situation everyone needs to say "thanks very much for your input, but I don't think you're responsible for the final decision". It's common for this to happen with estimation, when the business tells the developers what needs to be done (their responsibility) and how long it's going to take (the developer's responsibility). Sometimes the lines are blurred though - the business is making "draft" decisions, fully expecting them to be reviewed by developers, rather than final decisions - and the situation needs to be clarified.

So if you're a developer who interacts with the business then you have a responsibility to respect the decisions of others, and you'll probably benefit from honing your influence skills as well as your technical skills.

Easy Access Training

In 2007 I'd like to try a few different things, and the first of these is what I'm calling Easy Access Training. Many developers have trouble getting budget and/or time off for training, so I hope to offer one day of training per month on a weekend, and have the price float depending on demand. I expect the rate to come out lower than a commercial course, which seems to be about $600/day (+GST), but I honestly don't know how much lower; probably it will depend on the courses that I offer. There seems to be a lot of interest in test driven development, so I'm starting there, but I'm keen to hear what other courses people woule be interested in on this basis.

What do people think of this idea?

Shu Ha Ri

I'm fascinated to read various posts (mostly blogs) about how "Agile" is bad, sometimes accompanied by a caveat that "agile" is ok. To me any distinction between the two is artificial - from its inception agile development has encouraged adaptation of the method. I see the distinction arising for two reasons - (i) simple misunderstanding, since adaptation isn't included in every description of agile development; and (ii) a mismatch between the question and the answer in shu-ha-ri terms.

In these discussions "Agile" is characterised as a fixed set of practices that must be adhered to, regardless of context or experience. While some people may approach there use of agile this way, I feel this is a misinterpretation of agile development - false doctrine, or if you want to be extreme, heresy!

Adaptation is certainly part of extreme programming, even if this word isn't used. In the second edition Kent and Cindee talk about reflection as on of the XP principles, and using root cause analysis as one of the corollary practices. These are both part of adpating XP to the local context. When the agile manifesto said that "...we have come to value...responding to change over following a plan" I took that to include the process itself! During a recent panel discussion I was asked which agile practice I would introduce first, if I could only introduce one, and my eventual answer was "retrospectives". If you introduce regular, open, honest retrospectives then given enough time and some knowledge of alternatives you'll eventually get the process that you need. And I think that I'd classify that you'd probably get an agile process. Diana Larsen speculated on the same lines.

So if adaptation is an intregral part of agile development, why doesn't everyone understand that. I think the answer is embedded in how we teach and talk about agile. In "Agile Software Development" Alistair Cockburn talks about Shu, Ha, and Ri as three stages in learning. In the Shu stage, the student needs a clear set of instructions or rules, and the faith that these rules will give them the results they need. In the Ha stage, the student can automatically apply the rules, but has begun to understand that the rules don't always give the best results. They start to look for these exceptional cases and apply different rules in these contexts. They gain flexibility but, and this is the important part, they need to be fluent in the basic rules first. Kent had something similar in mind when he suggested renaming the XP practices etudes - things that you practiced for fluency, but that you didn't necessarily apply rigorously every single day. In the Ri stage the student has moved beyond rules, but that's beyond the context of this discussion!

Most people, and I don't think this is restricted to software development, want to skip the Shu stage and move straight to Ha. They want to hear that the rules don't apply all the time and then decide when and when not to apply them. I hear this all the time - we want to do risk driven pairing, we'll only write tests for the complex parts of the code, things like that. The inconvenient truth is that this approach doesn't work. Until you've personally applied the practices in both appropriate and inappropriate situation you're just not in a position to make those decisions. You'll apply the practice where you want to apply the practice, but that won't be the same as where you should apply the practice.

So when I'm introducing people to agile practices, I'll say that you pair all the time, that you write unit tests for every method, that you should have 100% code coverage from your unit tests. I know these things aren't true, and it's not what I would say to someone who already had some experience with the practices, but they are very useful first approximations. They are Shu statements. People experienced with software development, but not with agile practices, can sense that these aren't complete answers - if they think that this is all there is to agile, that there isn't more sophistication futher down the track, then they are liable to reject agile as snake oil. It's easy for them to get this impression from introductory presentations, since it's hard to come up with material suitable for everyone in the audience, and it's even easier if the presenter hasn't moved past Shu themselves. We teach students in groups of similar ability for a reason!

In an ideal world this distinction between "Agile" and "agile" would disappear, but I'm not hopeful. Instead I thiink we'll see two things happen - some people will create branded, proprietary agile methods that aren't subject to community reinterpretation, and other people will stop talking about 'agile' altogether and just 'do stuff that works for them'. Time will tell.

Photos from Bangalore

I know that before I went to Bangalore I was really interested in what the physical environment would be like, so I want to share these photos from the business side of things (the more general side will need to wait until more photos get uploaded). If you'd like to hear more about our personal life in India, have a look at Amanda's blog.

The office building that I was working in was part of an IT campus, right next door to the golf course, that also included IBM and Microsoft (Microsoft is down where the bridge is in the photo). You might think from these pictures that it was a very western environment, and it certainly was inside the buildings , but outside, where building was still in progress, the contrasts became more apparent. The roads were kept clean by people with horsehair brooms who came out at night (the brooms looked just like the one that our maid used, with short handles that meant that you needed to bend over to use them), and when you look at the picture of the building site (right next to our office), note how many people and few machines you see. Construction here is very labour intensive.

 
 

Bangalore was a study in contrasts. The house next door to our apartment was palatial (and apparently occupied by late teen boys who wouldn't have been out of place cruising Chapel St, doof doof music blaring), but two doors further up the street the garbage pile was being browsed by cows and goats, and the ironing was being done by the side of the road, with charcoal powered irons. My office had a very pleasant cafeteria, but less than a kilometre away this is where breakfast was being served (sorry for the blurring, but the car was moving!).

 


 
 

Traffic was roughly equivalent to peak hour on Hoddle St in Melbourne, but a lot more chaotic. Horns are used to indicate "I'm here", since lanes, indicators and overtaking are all rather free form. Auto rickshaws fill the gaps between the cars, motorcycles fill the gaps between the autos, and there are usually some bicycles thrown in just for good measure. Rapid construction leaves the footpaths a bit of a mess, so there are frequently pedestrians on the roads, though it doesn't making crossing the road any easier.

Agile assignment in Bangalore

As some of you will already know, I've just finished a three month engagement for a Wall St bank, helping them refine their use of agile development practices. I'm going to refrain from comment on the specifics of the engagement, and instead focus on the things that I learned myself.

1) Indian programmers are just the same as western programmers - same strengths, same weaknesses. Some are good, some are not so good, some are quiet, some are extroverted. I've know this intellectually, but now I know it emotionally as well.

2) Recruitment in Bangalore is just as difficult as it is anywhere else. It might even be harder, since in Bangalore you're competing directly against Microsoft and IBM (who were on the same campus I was on), as well as Google. Most of us don't face that level of competition in our local regions. And sure there are lots more graduates in India, but if you want people with 5 or 10 years experience the ratios are less favourable. Plus Infosys wants thirty thousand new programmers in 2007 (anecdotally), and that might include just a few of the good ones ;-)

3) There are cultural differences, but they are swamped by the twin tyrannies of distance and time zones. Remote offices are dealing with comparative strangers, and between the USA and India there are only a few hours of effective overlap in a day (it's a bit better between India and Australia). Communication over email and phone just isn't the same - you need lots of face to face experience to overcome this.

4) For distributed development you need people who are willing and able to travel. Include that in your profiles.

5) You can't effect rapid change in a distributed group, especially if there isn't a strong consensus to begin with. And forming that consensus takes a long time. The Forming-Storming-Norming-Performing cycle takes a lot longer for a distributed team - there are plenty of opportunities for miscommunication, and it takes a lot longer to sort the miscommunications out.

6) Everyone's ability to influence is diminished by distance. This was certainly a personal challenge, and I don't feel that I really rose to the occassion.

That's enough to get the things that are distracting me out of my head so that I can focus on some pressing work, but I'm sure that more things will occur to me later. When I get a chance to right a blog while I'm online I'll include some photos so people can get a better sense of the work environment here in Bangalore.

Personal Declaration of Independence

I can't say it any better than this, though I wish I could.