2011/03 Mike Monteiro | F*ck You. Pay Me. from SanFrancisco/CreativeMornings on Vimeo.

Definitely one of the most useful videos I’ve seen in a while. Having to deal with clients in a regular basis, I can’t deny there is a great deal of common sense in it.

In my personal case, I do not do any client work without a contract in place, ever. I found it helps streamline the communication and the collaboration with the client, removing uncertainty and concerns upstream, instead of downstream. So far I haven’t encountered any client who didn’t want to have a contract in place; most usually we go through several revisions, depending on their legal team’s requirements or some other detail that has to be reviewed. But I’ve had people not respecting them. That’s another problem altogether.

I admit, however, that my contract model is far from perfect. And that’s where this video comes in handy. In particular, the “intellectual property transfer on last payment” part is the most interesting one for me; I’ve had payment problems in the past, even after an application was published on the app store, and I positively know that I do not want such problems in the future.

“Business is about giving and receiving”.

Now, don’t get me started on that chapter of “Friends”, where Joey writes a speech to celebrate Chandler and Monica’s wedding, and all he can come up with is a series of “giving and having and sharing and receiving” phrases. Stay with me; I will try to elaborate on this point. Being a constant learner in the business area, I take these phrases as precious information to shape the destiny of my own business. akosma software is my first company, and to my own amazement, my wife and I are able to live out of it; said like this, it might sound ridiculous. But it is a huge statement for me, an incredible source of pride. It is part of my very personal way of watching the world and ourselves.

Most people leave their employee status behind to start a company with the inner feeling of being the next Bill Gates or, these days, the next Steve Jobs. The idea, particularly in the tech business, is to become insanely rich. Much more than you really need to live a decent life. And to screw all those who block your path, and yes, why not, build an empire down the road.

Bullshit.

Let’s go back to basics: the basic idea of business, the one that lays at the bottom end of any human activity which involves the exchange of goods and services, is to be able to get what you need for a living, in exchange of your work or its product. Remember? That’s how it all started around 10 thousand years ago. And the basic ideas behind akosma software lie in very simple terms:

• To be able to live out of the product of my work, offering my own work, services and ideas;
• To be able to build something sustainable, that eventually might feed other people too;
• To learn new things, and to meet interesting people during the trip.

Most businesses have completely lost their touch with reality, not only because of the kind of products offered, but simply because of their way to perform their work. They treat people in such a way (inside and outside of their organizations) in such a way that it makes Jason Fried’s speech sound like revolutionary, instead of what it really is: good old, down-to-earth, common sense.

When Jason says that most companies do their best to get out of business, he’s absolutely right; simply because most people have forgotten why they go to work every day. That’s why books like Getting Real or REWORK are successful. That’s why Bob Sutton‘s books are successful. That’s why Tim Ferriss’ “4 Hour Workweek” became a bestseller.

Businesses, companies, managers, employees, we have all lost touch with reality.

Running a business is not just about how much money you can make; taking care of that is important, but not enough. It’s not about trying to screw people just for the sake of making a few more bucks, all while having nice words about social responsibility in your website. It’s not about filling your mouth with the ecology word while not even recycling paper in your printer room.

Don’t get me wrong; I consider myself a liberal. I believe in the free market and I resent governments sneaking into our lives. I believe in being able to associate and create new things respectful of what surrounds us as a society and an environment. I also believe that cooperatives are the best type of organization for small businesses, but I do not believe in democratic project management processes. I believe in vision and direction for products and projects, and I believe in a redistribution of the earnings (and the losses) among all those who helped create something new. I believe in small teams, committed to (not just involved in) their projects.

Most importantly, I want to believe in the people I work with. Let me repeat that: I work with people; they do not work for me, I do not work for them. I believe in us, whoever is “us” in that group.

Business is about not being hypocrite. Business is about being upfront about what you do, about the value that you add, about being passionate about your craft, about being proud of your work and your colleagues. Business is about saying no at the right time, and about never saying yes without care and attention.

Business is about giving, sharing and receiving. A good friend of mine told me once that I should never say “thanks” to him; a simple “wow, cool” was better. Being able to marvel oneself with whatever comes is a key element in happiness, the second key element being giving back to others whatever happiness we have.

When you focus business on people, long term partnerships invariably become strong friendships.

Prologue

A couple of years ago I found a job as a PHP + JavaScript developer in a small company in Geneva, Switzerland. I remember going to their offices two or three times, and having several interviews with various people there; one of them was the lead PHP developer of the company, the other being the CEO, a relatively well-known person in the tech area in Geneva; both shall remain nameless. The last interview I had was with the CTO, who would be my direct boss, as I was told.

They finally chose me, and very happily I signed the contract. I handed my resignation for my current job at the time, but had a couple of months of work to do before leaving (this is usual practice in Switzerland, one that I despise deeply, but that you are legally forced to follow). All in all, three months passed between me signing the contract and the first day of my new job.

The First Day

So one day, I headed to Geneva to start my new job. I arrive at around 9am to the address where the interviews had taken place, and, oh surprise… there was nothing. Stay with me: there was nothing. Not a sign in the wall indicating that the company used to be there, not a single desk, not a phone plugged on the wall. Nothing. Puzzled (to say the least), I asked the first person I met in the hallway about the company, and she told me that they had left a couple of months ago. I asked if she knew where they went, but she told me that she did not.

I was really, really worried by now. Had I signed a contract with some kind of fake company that had just left the country to the Bahamas or Luxemburg? I called their phone number. The automated voice at the other end told me that the number was not in service.

Oh dear.

After what must have been like 60 minutes of going back and forth in the hallways asking for some kind of information about the company, one guy told me that they had moved not far from there. Finally a clue! He even gave me an address, so I left as quickly as I could. I was one hour late to my new job; you do not do that in Switzerland.

On my way, I could not help thinking things like, “why wouldn’t they call me to tell me that they moved to a new place? What’s going on?”

So around 1030am I arrived to this new address, got into the building, and checked in at a reception desk that was standing there. I asked the names of the people that had interviewed me. The guy told me that nobody with that name worked there. Then I asked, “I’m looking for the company such and such”, and he told me that no, this was a private bank (there are lots of them in Geneva), so I must have been given the wrong address.

Bummer. Back to step one.

The guy, nevertheless, told me one interesting thing; in the warehouses behind the bank there was this new “startup center” with brand new offices, and the company might as well be there. I thanked the guy, and started investigating the area.

The word “investigating” is the correct one. It felt like being Columbo looking for a murderer.

Indeed, behind the bank there was a huge, new complex with many new offices and small companies popping up. The building was an old factory that the city of Geneva had bought a couple of years before, and where you could rent cheap office space. Perfect for startups. But in the main entrance, there was no sign of the one I was looking for.

It was almost 11am, and I was about to give up. My cell phone had not rang, nobody called from their office; my wife told me that nobody had called home either. If they were around, they really did not care about me.

Just when I was about to leave the building, I asked one guy cleaning the hallway about the company name. He told me that he had never heard about it, but that there was a huge sign near the entrance of the parking with company names, and that given that the building was fairly new, not all company names had been set up in every entrance of the building, so I might as well check that one out.

