Archive for January 2009
Stop Programming, Start Integrating
A few months ago I interviewed a web developer who applied for a position in my company. At that time he was still employed by another company and wished to change a position. I asked him what made him look for another job, and he said that the reason was professional – he further explained that up until then they were maintaining their own in-house developed CMS, and were starting migration to Drupal in order to get things done more efficiently. He claimed that working with Drupal was boring, since it merely involves integrating some existing modules into an application, and he prefers to do it the old low level programming way. He said that with a pride of a brave programmer, ready to fight them bits, bytes and bugs, and smiled with satisfaction. The poor dude thought he was impressing me… Of course I did not hire him.
This event took me back in time to 1999. I was then the CTO of Tikal Knowledge, a super PowerBuilder developer who was handed the responsibility of developing a web based knowledge management system from scratch. Driven by the internet hype of the late 90’s, our team just spinned off a software services company, and had no idea about developing web applications. We started to program the thing from scratch, in Java programming language – mainly because the only other alternative we could think about was Microsoft and we didn’t want to pay any license fees. We were so novice that we actually started programming an entire in-house web server. We realized we were doing something wrong when we had to figure out why no data is being actually written into the database. It turned out we forgot to code the “commit” statement…
At that point the company was nearing some great business opportunities. A bunch of high profile enterprises showed interest in our product. It was quite a neat product and I guess we had a good marketing team as well. However, the more promising the business future seemed to be, the more frightening the development process became. The product was fragile, strict, and had no friendliness whatsoever for the future professional services team to come. Our greatest fear was that the product will sell but the application will never be able to hold it from falling apart – should we keep developing it the way we did – and that the failure will be a tech one.
After a year and a half of development, with a major install at the first big enterprise client’s site few months ahead of us, we decided to switch to a completely different approach, junk all the old code, and start all over again – second time from scratch. We decided that this time we will be basing as much as we can on existing open source projects. It was a very frightening stage. We needed to accomplish a lot in a very short time and we had to trust other people’s code to perform for us. We never had a similar experience before and had little trust in it. But there was no other choice.
So we jumped on the J2EE wagon in its very early days – EJB specification was only version 1.1 old at the time – used JBoss on production back on the days when it was still called EJBoss and was quite immature and questionable, packages such as Apache Velocity (where is it today?), Ant and various others.
The result? After less than 3 months we were able to get back at the same point in the product road map from which we “branched”, this time with a robust product that was flexible enough, configurable and with much less bugs. We also had great development communities supporting us. We knew that we are ready to take the application further to wherever its clients will want to take it.
Then the NASDAQ collapsed and our opportunities all wiped off one after the other. Tikal Knowledge itself was not shut down however. CEO Lior Kanfi had wisely used our open source religion to shift the company focus towards providing cost effective open source solutions for the enterprise, and the company today is very successful.
As for myself, I learned a very valuable lesson at that time, a lesson I implement somewhat fanatically in my current ramblings: When it comes to developing applications, if you’re finding yourself programming too much, you must be doing something wrong. At this point, what you have to do is simply stop programming. Start integrating instead.
WordPress Theme as a Communication Protocol
One of the nicest things that a publisher gains by using WordPress (and any other open CMS like Joomla, Drupal and the likes) is the elimination of what was once – and still is for those publishers who still don’t use open CMS – a tedious, exhausting and frustrating process – the process of designing your website.
Designing a website wouldn’t have been such a dramatic process if a human designer wasn’t involved. But that’s not usually the case. If you polled a group of publishers for the thing they dislike mostly about what they do, they would definitely vote for the process of communicating with a website designer to be number one.
The problem is usually that publishers and designers hold completely different approaches and while formally speaking the same language, be it English, French or Slovenian, they use different dialects. Moreover, while publishers look for the utility in the design, the designer will most likely look for the artistic aspect.
Publishers who ever found themselves trying to explain their designers about usability and utility will testify that always when they finally had the designer humming, there was a slight feeling of guilt hanging the air, saying something like “hey you publisher, you art killer.” At that point many publishers share a very shameful thought. They wish they could hand the design process to a computer… experienced to a certain extent with computers, having those as well not always functioning as expected, publishers appreciate the predefined communication methods of computers – also known as protocol.
Now getting back to WordPress, and what it has to do with all this. Well, WordPress covers so many aspects of CMSing, one of them is a set of rules for designing themes and templates. Any publisher who chooses to publish their websites with WordPress must obey those rules. And – any designer who wishes to design a WordPress website must also obey those rules. There you go. No more conflicts. No more guilty feelings. The publisher can be so much utility driven, and designer can go so far with their artistic aspirations.
I am not sure they meant it over at WordPress, but what they really did is creating a communication protocol for publishers and designers.
Shahar Solomianik 