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”.

Ajax development with Dojo

Almost exactly 11 years ago I made my first steps into the world of web programming by writing a web-based address book in Perl. The idea then was to teach myself how to create dynamic web pages. It took me about a week to learn Perl and to write this small app. Last week I have repeated the exercise, albeit on a different level. I wanted to teach myself the fundamentals of the Dojo toolkit, Dojo Ajax, and some of the more advanced MySQL features. It was also a welcome break from a longer period of Java work. I used a PHP5 OOP framework for the server side scripting. Mind you, not one of the super-bloated third party frameworks that can do everything from spitting out Pi to the thousandth digit to calculating your mortgage amortisation, but my own small set of classes, which don’t do much more than providing a simplified MVC scheme, DB abstraction, session encapsulation, and authentication. The focus was on Dojo, of course.

Dojo Ajax Application

The good news first. Dojo is very, very powerful. Unless you do really esoteric JavaScript programming, Dojo probably fulfils all scripting needs you will ever have. It offers a great number of widgets from Delphi-like layout containers, windows, tabs, and menus to sophisticated tree controls, sortable tables, and data stores. The out-of-the-box widgets are very easy to create and use. Almost no scripting is required. All you need to do is to add Dojo custom attributes to HTML div tags. It is worth learning Dojo for the widget set alone. Widgets provide an easy way to enhance the GUI of web applications and to create powerful interfaces. But GUI widgets is not all that Dojo has to offer. The second most important thing is probably the Ajax facility, which is likewise a felicitous implementation of a complex functionality. Dojo offers several different transport mechanisms for Ajax requests, including XMLHttpRequest and IFrames. It hides all the underlying complexity from the programmer, such as mechanism differences and browser incompatibilities, and encapsulates Ajax requests into a single function call. Furthermore Dojo offers a JSON-RPC client for use with Ajax, drag-and-drop functionality, form validation, cryptology functions, graphic functions and animation, math functions, xml parsing and more.

Unfortunately there is also bad news. Dojo’s comprehensiveness entails complexity. Granted, this complexity is well hidden from the user. Creating a widget is as easy as adding some Dojo-specific attributes to HTML div tags and including the respective Dojo libraries into a JavaScript section in the head of the HTML file. Things start getting difficult when you interact with widgets and when you customise them. For most non-trivial applications you probably need to do both. What makes this task difficult is chiefly the lack of a proper API documentation. At this time, Dojo only has a partial documentation which means that you either have to look at sample implementations (of which there are only a few), or look at the Dojo source code, or scour the Internet for tips and hints. This can be quite time consuming and frustrating, as the specific information is not always available. It has been said that the Dojo documentation was even more fragmentary before version 0.4. Another problem I came across is that when I started to combine different widgets, such as splitters, containers and layout widgets, the Internet Explorer 6 could not render the page any more. I felt reminded of the bad old days of the browser war when cross-browser compatibility was a software engineer’s pipe dream.

Productivity was likewise not very exalted. I spent 60+ hours on developing a simple address book application (see screenshot), and I am not even counting in the time I spent on learning Dojo. This application has two screens, one for contacts and one for organisations. Each screen consists of an entity list that can be searched in two modes (simple search and advanced), a form with detail data of a single entity, and two linked tables. Almost all data exchange with the server occurs via Ajax calls. Each of the two pages is driven by 475 lines of JavaScript code that handle the dynamics, on top of Dojo. Although it was an instructive experience, and although I am quite impressed with the breadth and power of the Dojo toolkit, I did not find it very practical for real-world application development. Considering that a conventional PHP application could be produced in a third of the time, it would be more economic to use IFrames for producing a similar UI. I reckon that Dojo is still far removed from being a RAD tool for web development. Conceptually it seems to be on the right track, however. If a proper documentation becomes available and if widget integration and interaction is streamlined, it might come out as a winner. IBM and Sun have recently announced their official support for Dojo, so perhaps we should keep an eye on its future development.