Leo Babauta of Zenhabits describes an interesting concept of pigeonholes in interpersonal communication. My personal experience with this suggests that there is always a hassle that stops people from changing for better. Changing for worse usually happens gradually and unconsciously; and when it is conscious (I can not imagine that, but still) you do not care how others perceive you anyway. Changing for better is in most cases a conscious action and involves a great deal of thinking. Here perception of you by others is important.

Unfortunately, often the first reaction to change in you (or in other words you trying to change a pigeonhole) is suspicion. Why would he wonna do that? Is he going to fool us? And you really need to get through this. One of the better options to do that is to get an alignment of a person you trust. With her belief in your new personality and her support it would be easier to convince rest of the world that it is not about them being fooled, but about you becoming better.

Beware that when you want to move something from one pigeonhole to another you need to pick it up first.

Many years ago when I was at school I was serious about orienting. Once I even was 3rd in national championship. And the trainer always told us "Stability is a sign of mastery". No matter how fast you are on the training you've got to be able to repeat this result in real competitions throughout a season. Also you've got to be proficient with basics of the sport - you can not succeed without consistent results in long-distance racing. And no one in your team is going to take you seriously if you say "This will be my showtime" when your results record is like a wave of highs and deeps. When you are developing a software product you, first of all, run against your competitors on quality. And you will only be able to succeed if you can deliver consistent level of quality. Consistent external (perceivable by your users and customers) quality can only be achieved through stable internal (visible to your staff) quality. Of course, miracles sometimes happen and you can get a decent quality product without maintaining internal quality metrics. But you will never able to sustain this quality before you get internal processes and practices right. (By the way, if you think you've managed to do that, drop me a note -  I would love to know how it worked).

Jason Yip got a great quote on this from The Practice of Programming:

Consistency leads to better programs.  If formatting varies unpredictably, or a loop over an array runs uphill this time and downhill the next, or strings are copied with strcpy here and a for loop there, the variations make it harder to see what's really going on.  But if the same computation is done the same way every time it appears, any variation suggests a genuine difference, one worth noting.

Master your skill and deliver quality everyday even if no one notices that. And once you need to do your best you'll do that as you always do.

... someone has to be using it. Guys from 37signals got it right:

It feels great to be done with something on the programming side and then feeling free to move on to the next thing. We all do that at times. But it’s not really real until our users are able to enjoy it.

Way too often more attention is paid to the process of creating something than to the actual value of the result for others. The truth is that value is realized not at the moment the product is created and the more so not in the process of creation. Value is realized when the product is delivered and used.

Declaration of Interdependence which is going (hopefully) to drive the way we manage projects puts essential focus on delivery of value:

We increase return on investment by making continuous flow of value our focus

Like quality is everyone's business every day, so delivery of value should be.

Software developers like being "agile", whatever this means. They say being "agile" liberates their creativity and lets positive energies of the Universe flow through them to the code to (hopefully) solve customer's problems. They are committed to using all the practices that e.g. XP suggests, but it generally would be better if somebody else writes unit tests. For me definition of "agile" changed forever when I first watched David Anderson's interview "Writing Agile Software" and read his book Agile Management for Software Engineering. All the other books on "agile" topics I've come across focus of how freaking cool it is to use agile to develop software, of course, from the point of view of developers. And you are a, hm-m-m, short-sighted conservator if you want developers to do development with, say, RUP.

"Agile" does not equal to "Say no to BDUF and documents". David in his book explains what is agile and why it is better for clients and their businesses.

Jurgen Apello in his blog provides a review for this book, but focuses mostly on the form, not the meaning. True, the book is not fun and makes you think, but it is gratifying when you finally get the clue. Again, this book is not about the fun you get working on agile project, it is about why agile works in business landscape.

Anyway, if you want to better understand the book, my suggestion is to watch the video first.

Via Presentation Zen I recently found out that videos from Startup school '08 are now available at Omnisio. If you like to hear smart people talking about interesting ideas then you should probably check them out. So far I've watched David Heinemeier Hansson's presentation and Paul Graham's one and I should say I like what I see. Tim Bauer has published his notes from these presentations. You may also find them useful:

• David Heinemeier Hansson: Forget Free, Go Fee
• Paul Graham (YCombinator): Unleash the Cockroach In You

And, by the way, I agree with Paul that you should not drop out of college in order to just start making money.

Many articles on the topic of outsourcing to Eastern Europe, Ukraine, Russia etc. discuss establishing offshore development centers (ODC, unfortunately no comprehensible definition in Wikipedia). But ODC is not the only and for sure not the single universally effective means of offshore outsourcing.

For example, Outsourcing to Ukraine: Why the US$246 Million Industry Is Expanding to the Provinces provides a good analysis of Ukraine's outsourcing industry geography and other internal drivers:

... [Ukraine] has a large pool of highly educated people and the geographical location was convenient. He found the English competency of his employees was better than in China. And the cultural differences were less noticeable compared to those in India and China.

Many of the challenges described in this article and associated risks can be transferred to outsourcing vendor. This is a great idea for companies which do not have software development as their core competency or smaller companies for which it is not feasible to establish ODC. In this case vendor will provide you with certain level of service and take care of all the risks.

How much more can we outsource? gives a good notion of difference between 'outsourcing' and 'offshoring'. And when you contract offshore outsourcing provider such as SoftServe, you will be able to realize offshore benefits without all the burden of managing a branch in another country.

If you follow advances in agile project management you've heard of Declaration of Interdependence (compare it to Agile Manifesto). This Declaration reflects progress of software development from romantic profession of "ugh, this guy can command a computer" towards pragmatic business and established engineering discipline. We no longer can afford doing technology for pure technology sake. Economics comes into play. Surprising thing to me is that since I first learned about DOI I haven't heard of it at all. Despite of being a well thought out piece of knowledge it did not get referenced too much. Mike Griffiths provides a good analysis why this may be so.

Mike references the Made to Stick book which happens to be on my bookshelf also. Looks like I need to push it up on my reading list.

Quite a time ago I wrote about "good" outsourcing which is focused on business value delivery rather than on potential cost savings. Even when we speak about outsourcing to offshore locations costs should not be the major factor influencing the decision. What is more important is the ability of the vendor to deliver on promise. Deliver business value on schedule and within budget. If you read Outsourcing Handbook by Construx you will see that cost savings are not listed among 10 common reasons to outsource a project. Although the study did not explicitly focus on offshore outsourcing I believe the results would not much different. Outsourcing is there to help you leverage your own potential by developing your core competencies. Budget savings should be seen as vendor's ability to master his software engineering approaches to achieve higher efficiency than with in-house development team.

Yesterday driving the city I noticed a big board which invited to buy a flat in a house. The interesting fact about this sell was that the is not built yet and the construction has not even started! But they have a fully visualized 3D-model of the house which you can use to imagine how your new dwelling will look like. I doubt that anyone has any apprehensions that real estate company can and will build the house so that it will look exactly like it looks in the model (i.e. in the project). So what they are essentially doing they are selling a design, not a completely usable product. Can you imagine anyone selling a design of a software product to end-users? Or even better, can you imagine anyone buying that?

Unfortunately, in software industry we do not get that level of credibility like they do in civil engineering industry. But I do believe it is possible with of software engineering profession. If you agree with me the Professional Software Development by Steve McConnell will reassure you. If you do not agree this book will, probably, persuade you that it is possible.

Just a few moments ago I've finished reading the "The Deadline: A Novel About Project Management" by Tom DeMarco. It was an interesting read. Although I have to admit that fiction side was somewhat weak, from educational standpoint book is great. The idea about Mr. Tompkins' is just brilliant. You can review his notes in Excerpts from The Deadline. In this book there is a wonderful chapter (Roll of the Catalyst) about importance of informal education. motivation, inspiration (what not) by telling different stories. In about the time I was reading this chapter I saw the post Tell New Stories to Make the Lean Change. And I agree that appropriate story in a right moment is a very powerful tool in getting things done the right way. Stories teach you something without boredom of abstract theoretical knowledge and produce much more sustainable result.