1997

As the end of the year is drawing closer, it is time for some reflection. Let me take you back not just one year, but twenty. At the end of 1997, I found myself at the epicentre of the Asian financial crisis, also known as the Tom Yum Goong crisis, which originated in Thailand and followed the devaluation of the Thai Baht earlier that year. I was in charge of a startup company in Bangkok providing software services to local companies in Thailand. Within just a few months, almost all of our clients either became insolvent or withdrew from their contracts. As might be imagined, this presented quite a challenge for a fledgling startup business. At times, I was worried that I would not be able to pay out salaries to our employees at the end of the month. Fortunately, it never came to that. Due to providential circumstances that allowed me to bridge the worst periods with loans and advance payments, my company avoided joining the increasing numbers of Asian crisis casualties.

 

However, by the end of that year it became clear that the economic slump was of a more permanent nature and that I needed to restructure the company’s business if I wanted it to have a future. Fortunately, there were two things on our side. The Internet was taking over the world rapidly, creating a sudden demand for web services and web-savvy software and at the same time making remote collaboration more practical. Secondly, the company was small and agile, which meant it could adapt to these changes quickly. Thus I put all eggs in one basket and began to restructure the business as web development company. We moved away from the more traditional enterprise software market and embraced then emerging web technologies. I hired two graphic designers and our programmers learned HTML, Perl and JavaScript.

Perhaps more importantly, we started to look abroad for new business, particularly in Germany and the USA. The idea was not just to offer a new type of service, but also to offer it to a new type of clientèle, namely one that is located offshore in different places around the world. Within six months, between 80% and 90% of the company’s revenue was derived from web services, particularly from creating web sites for small and medium enterprises. As our portfolio was growing, we established a reputation and were able to attract bigger clients. By mid 1998 we merged with a small local web development company and thus cemented the path taken. The transition from working locally to working globally took a bit longer, however, as it turned out to be more challenging. Cooperating remotely with international clients presented not only technical and organisational difficulties. There are also a cultural barriers between Thailand, Europe and America that need to be taken into account.

Among the many cultural differences one finds besides language, communication style, business practices, social habits, the degree of risk acceptance, awareness of hierarchies just to name a few. Efficient communication turned out to be the most challenging issue. It became necessary to put project leads in charge who are not only fluent in English, but who also have some understanding of the way things are done outside of Thailand. In most cases, this adds a layer of management and administration. For example, requirement and specification documents have to be translated. Customer expectations must be communicated clearly to those who execute the work. By 1999, all of our major clients were international. It took almost two years to complete the transition from a local consulting business to an offshore services company. In the end, my company had escaped the snag of the Asian crisis. Perhaps more importantly, it had reinvented itself. The newly defined direction laid the foundation for years to come.

The Agile Samurai

The Agile Samurai

The Agile Samurai
by Jonathan Rasmusson
1st edition, 280 pages
Pragmatic Bookshelf

Book Review

Over the last ten years, I've been working with teams with different degrees of commitment to the agile process, ranging from non-existing to quite strong. I was looking for a text that summarises agile methodology to help me formalise and articulate my own experiences, and of course to enhance my knowledge of some of the finer points of agile practices. I have to admit that this book did not meet my expectations. The first eighty pages up to chapter six are mostly about project inception and read like a prolonged introduction. From chapter six onwards, the author finally comes to the point and discusses the core concepts of agile processes, so the book does get better with increasing page numbers. Unfortunately, Scrum isn't discussed at all, instead Kanban is introduced in chapter eight. The discussion of typical technical processes, such as refactoring, TDD, and continuous integration is compacted into several brief chapters at the end of the book.

The writing style is very informal; the author uses a conversational tone throughout the book. Almost every page contains illustrations, which makes it an easy and quick read. The style of the book is comparable to the Head First books. It left me with the the impression that I sat in an all-day meeting where someone said a lot of intelligent things to which everyone else agreed. Unfortunately, not many of these things seemed radically new or thought-provoking, so I fear I won't remember many of them next month. Of course, this may be entirely my own fault. I prefer a more formal, concise, old-school language. I also prefer dense and meaty text books with lots of diagrams, numbers and formulas. In return, I can dispense with stick figures, pictograms, and even with Master Sensei (a guru character used in the book). I feel that a lot of the deeper and more complex issues of agile project management have simply been left out.

To be fair, it must be mentioned that I probably do not fall into the target group for which this book was written. It is more appropriate as an introductory text for people who are new to agile project management, or even new to the entire business of project management. Think "trial lesson" and "starter course".

Oracle buys Sun

Generally I don’t comment on events in the business world, since this blog is about web development and software engineering. However, the acquisition of Sun by Oracle, which was officially announced yesterday, is so large-scale that it is likely to affect the engineering halls in many subtle ways. Quick facts: the deal is $ 7.4 billion worth, it was unanimously approved by Sun’s board and it will be closed this summer. Sun and Oracle published identical press statements yesterday which sing the praises of the acquisition.

I am not sure whether this is good news. While it was apparent to most observers that Sun was past its zenith, one wonders what will happen to its employees and its innovations. Granted, an acquisition by IBM would have tipped the scales even more in favour of Big Blue’s dominance in the enterprise market and that might have distorted competition. But one may doubt that Oracle will uphold Sun’s commitment to the open source community. Sun’s market was driven by innovation and open source products. Oracle’s market is clearly not.

