Entries Tagged 'Planet' ↓

Last week I wrote about The Passionate Programmer, about my and Chad's very similar ideas on many things. I closed by saying that it's hardly feasible or sustainable for any SME to base the business on passionate programmers. Imagine my surprise opening the PragPub Magazine yesterday where Chad Fowler talks about replacing your people with the worst people available. The idea is quite old and comes from Michael Gerber's The E-Myth Revisited. I read this book back in 2005 and I've been in internal fight with this book ever since. Even in my bookshelf it sits right next to it's antithesis Good to Great by Jim Collins. The idea Chad is getting at is that you should replace great people with great systems and get mediocre people to be run by those systems. Much like a clock - made of hundreds of small cogs and pieces, each easily replaceable and while totally insignificant alone, having a specific, clearly defined and essential role in the clock.

Let's backtrack a bit. I really loved The E-Myth Revisited book for the questions it asks. In fact, a bigger part of the book is dedicated to depicting a typical small business. Painstakingly describing day after day with such a detail and accuracy - I don't know a business owner who wouldn't resonate with every page. Unfortunately, it leaves out most of the answers. Actually, the answers are there, but while you can really feel the pain of the questions, the answers are put almost bluntly - like an external consultant just took over and reads his 6 steps to happiness. It took 10 years for the real answers to arrive. They're in the E-Myth Mastery. While this book never neared the popularity of the first one, I found it infinitely more useful. The main difference is that while the questions remained, the second book provides actual answers. While the first one is based on observation and consultancy, the second is based on first hand experience and the author lives through every sentence. I bought the book in 2006 but I didn't get round to reading it until late 2008. And it was a deja-vu. I read maybe 50 books over those 2 years - yet I didn't read the one that could/would have actually helped me. It was like somebody wrote a book about the what was going to happen, but I couldn't read it because I was too busy heading for the catastrophes I could have avoided if I just read the damn book.

Now back to the good vs. bad people question. Our business is streamlining and automating of business processes. Over the years we worked with companies from more than 30 different industries. Anything from travel agents, through media, manufacturing, logistics to financial consultants and portfolio management. People usually get our systems to either decrease their staff numbers while increasing performance or keep the numbers and radically improve performance. The way to do it is based on what Michael Gerber says - take a process and orchestrate it. In our case, it's followed by computerization, where the computer system does the heavy lifting. In Michael Gerber's case, once the system is orchestrated, the cogs (aka the least qualified people you can find) can be put in places and the show is ready to go on. Your role as a mastermind, is to grease the cogs, innovate and move from technician to manager (and later to businessman). This has worked remarkably well - just look around - this is the principle behind every McDonald's, Burger King, Starbucks, Subway, and so on. As a freshman in university I applied for job in McDonald's but at the end chose to work in research institute. I regret that decision to this very day. While I made considerably more money working in the research institute I lost opportunity to learn about how one of the very successful businesses is run. On the other hand, I've seen a number of places where just systemizing didn't work all that well. Take accounting as an example. The process is well defined (even though with considerable amount of leeway in asian countries), there are formal checks in place like audit, tax checks and so on. Yet I've seen it in quite a mess in a number of places. While there are better accountants just like there are not so great accountants most of them are able to do accounting. The cause was usually somewhere else. Most of the business owners are masters of their trade, they are the masterminds behind the systems and they are the puppet masters running the operation. When it comes to accounting, however, they're lost. So they hire an accountant. And then another. And data entry clerk. And temp staff because of the back log. And still the accounts are in mess. Buying a better (more expensive) accounting system doesn't help much neither. What's missing is usually leadership. It's not an accountant the technician but accountant the puppet master. Human systems don't tend to be as iron clad as the clockwork or jet engine. That's where the 1 obsession of the extraordinary executive (build and maintain a cohesive leadership team) comes from. You cannot be everything to everybody and people are not cogs - you can't just put them in places and expect them to function flawlessly.

I've always believed that you get only as good people as you deserve. And I've paid the price to learn this again and again and again. Most of the work I've been around is not linear. You can hardly say that if one CEO produces 1 mil of profits five CEOs would turn the same company in 5 mil business. Just like if a system takes 1 developer 3 months to develop it doesn't mean it would take 3 developers (offshore or not) 1 month. Just like if one sales person can close deals worth 100k per month it doesn't mean 3 of them will close 300k.