I left the building, went to the entrance of the parking, and finally! I saw the name of my new employer. Together with the indication of how to get there by foot: a 10 minute walk from where I was. I said to myself, well, what the heck. Let’s go.

When I crossed the door, I saw yet another reception desk, this time with a huge sign behind the receptionist with the name of the company. This was finally the good one. That was at around 1115am; I had been touring Geneva for over 2 hours looking for this company by now.

I tell the girl that I am starting today my new job, and she tells me that it was her first day too, so she did not know anyone, so she guided me to an office marked “Human Resources”, which looked quite appropriate for the occasion.

“Welcome to the company!”

The HR guy gets up from his desk, greets me and tells me that he started 2 weeks ago and that he did not know that I was starting that day, but that was OK, welcome to the company anyway! He guides me to the sector of the open space where the technical team works, and I finally see some familiar faces, together with some 30 people I had not seen three months ago.

The company had had an explosive growth in just 3 months.

Anyway, they point me to a crappy chair and table in the open space and they called that a “desk”, and I said, OK, let’s score some more points. Even better, the IT manager comes up to me and says “oh sorry, I don’t have a computer for you, I didn’t know you were coming today”.

I sit down, awkwardly, as everyone resumed their tasks in an awkward silence, a mix of “I don’t know anyone here” and “I hope it’s 5pm soon”. Probably one of the worst feelings I have had in a work environment in a while.

Meet the boss

30 minutes later (it was almost noon, and I was really starving by now), while I was sitting on my chair without having anything to do or anyone to talk to, a guy looking like a hawaiian surfer comes up to me and tells me that he was my boss. Which was strange, because he was not the CTO I mentioned earlier, but given that everything had changed so much, I was not surprised.

The surfer takes me to a meeting office, we sit down for what I think it is going to be my first work meeting, and he tells me that he has been appointed to this boss role last month, that they are dropping PHP altogether, and that they will be doing the new system using Java. The guy tells me that he knows that I despise Java (he read it on this very blog, actually) and that he does not like me not liking Java. But he cannot fire me, because he has not hired me, so my role is undefined and, as a matter of fact, I have nothing to do there.

It was 12am, and by now I know I will not be doing long in this company.

To make a long story short, a few days after that I went to the office of the CEO, I gave them my resignation letter, and they just told me, literally, “OK, bye”.

That was it.

Epilogue

After two years, I was told that the Java system was never finished. The company still exists but has completely changed its business model, and the CEO has left the country and moved his company with him.

I also learnt that the original PHP developer, one of the guys who interviewed me, the one who worked his ass off for 4 years building the only system that was actually bringing cash, was also being dismissed from the new team because he was not a Java guy. He was let go a couple of months after I left. Nobody cared that he actually knew how the original system worked, how the business worked, or that he gave 4 years of his work for a company that greeted him with another “OK, bye”.

My path to independence started that very day. Dealing with that kind of crap (of which I have many more nice anecdotes that I will write about very soon) is what tells me that I do not want to be an employee again. I prefer to starve rather than being treated like shit.

PS: you will not find the company name in my LinkedIn profile, for reasons that should be obvious by now.

Winner: Geekonomics: The Real Cost of Insecure Software by David Rice

Runner-up: The No Asshole Rule: Building a Civilized Workplace and Surviving One That Isn’t by Robert I. Sutton, PhD

And 6 more:

• Software Estimation: Demystifying the Black Art by Steve McConnell
• Modern C++ Design: Generic Programming and Design Patterns Applied by Andrei Alexandrescu
• It’s Not How Good You Are, It’s How Good You Want to Be by Paul Arden
• RESTful Web Services by Leonard Richardson and Sam Ruby
• JavaScript: The Good Parts by Douglas Crockford
• Programming Collective Intelligence: Building Smart Web 2.0 Applications by Toby Segaran

Geekonomics: The Real Cost of Insecure Software

My big winner for 2008. If you don’t care about software quality (yet), or if you think that machines aren’t already in charge or our world, this book is for you. This has been one of the most hyped releases of 2008, and indeed, it can send a chill down your spine. Geekonomics is a lively catalog of software glitches and disasters, showing users as “crash test dummies”, describing a whole industry built upon “end user license agreements”, removing liabilities as no other industry has ever been capable of. Even the world of free and open source software is described with strong criticism.

Geekonomics sometimes feels like a desperate plea to apply Deming‘s Total Quality Management principles in the world of software.

The book is interesting in several fronts. David Rice pledges for the creation of standards of quality, as well as tightening the requirement for certification of practitioners. His views are based on the United States, describing the legal framework of “tort law”, the economic foundations of “incentives” for industries, and using comparisons with other economic sectors, particularly with the automotive industry. The book is academic yet entertaining, frightening but instructive, but sometimes falling on the side of sensationalism, in my opinion. I could even say that some of Rice’s proposals are downright impossible to achieve, given the particular characteristics of the software industry, and the situation of the legal system in other parts of the world.

In any case, even if I do not particularly agree with all of his views, David Rice is right to emphasize his point strongly, giving concrete proposals, and opening the debate: the book would not have had the same impact if it had been written mildly.

Geekonomics was enlightening: it made me think about the quality of my own work in a completely different way (and prompted me to talk about it at Lausanne’s 2008 Barcamp). I think that taking a time of introspection, and reading your own code with different eyes is required to realize that we are, as software developers, responsible for much of what is going on in the world. And this is the major contribution of this book.

The No Asshole Rule: Building a Civilized Workplace and Surviving One That Isn’t

Some of my former colleagues will chuckle when they see this entry, because I’ve flown from a previous job a couple of years ago because of a total, complete, utter, outright and unmitigated asshole. A complete control freak, self-proclaimed genius, irresponsible jackass, who was the reason why 5 people (including me) left the place in less than 3 months.

(Guys, feel free to leave comments below ;)

More seriously, in the software industry it’s common to see that great developers are, more often than not, shy or introverted. This fact, coupled with the Swiss’ legendary attitude of eternal conciliation and conflict avoidance, has the side effect of creating troubled workplaces all over the country. No wonder this book made the headlines last month in Switzerland. This is a huge problem which is only being revealed right now.

In any case, this book is, together with Peopleware, a gem of teambuilding and a real bag of tricks to avoid turnover and burnouts in your company. An absolute read to everyone involved in the creation of workplaces, in every possible industry.

Software Estimation: Demystifying the Black Art

This book should be a mandatory read for every software developer, in every company, all over the world. It is a true gem, and a book that will become a timeless classic.

How many times have you been asked to estimate a project? To provide a deadline? To approve an estimation done by someone else? This book starts by enumerating the problems related to estimation, including those related to the definition of the word “estimation”, the politics and the economics surrounding and defining what is accepted and required, and the common traps where all of us have stumbled upon at least once. Then it provides a catalog of common estimation methods, from the most obvious to the most complex ones, including a description of their relative drawbacks and benefits.

