Outsourcing is not only about ODCs
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.
Unexpected implications of computing
Did it ever occurred to you that one particular idea or technology which is pretty concrete and utilitarian can suddenly reveal unexpected and beautiful applications? Sometimes one even would not think that any technology should be applied at all. This is what really amazes me about computing and will never our profession completely mechanistic.
Through ACM TechNews I've read article Virtual Extras. It subtitle did not promise anything "extra" at all. Just serious advances in development of animated mob scenes:
Giving each member of a digital crowd its own personality could make animated mob scenes more realistic.
But when you read further you come across
... software even manages to capture the way in which two crowds of people, moving through a narrow corridor, naturally form two opposing lanes.
With this things start getting interesting. And finally you get
Beyond movies and games, there's increasing interest in using crowd simulation to help conduct fire and disaster assessments of large public spaces...
Isn't it amazing that purely entertaining-targeted research suddenly finds such non-trivial application. Do you feel the same after reading the article?
Functional programming returns
Long ago I took a huge interest in functional programming languages and their theory underpinnings. My master's thesis also was related to functional programming. But later I went into full-time position in industry and cruel nature of business started putting its real-world limitations on technology selection for software projects...
In recent issue of local IT magazine a second in a series article on functional programming was published and I really enjoyed going back to the times when I lived in this world. So if you happen to know Russian and know something about functional programming or, probably, think you know everything about programming, but never heard the words Haskell, higher-order function or strong typing, I encourage you check out these articles:
Project management of future
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.
Do we unnecessarily complicate things?
Today I was thinking of establishing a clear versioning system for one of the projects I'm managing. Usually I start such kind of activities with research of past experience on the Internet. I did so this time and found a bunch of interesting links. Here are some to name a few:
- Software Versioning article at Wikipedia provides good overview version numbering schemes adopted for different products. Also interesting is discussion of political implications of software version numbers.
- Eclipse Version Numbering discusses the topic as applied to Eclipse platform. It nevertheless gives a good reasoning behind one particular scheme and show what software engineer needs to think about with regard to versions and configuration management approach.
- Which Version of Version? Also describes one particular versioning scheme.
- What's In a Version Number, Anyway? Raises usability concerns of version numbers for mere mortal software users. Microsoft Office versioning approach is also discussed here. Additional point of interest is comments to this post.
- Decoding Office Build Numbers. Description version numbering scheme currently used by Microsoft Office products.
I generally agree with Jeff's ideas that versioning often is overly complicated and confusing for end-users and even sometimes for developers themselves. I think developers' love for "magic" numbers and words comes from natural human's desire to differentiate from other humans. In this case developers differentiate by possessing knowledge about all those tricky version numbering approaches which are hardly comprehensible by mere mortals.
Albert Einstain once said "Things should be made as simple as possible -- but no simpler." I believe we should follow his advice in giving versions to our products.
Things to watch in 2008
What would you think is in the list of 80 things to watch in 2008 published by JWT (the United States largest and world's fourth largest advertising agency)? Yes, it is "Outsourcing to Ukraine (and other Eastern European countries)" (look for item 50 in the list)! Working in Ukraine's IT industry I'm just in position to watch that.
The list in general is quite interesting. Be sure to read it all.
On outsourcing. Again
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.
Selling the design
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.
Telling your stories
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.
Big questions - small answers
Today I found some new answers to questions I was asking and was asked. Here they are:
Q: How do you define a "small" and "large" project?A: Small project is project with homogeneous development environments. In large project the environment is heterogeneous. For instance, C# + SQL is homogeneous environment, while Java + Flash, or .NET + Perl are heterogeneous.
This definition correlates to size of the project measured, say, in functional points. When project size grows more supporting utilities, services or components are required which are often implemented with technology very different from core product platform.
Q: How do you define "mature" developer?
A: Mature developer, I would even say, engineer understands that technology is not a goal. The goal is business value, technology is only a means.
Have you ever been told that new version of XYZ came out yesterday and we need to migrate to this new version as soon as possible? Great engineer is the one who finds best technical solutions with the imperfect tools he's got.
Q: Who is a manager?
A: A manager is a person who understands trade-offs.
Manager understands what choices mean, what are the implications and why one of several alternatives is chosen. Good managers see choices where others can only see a straight way.