The Chad's article goes on to explain business automation likening it to automation of software development. While interesting to read - this is how software developers must feel when being compared to construction workers :-). I guess (literally guess) that Chad has passed the euphoric stage in his business and tries to see where is all that going. I wouldn't be surprised if it looked awful lot like working in a big company he left, but with way more responsibilities and way less money. That's where I went through the same Freedom musings. Hopefully, I am wrong and the wine and roses will last forever. They didn't for me, though. Time came when I realized that my business was just a business - without the magic IT formula from The 50 Great E-Businesses and instead of counting millions or billions on my account I had (and still have to) change from passionate programmer passionately pursuing his own sweet career to someone running the business. It's not just about me anymore...

Anyway, today I found a book that does a great job explaining just how different running a business is from software development. The book is The 100 Best Business Books of All Time. I am not saying that reading this book or even all 100 books listed will make you the best business person of the century or that it will solve all your problems. I merely believe that reading some of them will help you see what's on the other side and consider it before it's too late. There's a saying that smart people learn from mistakes of others...Never happened to me, but I hear it's great :-)

It's really been some time since I wrote something. I've been really busy - more than usual busy with all the projects but additionally busy trying to workout a solution to some of my perennial problems.

I finally managed to read The Passionate Programmer. It almost felt like reading my own notes. Over the past few years I've been talking and writing about quite a number of issues from this book. It's almost unbelievable that somebody has so similar views. Starting with the saxophone experience - I played saxophone for 10 years - I can relate really well to Chad's stories and parallels. Of course, that's not to say that because some things work in music they will work in programming as well. As Martin Fowler once said software development is software development and we shouldn't be comparing ourselves to other industries and drawing misleading or wrong parallels. Anyway, regardless of whether the conclusions are right or wrong the flashbacks to saxophone playing experience added extra level of depth (at least for me).

Out of the many ideas that struck a cord with me...here are a few I noted down

Invest in Learning
The nerve!!! Judging by the reactions I receive whenever I talk about importance of proper education and practice for programmers - it's ranking among the worst insults you can ever make. Every programmer worth his salt knows that learning is for dummies. We were born better than them (basically everybody else). Sarcasm aside, I believe that a lot of programmers would benefit from experience of playing a musical instrument. Daily (i.e. every day) practice and performances. When you're performing on stage without practice - okay let me rephrase that - when you're on stage without hundreds of hours of practice - you're very likely to screw up - and if you do you're like naked. There's nowhere to hide. The whole audience looking at you and everybody knows it was you who screwed up. Believe me, the next time you'll think more than twice before coming on stage without proper practice. When you program without practice (or learn on the job) you're just as likely to screw up...the only difference is that you can blame it on the customer, on the specs, on the technology, or whatever or whoever else around you. Many times you can just comfortably hide behind your boss as he/she is the one facing the customer.

Work expands so as to fill the time available for its completion
This is an interesting concept. In the industry where everybody complains about way too tight deadlines - Chad goes on to say that just by making the deadlines even tighter you can easily double or even triple your productivity. While I am still to meet an employee that would confirm this - it's definitely true for me and all my ex-staff that went independent. It's really fun to see that things that took them several months to finish while being employed can suddenly be done in a month when they're on their own.

Writing Skills
"If you can’t organize your thoughts in your mother tongue so that others can clearly understand them, how can we expect that you can do it in a programming language? The ability to shape an idea and lead a reader through a thought process to a logical conclusion is not much different from the ability to create a clear design and system implementation that future maintainers will be able to understand." While this politically incorrect statement would get you to prison in a number of countries it's surprisingly true. And quite opposite to the geek stereotype. Interestingly enough, ability to speak and organize thoughts clearly has become a very important factor for us. Try to notice the similarities between way people speak and code - if you have a programmer that is very verbose - talking, talking, talking and still not making the point clear - chances are his code will be very similar - long winded, using unnecessary constructs and never quite clear on what it's supposed to do. On the other hand, if you have an introverted programmer that says 10 words a day, chances are his code will be very terse, taking one liners to the whole new level.