McConnell is the author of Code Complete (which I’m re-reading these days) and Rapid Development (which I plan to read soon). This guy knows what he’s talking about, and he provides all the data required to support his claims. I cannot stress this more: if you are a project manager, a developer, a tester, an architect, or deal with software projects in some uncanny way, you have to read this book.

Modern C++ Design: Generic Programming and Design Patterns Applied

I bought this book during the writing of my Master’s degree dissertation project. I had heard about it before, but since my project involved a lot of C++ template metaprogramming, I thought that the best idea was to check with the real experts. And boy, I’m happy I did.

This book goes beyond your common programming grounds, whichever your favorite language is. I personally enjoy writing C++ a lot, but that’s me, and your mileage may vary. Doing multiple inheritance mixed with template metaprogramming, however, stretches your mind into the realm of what you previously considered esoteric and impossible, and that’s precisely the kind of readings that take you a long way forward.

If you are looking for a new way to write your old C++ code, or if you are asking yourself how different are C++ templates from Java or C# generics, read this book. You’ll find a lot of interesting stuff in it, with explanations related to an existing library (written by the author) called Loki, which provides the implementation of several patterns explained in the book.

It’s Not How Good You Are, It’s How Good You Want to Be

This little book (less than 130 pages long) was written by Paul Arden, former creative director of Saatchi & Saatchi, a recognized advertising agency (whose “early growth was also helped by a policy of settling the invoices from small suppliers as late as possible, while promptly paying large, high-profile companies”, dixit their Wikipedia article. No comments.)

Paul Arden provides extremely interesting and pragmatic views on creativity, people management, client relationship management and other stuff; if you happen to work in a web or advertising agency, you should read this book. However, as a software developer, I think that many of his views are still applicable to our own activity, particularly when, like me, you’re beginning your own independent path. It is not always obvious how to deal with situations when you’re “in charge”, and Arden’s recommendations do help.

RESTful Web Services

For years I thought that SOAP was the way to go. And then some Rails activists started talking about RESTful this, RESTful that, and well, it tickled my curiosity. It all started with Roy Fielding‘s doctoral dissertation about network architectures, followed by all the buzz of Web 2.0 APIs, which in the case of most startups took the form of RESTful APIs, found to be much easier to document, use and maintain than their XML-RPC or SOAP counterparts.

I read this book because of a requirement of a project where I worked at the beginning of the year, and this led to several blog posts and even a project, that are still today quite popular. I’ve been using the RESTful approach for other projects, involving .NET, the iPhone and Cocoa on the Mac, and I would have never thought that doing network-based programming could be this fun. Looking backwards, attempts like SOAP and XML-RPC look clunky, adding layers of unneeded complexity for most projects, and creating a higher barrier of entry for new users of an API.

JavaScript: The Good Parts

Douglas Crockford is head of web development at Yahoo!, and probably the person in the world that knows most about JavaScript. I’ve been reading his articles since I started working in my Propano project, and then watching his videos as soon as they became available.

His views of JavaScript as the World’s Most Misunderstood Programming Language helped me see this (now I think) beautiful language under a new light. And of course, I could not miss reading his short (170 pages) but extremely detailed book. I thoroughly enjoyed it and strongly recommend its reading to anyone dealing with JavaScript in any way.

Programming Collective Intelligence

I love programming books focusing on solutions rather than on specific features of some language; they provide insight on how to solve problems, showing the mathematical background required to do it. This is one of them.

This book can be considered a practical handbook on statistics programming, using Python for the code examples, but providing all the required insight and theory required to understand the logic beneath every code bit. The focus on Web 2.0 applications is clear, and this book has helped more developers than the author might ever know. Social sites are the realm of networks, large numbers, big datasets and complex relationships, and the techniques described in this book can help developers get out more information about their databases. Ever wondered how LinkedIn finds out someone you might know? This book has the answer for you.

What about you?

I would be very pleased if you could leave, in your comments below, the reference to your own preferred books. I am sure I have missed some gems last year, but 2009 is just starting!

The dot-com boom of the 90′s spawned a brand new generation of coders and software developers, including me, by the way. While before that time the term of “software developer” might have been reserved to system programmers fluent in C, COBOL, C++ or other languages, right now the vast majority of developers I know spend their time writing web applications, either public or in a private intranet, in J2EE, ASP.NET, Rails, PHP, you name it.

I have said before that writing web applications should be taken as seriously as writing desktop systems. Call me names if you want, but I’m a big fan of Joel’s Test.

However, after all this years, after the Chaos reports, after Peopleware, after the Mythical Man Month, people still treat quality as an afterthought. And also complain about how much software sucks, how expensive it is, and how late it arrives, by the way. Now that the iPhone SDK is widely available, that the App Store is selling more apps that we could have had imagined 6 months ago, many web agencies want to jump to native iPhone development contracts, which are hype and nice and pricey and whatnot. Which is only going to make things worse.

The dirty little secret in this story is this: iPhone development looks more like developing applications for a desktop operating system, and less, much less than web development. And I’m frightened to see some small shops (and even bigger ones), who never attained a real level of professionalism or quality in their software tasks, starting projects and realizing, later, when they are over budget and behind schedule, that this kind of applications requires a different mindset.

Let’s repeat something that you should know by now: web apps are easy to maintain. To begin with, you just have one instance running of it, and as Paul Graham said, you can write them in any language you want, you can release bug fixes with your application running, monitor performance issues live, change its appearance quite easily and for everyone at once, etc. This is probably the single biggest advantage of web apps. With AJAX we even got the possibility of going beyond in terms of user interface, responsiveness, perceived speed, you name it, and today the number of famous web apps is outstanding.

However, web apps run into this terrific (and terrifying) sandbox called the browser. They (normally) cannot access your file system, they cannot open other applications and interact with them – well, with some custom URL schemes like lastfm: mailto: or skype: you might have the ability to do some things, but certainly not much more than activating the application in some limited way as a help for the user. You cannot access the user’s hardware directly – well, again, you can access the webcam through Flash, or you can trigger the window.print() method to have the native print dialog pop up, but that’s more or less the maximum you can do.

In the iPhone, there is a similar situation. You choose to create a native iPhone application over a web one when you require one or many of these things in your application:

• GPS geographical data;
• Accelerometer information;
• Photo camera or library;
• 3D graphics;
• Complex animations;
• Address Book entries;
• Sound recording and playback;
• etc…!

I’ve talked about the dichotomy between iPhone native vs. web apps in my speech during the iPhone conference where I used this graphic, which might help those having to decide whether they should do a native or a web application:

The tradeoff, basically, consists in knowing that having the ability to access these features, means that you are giving up your capacity to roll out quick upgrades to your code. You have to depend on Apple’s own review process timings for that, which, as far as I’ve seen so far, cannot be predicted. And finally, you depend on the user’s final will to update your application!

Similarly, you also lose the ability to create these applications using your common, well-known, garbage-collected programming language, but you’ll have to deal with Objective-C exclusively, together with its weird syntax, possible memory leaks, eventual out-of-memory notifications, lazy loading techniques, compiler warnings and errors, and seeing the MVC design pattern even in your wildest dreams at night. Regarding the syntax, I admit that I love it, but it took me a while to get used to it, when I started playing with it back in 2003.