In particular, one wonders what will happen to MySQL which was bought by Sun earlier last year and which competes with Oracle’s core products. Pessimistic observers have already called it MyToast. Will Larry Ellison allow MySQL to compete in the enterprise market? Probably not. Other items in Sun’s portfolio once considered crown jewels, such Solaris and Glassfish, might also be on the endangered list. But that is pure speculation at this moment. Whether this acquisition will turn out to be a good move for Oracle is currently debated by the industry experts. Whether it is a positive turn for open source community may be reasonably doubted. Time will show.

Scala Hits Top 30

The Scala programming language has for the first time hit the top 30 of the TIOBE index in April this year. The TIOBE index measures the popularity of programming languages by counting searches for the respective programming language in the most popular search engines. In April 2009, Scala searches were tracked at 0.237% of all searches which places it at rank 28. This means it is already ahead of other functional languages such as Haskell, Erlang amd Caml. The TIOBE track record is an indicator of Scala’s growing popularity. Scala entered the TIOBE index in early 2008 and appeared in the Top 50 for the first time in the fourth quarter of 2008.

Between suits and nerds

Everybody knows the balloonist joke that epitomises the eternally rocky relationship between I.T. (also known as geeks, nerds, techies, code wrestlers, bit whippers, keyboard pounders) and management (also known as “the suits”). For those who don’t know the joke I have attached it at the end of this article. In Dilbert’s world, the nerds are typically bigheaded, odd, socially inept, and devoid of a sense of humour (or at least nobody understands their humour), whereas the “suits” are typically pushy, mean, overbearing, and of course completely clueless. I am sure that we have all seen one or another Dilbert stereotype incarnation in the real world. Perhaps we are also aware of the adjunctive differences in the Myer-Briggs typology and such. But this article is not about nerds versus suits. It is about a curious profession called project management. Project managers are a sort of hybrid “geek suits”. Technically they are engineers, but they are in the same category as administrators. Organisations that develop computer systems professionally, or organisations large enough to maintain their internal R&D department often have a need for individuals with such qualifications.

What exactly does a project manager do? From the perspective of the nerd department, the project manager (PM) is a “suit” with knowledge. Unlike top management, the project manager cannot be duped easily with buzzwords and technical acronyms. The PM keeps an eye on the work requirements and duties of the engineering staff, so the PM is often viewed with suspicion. The terms “galley whip” and “nerd nanny” come to mind. From the perspective of the “suits”, the PM is simply a sort of Über-nerd who is put in charge of a bunch of regular nerds, so that they don’t play computer games all day and deliver meaningful work results which resemble specifications. Additionally, a project manager comes in handy as a scapegoat when the project flops. This means that the project manager’s primary role is performing a tightrope walk between management and engineering. Since the PM is neither liked by any side, and since the PM is the first to be blamed for any shortcomings in the project, the project manager needs to have a high tolerance for suffering. On the positive side, the PM usually commands a high salary well above regular-nerd level.

Of course, things are different in a small company. Small companies don’t have the hierarchies and corporate politics one finds in large organisations. I have worked in the role of CTO and project manager in my own company for ten years. When I started, there were only 4 people and we built up a team of 16, of whom 12 worked in technical positions. It wasn’t much of a tightrope walk for me, because there wasn’t any superordinate management. Convenient, you might think and you are right. I tended to see project management as orchestration and therefore -to keep with the music metaphor- the project manager as a conductor. Neither conducting nor project management are hard sciences. Sure, there are techniques, best practices, and (to use one of the PM’s favourite terms) “methodologies”, but there is no recipe or “silver bullet” (another favourite) to make an orchestra perform brilliantly or to produce excellent computer systems on time and on budget. – So what really is project management?

Wikipedia offers a reasonable definition of project management, but unfortunately it just scratches the surface. The function of a project manager cannot be summarised easily. It is indeed a bit perplexing. The PM rarely participates directly in the production of a system, but is expected to understand every part of it. The PM also needs a deep understanding of execution, but does not execute. Like a conductor must understand the instruments, the scores, and the orchestra, the project manager must understand the technology, the specifications, and the capabilities of his team. He might be exempted from having to wear a tie, but he still needs management skills, in particular communication and motivation skills. Although the field of project management is fairly well defined, the actual techniques and methods differ widely depending on industry, culture, and deployed technologies. No particular skill set works in every situation. One of the best recognised organisations that certifies project managers, the Project Management Institution (PMI) therefore covers only basic management skills in their programs. Does this make the PM a “suit” after all? Well yes, but a nerdy one.

 

And here is the joke:

A hot-air balloonist had drifted off course. When he saw a man on the ground he yelled, “Excuse me, can you tell me where I am?”

“Sure”, said the man. “You are in a balloon.”

“Ah, you must work in I.T.,” the balloonist said.

“How did you know?”

“What you told me is technically correct, but of no use at all.”

“And you must work in management,” the man on the ground retorted.

“That’s right.”

“Figures. You don’t know where you are or where you’re going, but you expect me to help. And you’re in the same position you were in before we met, only now it’s my fault”.