Category Archives: Project Management

Mike Monteiro | F*ck You. Pay Me.

Posted on by

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.

Random Thoughts on Partnerships

Posted on by

A couple of months ago I had a very interesting conversation with a friend of mine, who happens to be a close business partner in many different ventures. During this conversation, one of his phrases, probably the simplest of all, struck me and stayed in my mind:

“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. Continue reading →

Welcome to the company!

Posted on by

Many people have asked me why, when I was an employee, I used to change jobs so often. The answer stands in between my own curiosity to take on new challenges, and the various assholes I had to deal with through the ages. Just as an example of this last case, here goes a true story, one that stands between being a candidate story for The Daily WTF, or as sample material for The No Asshole Rule book by Bob Sutton. You decide.

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. Continue reading →

Best books of 2008

Posted on by

You might remember my beloved mantras: learning a new programming language and reading at least 6 relevant books every year. Following the 2007 edition, here’s the list of the 8 books I have enjoyed most in 2008, ordered by a purely subjective and absolutely irrational decreasing preference. I strongly recommend all of them!

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:

Continue reading →

The Dirty Little Secret of iPhone Development

Posted on by

This is happening right now, at a web agency near you.

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.

Continue reading →

Dangers of Prototyping

Posted on by

Frederick P. Brooks Jr. has written about prototypes, saying that they are not only useful but strictly fundamental pieces of the overall software process, as in many other engineering activities. He gives the example of a pilot chemical plant, prepared to process 10’000 units per day instead of the 2 million units a day that the final plant would have to handle, in order to demonstrate the feasibility and uncover some unforeseen problems.

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. Continue reading →

Saving a Failing Project

Posted on by

In 2006 I had the opportunity to work as a “project leader” into a small failing project. Three developers were working in an ad hoc basis, creating a software application for an important client (a government office in Lausanne), without any kind of detailed formal specification, without any kind of design documentation, and with strong pressure from the management to release the application, even if not in an usable state. Needless to say, the project was also beyond budget.

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. Continue reading →

Adding Manpower

Posted on by

Published in 1975, “The Mythical Man-Month” is considered an all-time classic in the software engineering field. The book author, Frederick P. Brooks Jr., used his experience as the project manager of the IBM System/360 and its software, the Operating System/360, to explain a common set of problem patterns, applicable to other software projects as well.

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. Continue reading →

Certification

Posted on by

While several other professions have a long, established and standard procedure of certification, the title “software engineer” is applied to both self-made developers, turned into experts of some technique, or to people with PhD degrees, and a long history of both academic and professional achievements.

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. Continue reading →

On the Need of Minimalist Polyglots

Posted on by

Many companies, at some point of their history, ask themselves a simple question: what programming language should I use? The answer to this question is tricky, and has big, big consequences, for every single line of code of your future products will be written, read and suffered by it. This single choice defines the level of salaries you will have to pay, the skills of programmers you will have to deal with, the relative length and performance of your systems, the availability of tools (or lack thereof), the kind of support you will get (or not), the number of operating systems your code will work in, etc.

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.

Continue reading →