Given these conditions, when you start an iPhone project you will have (let me be very clear about this, so I’ll repeat) you will have to dust out your good old desktop application programming techniques (or learn if you don’t have them), read Code Complete again (which I’m doing right now) and take all the advice that you can from C and C++ programmers who have been working in this kind of stuff for the past 20 years.

I’ve even done my Master’s degree project in C++ because of this: the mindset required for iPhone apps is not the same as for your day-to-day web application, and is closer to that of a desktop application. I’ve been doing web apps for 12 years now, and desktop apps for 5 years (mostly in C#, Objective-C and C++); that’s my ground for stating this. You require a spec, you require tests, you require testers, you require daily builds, you require bug databases, you require quiet working conditions.

You require at least an 11 in Joel’s Test to know that you’re doing fine, but not only that: you need to know about pointers, you need to know C, you need to know that your code runs in an fragile environment with EXC_BAD ACCESS (SIGBUS) and low-memory warnings and stuff like that happening when you expect it the least.

Unfortunately, from what I’ve seen so far (at least here in the Lake Geneva region) many companies are spending much more than they intended to for rolling out their iPhone apps; these are real quotes from people I’ve dealt with in the past 6 months:

• “Oh, we do not write specs, we prefer to modify the code as we have ideas!”;
• “Oh, we do not write tests, we do not have the time for that!”;
• (in general) “Oh, we do not work like that here. We do what the client asks and that’s all.”;
• “We will not follow Apple’s iPhone Human Design Guidelines at all; we have our own. Users must double-click on buttons, so they feel more comfortable while using our application”;
• “We want our [PUT YOUR FAVORITE UIKIT CLASS NAME HERE] to have [SOME IMPOSSIBLE FEATURE WHICH DEFIES GRAVITY]. Easy, right?”
• “We have to remove this XYZ feature, right now!”, which means rewriting half of the code and leads to this: “What? So much? For such a small change?”
• “Why have you spent all that time ‘fixing memory leaks’? I won’t pay for that. Please concentrate in the new features we’ve asked. By the way, what are memory leaks?”
• “Here’s the styles document you asked, with the colors and fonts for the application” and the guy provides me with… a CSS stylesheet. Which references a font not available on the iPhone, by the way, and with colors in hex format.
• “We want an animation at startup, like the Chanel application” (everyone wants to release the next Chanel iPhone app these days) “here’s an [animated GIF / Flash movie / PowerPoint slides] with the animation for you.”
• “Our team has slightly modified the code when you weren’t there, but it does not work any more, could you fix it please?”

And of course, the all-time winners: the support tickets stating that “everything is slow” without further indication, or that “the application hangs”, without any details in it.

OK, I confess, I’m a bit of an extremist here; many of the quotes above are valid in some contexts. But not those of the small-to-medium sized iPhone projects I’ve been involved in lately, with the urgency of releasing the code as fast as possible, just for the sake of being there, in the App Store, right now.

There’s a long road ahead. The problem, again, is not the technology itself, but the people involved in these projects (me, for example :). There’s a bit of what Joel mentioned a while ago, about the perils of Java schools, which actually only has to do with developers, but there’s also the issue about teaching the clients the limits of the platform, and about creating a strong software engineering body of knowledge in companies which usually did not need it previously.

We’ve been doing web apps for so long that we’ve forgotten how to sit down, take a deep breath, fix that goddamn memory leak, and realize that, as Brooks and Joel said, good software takes time.

He summarizes his opinion in the famous phrase “plan to throw one away” (Brooks, 1995, page 116), underlining the problem of change management: managing change, right from the beginning of the project, instead of ignoring or avoiding it, is particularly important in software projects, since it presents a solid mindset for all stakeholders in order to avoid scope creep, schedule and staffing problems. One of the proposed solutions to manage change (the “only constant thing”) in a software project is the use of prototypes, which consist of UI mockups, showing basic interactions between the components and screens, allowing users to see in real time how the final software will look like, and serving as part of the feasibility study before creating the final product.

Several authors have highlighted different problems related to prototypes:

We consider three dangers to be most serious.

• Assumptions may be hidden (…)
• Feedback may be too expensive (…)
• Inappropriate human-computer interaction issues are highlighted

(Atwood et al, 1995, page 180)

One of the risk of creating a User Interface Prototype is accidentally raising unrealistic expectations about future progress on the project.

(McConnell, 1998, page 117)

Firstly, there are still plenty of users and managers around who think that the software is not much deeper than the user interface, and so if they see a nearly finished interface, they think the project is nearly done. (…) Secondly, engineers often get carried away about making a lovely user interface, and spend far too much time on it. (…) Lastly, and perhaps most importantly, is the fact that almost no code that is written as a ‘temporary throw-away’ actually gets thrown away. It usually gets used in the product in one way or another.

(Whitehead, 2001, page 254)

• Needs cooperation of management, developers, and users
• Managers may view prototyping as wasteful
• Managers and/or customers and/or marketing may view prototype as final product
• Programmers may lose discipline
• Prototype can be overworked (reason for prototype is forgotten)
• Prototyping tool may influence design
• Possibility of overpromising with prototype

(Hartson, 2001, page 5)

In my personal experience, I must say that I have not worked in many teams using prototyping extensively. Many times, when I have came up with the idea of doing a prototype, my managers (and even my coworkers) would dismiss it with the following criteria:

“We don’t have time – money – staff – (add your own preferred variable here)” “OK, but do the prototype in such a way that we could reuse it later” “We do not lose time in prototypes in this company; we do real work here” “We do not have a budget for prototypes in the project” “We know exactly what the customer wants” “Oh, we’ve tried that once, but the customers never like what they see anyway, so why bother” “Our client does not want prototypes, period” “Our CEO does not want prototypes, period” “I do not want prototypes, period” “Our policy does not allow prototypes”

However, I must add that in just one case (a successful project I worked in three years ago), the analysts team managed to fit in the project budget the capability to create a set of user interface prototypes using Microsoft Visio. This tool (or any other diagramming tool) has many advantages over the traditional “Visual Basic”-based prototyping:

• Any user with Visio (be it analysts, developers, end users with basic Microsoft Office knowledge) can contribute to the prototypes, suggest changes and play with the mockups;
• No code is needed, which avoids developers to reuse it later;
• The output can be inserted (typically as images) in other documents, e-mails, etc.

This technique had a tremendously positive impact in the project:

• A great deal of feedback from the client was related to the mock-ups;
• The design documentation had an excellent complement of information, in the form of screenshots, coupled with the textual indication of every possible action on the user interface;
• The developers could use these indications to reduce the uncertainty and deliver a product that matched the final decisions exactly;
• Since the prototypes were not “reusable” (they were after all only drawings on Visio) the developers could not be tempted to reuse the code in the final product.

In my opinion, this approach was one of the key factors of success of the project, but not the only one: the team members and the customer agreed that the project was critical and complex, and that a prototype could help everyone to understand it better. There was a specific mindset in the whole project, at both sides of the equation, which made prototyping a good option, and a success factor. Without this mindset, I do not think that prototyping will fit in any project.

References

Atwood, M. E.; Burns, B.; Girgensohn, A.; Lee, A.; Turner, T.; Zimmermann, B.; “Prototyping Considered Dangerous”, Interact ’95 Conference Proceedings, Pp. 179-184, NYNEX Science and Technology [Internet] http://www.fxpal.com/people/andreasg/interact95-2.pdf (Accessed June 24th, 2007)

Hartson, “Rapid Prototyping and Its Role in Development and Evaluation of User Interaction”, CS 5714 Fall 2001 – Usability Engineering, Virginia Tech [Internet] http://courses.cs.vt.edu/~cs5714/fall2001/notes/pdf/05_RP.pdf (Accessed June 24th, 2007)

Brooks Jr., F. P.; “The Mythical Man-Month – Essays on Software Engineering, Anniversary Edition”, 1995, Addison Wesley, ISBN 0-201-83595-9

McConnell, Steve, “Software Project Survival Guide”, Microsoft Press, 1998, ISBN 1-57231-621-7

Whitehead, R.; “Leading a Software Development Team – A Developer’s Guide to Successfully Leading People & Projects”, Addison-Wesley, 2001, ISBN 0-201-67526-9

I had just joined this company a couple of days ago, and the management asked me to take the project in charge. Not an easy task, particularly because it was my first experience of this kind. The client was pushing to get the software it had paid for (it was a desktop reporting application for the Police department), and had not got any kind of preview yet. So the first thing I did is to pick up my copy of “Leading a Software Development Team” book and read chapter 2, “I’m taking over the leadership of an existing project // where do I start?” and get a thorough read:

The first thing that you should start to do is to review the situation. This involves more than just absorbing impressions; you need to organize these impressions into a framework. Try to organize your thoughts into the following areas, and in each area try to separate technical issues from personnel ones: - Where is the team now? (…) - Where is it supposed to be getting to? (…) - How does the team currently intend to continue?

(Whitehead, page 17)

Another highly pragmatic resource was Joel Spolsky, and his “Joel Test”:

The neat thing about The Joel Test is that it’s easy to get a quick yes or no to each question. You don’t have to figure out lines-of-code-per-day or average-bugs-per-inflection-point. Give your team 1 point for each “yes” answer.(…) A score of 12 is perfect, 11 is tolerable, but 10 or lower and you’ve got serious problems. The truth is that most software organizations are running with a score of 2 or 3, and they need serious help, because companies like Microsoft run at 12 full-time.

(Spolsky, 2000)

The “Joel Test” result for this team was 2 when I joined the team (they just had source control and good tools). When I left the company, they were running at 9 (we just did not have candidates writing code during interviews, nor testers, nor hallway usability testing).

For this project I took the following decisions:

• Since the priority for the client was to see results, I asked the developers to concentrate on stabilizing “visible” features, particularly on a visual report editor, that used a complex set of controls, similar to those of a drawing application, to create reports. Doing this, we could have a stabilized preview version that we showed to the client as early as one week after my arrival to the project.
• In agreement with the developers, we set up a daily build procedure, and I also asked them to provide a “client build” every Wednesday, that would be placed in a public directory available to the client. It turns out that the client never downloaded the binaries, but they liked to see the version numbers grow, and the binaries being delivered. Every week, Wednesday was the “public build” day, Thursday was the “bug correction” day, and Friday, Monday and Tuesday were “new features day”. Small stand-up meetings every day allowed us to know what was going on.
• Another important concern from the developers’ side was to have a quiet environment to work. They were constantly interrupted by the (quite nervous) managers to see their progress, and as such, I decided to stand in between both; I asked them to not to interrupt the developers for any reason, and to ask me for updates. I became a “proxy” between both, which reduced the tensions, and brought some peace to the developers.
• I created a fast project plan in our Intranet (there wasn’t any, so tracking the project was next to impossible) by asking the developers about the tasks they needed to do to finish the project, with the estimated time to do them, and setting some milestones. Since the project was in a wiki page, the developers could change the time estimations in case that they felt they had made a mistake; the only condition being to notify me of these changes.
• Using that information, I could create a couple of reports for everyone to see, and bring more visibility to the project:
  1. I wrote a weekly report stating the week’s achievements, the status of the project (number of open bugs, new functionality available, etc).
  2. In the intranet, I set up a couple of graphs and report tables, which were automatically updated every day.
• I did not take any technical decisions about the project; I gave full authority on this matter to the lead developer, who in turn appreciated this trust and took spontaneously the decision of documenting and unit testing the system thoroughly doing extra hours every day. This boosted the morale of the team, and the quality of the application as well. The other two developers contributed to these tasks as well, and the rhythm of releases and their quality increased in a couple of months. It turns out that the architecture of the system was particularly well done, and as such, adding new features was a relatively simple task, once the underlying framework was done; of course, during that time no visible results were available, which made everyone nervous.

Looking backwards, the only technical decision I’ve needed to take during this project was to use the company wiki; there I could add information pages that everyone contributed to, reducing the number of communication channels and reducing the misunderstandings between project team members. I cannot stress how much this helped; it provided a complete dashboard for everyone to refer to.

The most important problems in this project were human and customer related ones. By providing more visibility to the project, and by reducing the signal-to-noise ratio in the communication channels between developers and management, the team was able to provide the customer with a more reliable and full-featured product.

References

Joel Spolsky, “The Joel Test: 12 Steps for Better Code”, Wednesday, August 9th, 2000 [Internet] http://www.joelonsoftware.com/articles/fog0000000043.html (Accessed June 8th, 2007)

Whitehead, R.; “Leading a Software Development Team – A Developer’s Guide to Successfully Leading People & Projects”, Addison-Wesley, 2001, ISBN 0-201-67526-9

One of the most famous citations in the book is the one regarding the consequences of adding human resources to a late project; this article will provide a couple of thoughts about this assertion, and highlight some contrariwise opinions. The Mythical Man-Month

The second chapter of Brooks’ masterpiece is named exactly as the book, “The Mythical Man-Month”; the core argument of this chapter is that the most frequent factor of project failure is schedule and time estimation. Brooks states that this is due to the fact that

Men and months are interchangeable commodities only when a task can be partitioned among many workers with no communication among them. This is true of reaping wheat or picking cotton; it is not even approximately true of systems programming. When a task cannot be partitioned because of sequential constraints, the application of more effort has no effect on the schedule. The bearing of a child takes nine months, no matter how many women are assigned.

(Brooks, pages 16 & 17)

The final phrase of the above paragraph is often used as a graphical depiction of the nature and meaning of Brooks’ law. It implies the strong need for communication and integration existing in software projects; being social processes, software requires a strong network of communication between team members, allowing them to coordinate the inherent set of interdependencies that every project has.

After an interesting analysis of common time overrun situations, Brooks ends this chapter with the following conclusion, which contains the enunciation of the law itself:

Oversimplifying otrageously, we state Brooks’s Law: Adding manpower to a late software project makes it later. This is then the demythologizing of the man-month. The number of months of a project depend upon its sequential constraints. The maximum number of men depends upon the number of independent subtasks. From these two quantities one can derive schedules using fewer men and more months. (The only risk is product obsolescence.) One cannot, however, get workable schedules using more men and fewer months. More software projects have gone awry for lack of calendar time than for all other causes combined.

(Brooks, pages 25 & 26)

This “law” is known and cited throughout the industry as an example of a common pattern, observed once and again in different projects all over the world:

Fact 3: Adding people to a later project makes it later(…) Intuition tells us that, if a project is behind schedule, staffing should be increased to play schedule catch-up. Intuition, this fact tells us, is wrong. The problem is, as people are added to a project, time must be spent on bringing them up to speed.(…) Furthermore, the more people there are on a project, the more the complexity of its communication rises.

(Glass, page 16)

As a personal experience, I must say that the lecture of this book opened my eyes more than many, many other books. It is a funny read, but also an enlightening one: many anecdotes told by Brooks strangely correspond to my own experience, and this one is no exception. I have seen projects gone unfortunately late because of the simple fact of adding more people; and in one particular case, the project was cancelled altogether. These projects had several factors in common, though:

• Bad documentation, or lack thereof; the only way for newcomers to the project to know what was going on was interrupting the other developers, disrupting the current operations on the project; I think that a good set of documents, describing both the high-level architecture and the low-level APIs are needed for new developers to jump in and catch up. It’s maybe not enough, but a good leap forward anyway.
• Lack of architectural vision; projects that do not have an architect, providing vision and technical leadership to the team, are in my opinion exposed to problems when more developers join the project. The architect can act as a proxy person, guiding new developers while they familiarize themselves with the project, isolating other developers from this task.
• Bad project decomposition in components; if the system to be developed is sufficiently large, and the decomposition in components is not properly done, the overlap and extended communication paths among team members might affect the whole project negatively. A good decomposition breaks down the whole project in a set of smaller ones, with the corresponding set of interfaces, which brings the whole team to work separately on different subsystems. In these, the risk of getting later for adding manpower is reduced proportionally.
• Bad working conditions; I positively think that open spaces are a common disease in our industry. Teams working in open spaces suffer more of noise and visual distractions, and this is more evident when new team members join the project.

Criticism

However famous, Brooks’ law has had a good deal of criticism as well, regarding the specific characteristics of projects that might be affected in case that new people is assigned to them. The OS/360 project, which served as the basis for Brooks’ work, might not be similar to other projects, and as such, the law would not necessarily apply to them:

For Brooks’ Law to be true, the amount of training effort required from existing staff must be significant. The amount of effort lost to training must exceed the productivity contributed by new staff when they eventually become productive. (…) “Late” chaotic projects are likely to be much later than the project manager thinks–project completion isn’t three weeks away, it’s six months away. Go ahead and add staff. You’ll have time for them to become productive. Your project will still be later than your plan, but that’s not a result of Brooks’ Law. It’s a result of underestimating the project in the first place.(…) Controlled projects are less susceptible to Brooks’ Law than chaotic projects. Their better tracking allows them to know when they can safely add staff and when they can’t. Their better documentation and better designs make tasks more partitionable and training less labor intensive. They can add staff later in the project with less risk to the project.

(McConnell, 1999)

Scott Berkun gives a more concrete analysis on why the law could be wrong:

• It depends who the manpower is. The law assumes that all added manpower is equal, which is not true.
• Some teams can absorb more change than others. Some teams are more resiliant to change.
• There are worse things than being later. (…) That can be ok if you also get higher quality
• There are different ways to add manpower. (…) The more experience everyone has with mid-stream personnel changes, the better.
• It depends on why the project was late to begin with. (…) no amount of programming staff modifications will resolve the psychiatric needs of team leaders or the dysfunctions of executives.
• Adding people can be combined with other management action. (…) if you’re removing your worst, and most disruptive, programmer and adding one of your best, it can be a reasonable choice.

(Berkun, 2006)

And what about open source projects? Many of these (Linux, Apache, MySQL) are potentially among the biggest software projects ever undertaken, and they don’t appear to suffer o fthe problems pictured by Brooks’ law:

But proponents of open source and free software development, including Linux developers, are not completely satisfied with the Law. Most famously (among geeks at any rate), Eric Raymond in his “The Cathedral and the Bazaar,” declared Brooks’ Law obsolete, if not simply limited, saying “if Brooks’ Law were the whole picture, Linux would be impossible.” Although Raymond now says that he has somewhat modified his views or was misunderstood, some still would say he is given to oversimplifying and outrageousness himself. “I don’t consider Brooks’ Law ‘obsolete’ any more than Newtonian physics is obsolete; it’s just incomplete. Just as you get non-Newtonian effects at high energies and velocities, you get non-Brooksian effects when transaction costs go low enough. Under sufficiently extreme conditions, these secondary effects dominate the system — you get nuclear explosions, or Linux.”

(Jones, 2000)

Conclusion

So far, the discussion seems to be open. There might be a scale factor for projects, which in turn might expose them to be affected by Brooks’ law. I think that research is needed to arrive to a conclusion, even if it will be a statistical one.

Other important facts highlighted in the book are the “second system phenomenon”, the productivity advantage of using high-level languages, and the importance of building a prototype – “one to throw away”. I can only recommend this book to everyone interested in the field of software engineering (which I did in my own review of classic books in this blog: http://kosmaczewski.net/2005/11/20/my-bookshelf-part-iii/ )

References

Berkun, S.; “Exceptions to Brooks’ Law”, January 11th, 2006, [Internet] http://www.scottberkun.com/blog/2006/exceptions-to-brooks-law/ (Accessed June 8th, 2007)

Brooks Jr., F. P.; “The Mythical Man-Month – Essays on Software Engineering, Anniversary Edition”, 1995, Addison Wesley, ISBN 0-201-83595-9

Glass, R. L.; “Facts and Fallacies of Software Engineering”, Addison-Wesley, 2003, ISBN 0321117425

Jones, P.; “Brooks’ Law and open source: The more the merrier?”, IBM, May 1st, 2000, [Internet] http://www.ibm.com/developerworks/linux/library/os-merrier.html (Accessed June 8th, 2007)

McConnell, S.; “Brooks’ Law Repealed?”, IEEE Software, November/December 1999 [Internet] http://stevemcconnell.com/ieeesoftware/eic08.htm (Accessed June 8th, 2007)

When in some situations it is not legally possible to use the title “software engineer” without an engineering degree of some kind (for example, in some states of the USA or some institutions like the IEEE – http://www.ieeeusa.org/policy/positions/titleengineer.html), the term “software developer” is usually applied to people in charge of designing, writing and / or maintaining software-based systems. I will use the terms developer and engineer interchangeably in this discussion, which some people might think is not correct. The discussion about the need of a formal certification process is a relatively new one:

Professional certification in the IT industry is a relatively recent phenomenon. It was begun in the late 1980s by Novell, Inc., an upstart networking vendor from Provo, Utah, in an effort to build market share and manage support costs for its products by building the skill levels of the people who worked with those products. Novell was one of the first companies to recognize the links between education/skills and product success. They knew that they could not build an education infrastructure that would support their worldwide marketing plans with their own resources. However, they also recognized that if they did not provide for skills acquisition for their highly technical products, they could never meet their product revenue goals.

(Shore)

However, no consensus about whether or not certification is needed has been reached yet. This article will highlight some of the problems raised by software engineering certification, which might explain the lack of consensus cited before:

• The first one has to do with the inherent extension of the software engineering field: are all software developers equal?
• The second one has to do with the large number of available certifications: which one to choose? Which ones are “reliable” indicators of expertise, and in which fields?

What is a “Software Engineer”?

In my career, I’ve found self-made people (I’m one of them, actually), real-estate architects, lawyers, mathematicians, economists and even geophysicists writing code for a life. What I’ve seen so far is that the most successful software developers are those who like doing it, no matter which profession they’ve followed. And the opposite is also true: many guys with a computer science degree discover, some time after they start their careers, that they definitely do not like that code thing.

One of the biggest problems with certifications is that there is not such thing as a “single kind” of software developer:

• There are those who write games, and spend most of their time writing in low-level languages for game consoles, optimizing for speed and space, and creating three-dimensional worlds using as little memory as possible…
• There are those who write web-based applications, and spend their time creating 3-tier architectures, talking to a database, using some kind of object-oriented platform, and luckily exposing some data using XML web services, dealing with cross-browser issues, and wondering what is all that fuss about Web 2.0…
• There are those who write operating systems, and work for some embedded software company, or hack Linux kernel device drivers every night, or work for Microsoft or Sun or Apple, and spend most of their time discussing whether microkernels are better than monolithic architectures…
• There are those who have the ill fate of working as a consultant, and spend more time switching from project to project every day, or dealing more with corporate politics, rather than with code…
• There are those who manage projects and spend more time in their mailing list or in Microsoft Project rather than being able to code (and then complain about this in their blogs)…
• There are those who have a software engineering degree, but work for ZDNet writing about industry trends…
• There are those who turn into human resource consultants, and try to keep up to date on the new trends, but feel completely lost given what they learnt in university…
• There are those who do a little bit of all what I’ve mentioned above, and are or not really good at all of them…
• And finally there are those who might fit any of the characteristics above, but would have preferred not to listen their parents and rather open that scuba-diving shop in Honolulu.

Available Certifications

This diversity explains the existence of more common product-specific certifications: you can be certified to use Microsoft technologies (http://www.microsoft.com/learning/mcp/default.mspx), MySQL databases (http://www.mysql.com/certification/), Apple servers (http://www.apple.com/xserve/raid/certifications.html), various IBM products (http://www-03.ibm.com/certify/certs/index.shtml), Java development stacks (http://www.sun.com/training/certification/java/index.xml), Cisco routers (http://forums.cisco.com/eforum/servlet/CCNP?page=main), RedHat Linux installations (https://www.redhat.com/training/certification/) or UML diagrams (http://www.omg.org/uml-certification/index.htm)

However, given that technology companies have interest in having many people taking their certifications, their affordability and low-entry barriers to get them, many of these become much easy to get than they should be, and as a result, they lose credibility, and do not help IT recruiters to filter properly software developers during the selection processes. I’ve heard many complaints of project managers regarding these certifications, and I think it’s a generalized feeling:

“Certified skills pay has not just flat lined, it’s in the negative. This is big news if you’re certified and you’re thinking about getting recertified,” said Foote. “This trend is in the fourth quarter, that pay for certifications is on the wane, while non-certified skills are growing in pay.”(…) Certifications are losing value because employers are looking for more in their workers than the ability to pass an exam; they want business-articulate IT pros.”

(Rothberg, 2006)

Bruce Schneier, a well-known security researcher, has written about security certifications as well, with a mixed feeling:

In the end, certifications are like profiling. They work , but they’re sloppy. Just because someone has a particular certification doesn’t mean that he has the security expertise you’re looking for (in other words, there are false positives). And just because someone doesn’t have a security certification doesn’t mean that he doesn’t have the required security expertise (false negatives). But we use them for the same reason we profile: We don’t have the time, patience, or ability to test for what we’re looking for explicitly.

(Schneier, 2006)

The conclusion of all of this is that the debate is pretty much still open, and that there is not a simple answer to it.

Market Fragmentation

There is an interesting anonymous comment in Schneier’s website as well:

Another thought on certification is they are not all equal. There are Vendor Certs. Microsoft’s MCP/MCSE, CISCO CCNA/CCNP/CCIE Pro: The canidate is likley to know how to work on your specific platform. Con: The canidate is likely to think in only the vendor’s interest. There are Certs to assure knowledge of standard security terminlogy. ISC CISSP Pro: Can talk strategy and evaluate the nine domains to evaluate how the company is doing overall Cons: Most likely could not tell you what the nineth byte of an ip packet means or if OpenSSL is out of date on Red Hat Linux. Topic specific, vendor neutral. SANS GIAC Pro: Vendor neutral. A lot of focus on specific skills in NIDS or Hardening Windows, Incident Handeling, etc. Con: Concentration on open source tools since they are easily available, but it does not seem to impress all employers.

(@nonymou5, in Schneier, 2006, spelling mistakes not corrected)

I think that this comment summarizes pretty well another problem with certifications: there is a great level of fragmentation in today’s market. Every single important technology in the IT world requires a huge investment in time and practice in order to master it, and this translates in a huge complexity for the developers to choose the right certification. All of these without taking into account the large number of IT-related university degrees available, online or not.

Conclusion

The term “software engineer” is sufficiently vague, and the number of “certifications” sufficiently large, as to allow a single “yes or no” answer to whether professionals in the software sector should be certified or not. I personally think that I would rather avoid vendor-specific certifications as far as possible, and choose university-related or problem domain related certifications instead, to keep my career options open, and my mind free of marketing.

References

Rothberg, Deborah; “Another Nail in the IT Certification Coffin”, Novembrer 3rd, 2006, [Internet] http://www.eweek.com/article2/0,1895,2051272,00.asp (Accessed June 3rd, 2007)

Schneier, Bruce; “Security Certifications”, July 20th, 2006, [Internet] http://www.schneier.com/blog/archives/2006/07/security_certif.html (Accessed June 3rd, 2007)

Shore, Julie; “Why Certification? The Applicability of IT Certifications to College and University Curricula”, [Internet] http://www.developer.ibm.com/university/scholars/certification/ebusiness/pdfs/why-certification.pdf (Accessed June 3rd, 2007)

Given the fact that Web Development equals Software Development, this discussion will be of interest to those building the smallest websites, as well as old desktop-intensive apps. It will not be a “Tell me what programming language you use, and I will tell you who you are” type of article, though it may look like one, because that is something you have to figure out all by yourself.

If you take a look at the list of programming languages, any business person would have an instant headache. There are lots of them. With the strangest names. You cannot possibly guess which one to pick from such a list, obviously. So, how do companies choose the languages they use? There are some straightforward methods that I have seen so far, in no particular order:

• Looking at what other companies use (typically Google, Microsoft, Apple or Sun, but it could be 37signals too).
• Following the advice of the CIO, the Lead Architect or some other politically-powered person, which might or might not have read this article ;)
• Looking at what the current pool of programmers in the company know how to use. Rinse, wash, repeat.
• Following hype.
• Because there is a market plenty of available, cheap programmers that I could use for this project.
• Taking into account the characteristics of the languages themselves (static vs. dynamic, etc).
• Following the company’s history of past projects (successful or not).
• Following what your the client suggests (or mandates).

I think that it is a very bad idea to take any of the above methods in isolation, without considering other factors. Doing so is a path to self-destruction in the medium to long term, even if you succeed in the short term.

Just as a small background for people not into programming: you can safely (roughly) group programming languages in a table like this:

In a static language all variable type references are bound at compile time; in a dynamic language, this is done at runtime (which allows you to assign a string or an int to the same variable). In a strongly-typed language, either the compiler or the runtime enforces the operations you can and cannot do on an object (depending on its type, as you may have guessed). In a weakly-typed one, there is no such restriction, and you can perform implicit conversions from one type to the other. And then you have functional ones, but that is another problem, because there are many programming paradigms out there. And then there is the hybrid ones, which I love as Steve Yegge does:

But also there’s, like, the Boo language, the io language, there’s the Scala language, you know, I mean there’s Nice, and Pizza, have you guys heard about these ones? I mean there’s a bunch of good languages out there, right? Some of them are really good dynamically typed languages. Some of them are, you know, strongly [statically] typed. And some are hybrids, which I personally really like.

He did not include Objective-C as “hybrid”, but I think it is. Anyway, so much for the theory, here is the main point of this article:

First of all, I consider programming languages (I know a few of them, and I have my personal picks) just as tools to get things done™. Nothing else. I think of them as hammers or Black & Decker screwdrivers or saws or nail guns.

Second, I believe that specialization is for insects. Getting stuck in a single programming language because of any of the reasons I have enumerated above is just stupid.

So what I want to say is: You need polyglot programmers in your team, like you need a team of people knowledgeable in many human languages in every company doing business at global scale. I would say even more, you need not only people fluent in western languages (like English, French, Spanish and Italian, which is my combination) but also in other languages, with different paradigms behind, like Arab, Hebrew, Hindi or Chinese.

What does that mean in programming terms? You want to have programmers in your team being able to use different languages in different ways; you want to have programmers that learn new languages every so often, just for the sake of it. And most importantly, you want to get rid of programmers that not only get stuck on a single language, but that, even worse, dismiss any other way to do things. Having people that takes a negative look on the learning side of things can bring your whole company to a dead-end. This industry is plenty of integrists, and you do not want that in your company.

For example, JavaScript can be used as a procedural, object-oriented or functional programming language. Does your JavaScripters know how to write functional JavaScript? If not, that is too bad, because they will not be able to fully understand what is going on behind the scenes in Prototype or jQuery then. Of course this will not block them from using those libraries, but they might not understand how to apply some interesting patterns in their own code.

Ask more about your programmers: do they know how to do complex C++ template metaprogramming? Are they aware of some performance problems brought by garbage collectors? Do they follow the latest evolutions of the next version of JavaScript? (even if they do not like them) Which blogs do they follow? Do they know why some people hate PHP? Do they know what a continuation server is? Which programming books have they read lately?

And finally, what is even more important than having chosen a good programming language? Your methodology. Ask yourself (or your team) about these points:

• Do you write unit tests? You might not have testers, which is a bad idea anyway, but that does not block you from testing code yourself (Steve Yegge):

<blockquote>
    And I would say it's a pain in the butt, but I mean... it's a pain in the butt because... a static type-systems researcher will tell you that unit tests are a poor man's type system. The compiler ought to be able to predict these errors and tell you the errors, way in advance of you ever running the program.
</blockquote>

• Do you use defensive programming techniques?
• Do you have a wiki, a project website or at least good documentation in your code? If not, how do your new hires learn about your product? No, reading the code is NOT a good answer.
• Is your chosen programming language portable? You might think that your system will never have to run on Linux or Mac, but why stuck yourself on purpose?

The common factor of all the above items is that you have to manage complexity. If you write code, you are creating complex stuff, and one of the best ways to manage complexity is to create small systems; as Steve Yegge said:

Small systems are not only easier to optimize, they’re possible to optimize. And I mean globally optimize.

And this is why you do not only need polyglot, but also minimalist programmers in your team. Small is beautiful. Paul Graham (of Y Combinator fame) knows that dynamic languages yield small systems:

The right tools can help us avoid this danger. A good programming language should, like oil paint, make it easy to change your mind. Dynamic typing is a win here because you don’t have to commit to specific data representations up front. But the key to flexibility, I think, is to make the language very abstract. The easiest program to change is one that’s very short.

And how can you get small programs? By choosing the right programming language. Which brings us to the beginning of this post! So, here go some tips for all of you looking for the right programming language:

• Prefer strongly-typed, dynamic languages; there are a lot of reasons for that, particularly those exposed by Steve Yegge in his excellent presentation at Stanford:

Yeah, sure, it catches a few trivial errors, but what happens is, when you go from Java to JavaScript or Python, you switch into a different mode of programming, where you look a lot more carefully at your code. And I would argue that a compiler can actually get you into a mode where you just submit this batch job to your compiler, and it comes back and says “Oh, no, you forgot a semicolon”, and you’re like, “Yeah, yeah, yeah.” And you’re not even really thinking about it anymore. Which, unfortunately, means you’re not thinking very carefully about the algorithms either. I would argue that you actually craft better code as a dynamic language programmer in part because you’re forced to. But it winds up being a good thing.

• Some points about his talk:
  • Many of the caveats of dynamic languages are not (so) true anymore (like the lack of decent IDEs or the performance problems);
  • There is a lot of research going on nowadays on the performance of programming languages, and this means that code written in these languages will benefit from many improvements in the near future, for free;
  • And yes, there is the hype factor I have mentioned above; the cool kids are using them:

Which makes them exactly the kind of programmers companies should want to hire. Hence what, for lack of a better name, I’ll call the Python paradox: if a company chooses to write its software in a comparatively esoteric language, they’ll be able to hire better programmers, because they’ll attract only those who cared enough to learn it. And for programmers the paradox is even more pronounced: the language to learn, if you want to get a good job, is a language that people don’t learn merely to get a job.

• Teach yourselves; setup internal workshops to have all your team learn how to do cool stuff with those languages you have read about in DDJ.
• Teach the community around you, and do not be scared of competition; have your team write papers, articles on business or technical journals, publish code as open source projects, and show that you can go beyond.
• Keep an open mind: continuation servers, Comet or multicore processors are the future. Is your team prepared?

Software is a social process. Once you get this in your mind, and get your team working proactively, collaboratively and teaching each other, the choice of a programming language comes in second place.