Businesses and those who run them are interested in business results
A thing you learn really fast when you're on your own but it's your biggest enemy when you're an employee. I remember a fight I had with one of my employees - his conclusion was that he just wanted to have a life. And he was right. Why should he worry about the deadlines or delivering what the customers needed? His goal was to have a life and the work was one of the main constrains - there was no direct link between his performance and quality of life. Not seeing and understanding this was my biggest failure running the business earlier on. While we had the basic performance based structure in place it was so detached from the company's culture and pretty much left for everybody to make their own interpretation. The challenge is to reorganize from a black box to a concert stage where everybody is crystal clear on how his performance is linked to the achievements of the whole team and how that translates to the distribution of rewards. Chad puts it very bluntly: "Sure, you got it done, but what was it? Why did it matter? How was this so-called accomplishment not just a waste of company time?" He couldn't be more right. I cannot even count how many times people told me that they had been making sacrifices, sitting in the office 8 or 9 hours every day and I still complain about their performance. The issue here was that while they counted hours I was counting closed iterations and customer satisfaction.

It's easy to get hung up on technology choices
Especially when our technology of choice is the underdog... I believe this idea comes from the Pragmatic Programmer - something along the lines of when all you have is a hammer everything starts to look like a nail. I've always tried not to be attached to technology, however, having a 50 projects investment in a technology makes you very close to being dependent on whatever choices you made. Yet, an investment in wrong technology - no matter how much you like it is usually much higher than investment in a different technology that is actually right for the job.

Go independent
This is quite a dangerous point. While definitely true - there are uncountable advantages to running your own show - just go for any motivational seminar by T. Harv Eker, Robert Kiyosaki and the likes - but being the best technician is only a start. Even though, based on the book 50 Great eBusinesses there's a number of teenagers without any experience that are managing billion dollar businesses (or one man shows) out of they're parents living rooms - vast majority of businesses and people are not so lucky. While Chad describes this as natural next step and spends only a few pages explaining the benefits and some of the obvious challenges it's a whole new ball game - one that has very little to do with programming.

Finally, the book got me really thinking. I've been running the software business for 7 years now and while we've been fighting with lots of problems, the single most difficult thing has been to get the right developers. I wrote about different aspects of it in a number of posts analyzing it from many different angles. This books is/says exactly what I've been trying to say and find for all this time. So many people told me that my ideal developer is a mix of too many and too different skills, and that such animals are more rare than a unicorn. On one hand it was very encouraging to see that somebody else has the same ideas and expectations, on the other it's quite a gamble to base your business on something so rare. Yes, it's possible to find one or two and get started. It may even be feasible to hack a new Web 4.5 killer app and sell it to Google for millions of dollars, but it may be much harder create a sustainable business out of it. It may work for huge multinationals that Chad is talking about as they can afford $300,000 packages but hardly any SME can do that. In fact, I couldn't sleep for almost 2 weeks trying to find a solution questioning my every belief and experience with this business. I tried to unhung my self from the technology, the product, the people and try to weigh the price and the risk of each option today and 10 years from now. It's been quite an exercise - I am now iteratively implementing the changes - if at least 25% of it works out this could be a book that totally changed my business and life. We'll see in half a year :-)

Ext.form.ImageField = Ext.extend(Ext.form.Field, {
    autoCreate: {tag: 'img'}
    ,setValue: function(new_value){
        if (new_value == undefined || new_value == null) {
            this.el.dom.src = '/images/no_image.png';
        } else {
            this.el.dom.src = '/images/thumbnail/' + new_value;
        }
    }
    ,initValue : function(){
          this.setValue(this.value);
    }

    ,initComponent: function() {
        Ext.apply(this, {

        });

        Ext.form.ImageField.superclass.initComponent.apply(this);
    }
});

Ext.reg('image_field', Ext.form.ImageField);

  def update
    contact = Contact.find(params[:id])
    on_bind(contact)
    success = contact.save
    contact = Contact.find(contact.id) if success
    
    logger.info("saved")
    
    respond_to do |format|
      format.ext_json do
        json = contact.to_ext_json(:success => success,
                                   :methods => [:image_id],
                                   :includes => [:address],
                                   :messages => {:notice => l(:contact_updated), :warning => l(:contact_update_error)})
        render :json => json #:json => {:success => success}
        headers["Content-Type" ] = "text/html"
      end
    end
  end

{"success": true,
    "messages": {"notice": "Contact was successfully updated.", "warning": "contact_update_error"},
    "data": {"contact[image_id]": 15, "contact[active]": false, "contact[client_account_id]": 2, "contact[client_account_no]": "100",
        "contact[created_at]": "2009-07-07T10:31:54+08:00", "contact[credit_term_id]": 1}}

success: function(form, action) {
                      form.setValues(action.result.data);
                  },