Apr 03

Akhirnya saya bisa nonton juga film ini. Film drama komedi tahun 1948 yang dibintangi Cary Grant dan Myrna Loy ini disebut-sebut oleh Douglas Crockford ketika berbicara tentang kualitas software. Menurut Crockford, membangun sebuah software itu seperti membangun rumah. Perlu perencanaan yang matang, teknologi/tools yang tepat dan skill yang baik dari para pekerjanya.

Sebab kalau tidak, kita akan bernasib sama seperti keluarga Mr. Blandings di film ini. Mereka harus menempati rumah impiannya dalam keadaan setengah jadi (waktu penyelesaian lebih lama dari yang direncanakan) sementara dana mereka sudah habis untuk keperluan yang tidak terpikirkan sebelumnya (over budget).

Link:
Mr. Blandings Builds His Dream House - IMDB
Mr. Blandings Builds His Dream House - Wikipedia

Dec 20

Saya suka membaca tulisan-tulisan Coding Horror, tapi tulisan terakhirnya dengan judul Nobody Cares What Your Code Looks Like terus terang sangat mengecewakan saya,

The next time you’re knee deep in arcane language geekery, remember this: nobody cares what your code looks like. Except for us programmers. Yes, well-factored code written in a modern language is a laudable goal. But perhaps we should also focus a bit more on things the customer will see and care about, and less on the things they never will.

Di sini saya tidak setuju.

Memang benar, klien tidak pernah peduli dengan kode yang kita tulis. Yang penting bagi mereka adalah program yang kita buat jalan dan sesuai dengan yang mereka inginkan.

Hanya saja, kode yang amburadul akan sulit untuk dikembangkan dan dipelihara. Penulis aslinya pun pasti mengalami kesulitan ketika harus menambahkan atau memperbaiki programnya.

Padahal, tidak ada program yang dibuat sekali jadi. Akan selalu ada perbaikan, penambahan atau pengurangan fitur. Selalu ada versi 2, 3 dan seterusnya. Bahkan bisa dipastikan, program yang cuma ada versi 1 bukanlah program yang bagus karena mungkin tidak ada yang menggunakan.

Selain itu, program yang kompleks lazimnya butuh lebih dari satu programmer untuk mengerjakannya. Dalam kasus seperti ini, kode yang kita tulis harus bisa dibaca dan dimengerti oleh programmer lain, cuma kebetulan saja mesti dieksekusi komputer. Maka biasanya dibuat standar penulisan program yang disepakati (coding standards). Anda akan dimaki-maki programmer lain kalau kode yang anda tulis acak-acakan.

Dengan kata lain, cara penulisan program bukan sekedar kebiasaan atau gaya tiap programmer, tapi justru sangat mempengaruhi program yang dihasilkan. Dari pengalaman, bugs yang saya temukan biasanya muncul dari kode yang ditulis secara sembrono, asal jadi dan tidak sesuai standar.

Jadi pendapat bahwa “tidak ada yang peduli dengan kode yang anda tulis selama programnya jalan” sebenarnya tidak ada faktanya. Ide seperti ini umumnya muncul dari mereka yang lebih mementingkan “kualitas” daripada “kesehatan” program.

Saya setuju dengan Kent Back bahwa program yang “sehat” jauh lebih penting dan berharga dari program yang “berkualitas”. Karena “kualitas” adalah ukuran instan (instantaneous measure) yang cenderung menipu.

Program yang mengidap kangker akut yang penuh dengan bugs di dalamnya biasanya tampak jalan dengan baik dan terlihat berkualitas dari luar. Tapi jika anda tahu dalamnya, saya yakin anda tidak akan menggunakannya.

Program yang “sehat” sebaliknya, mungkin tidak memiliki banyak fitur. Tapi semua fitur yang ada adalah yang benar-benar dibutuhkan user dan 99,99% bugs free. Kodenya yang rapih dan terdokumentasi dengan baik sangat mudah untuk dikembangkan dan dipelihara.

Program seperti ini akan selalu dinamis untuk memenuhi kebutuhan klien yang berbeda-beda tanpa harus merombak habis-habisan kode yang sudah ada atau memunculkan bugs baru.

Mar 02

So, couple months ago i was assigned to lead a project for one of our client. As usual, i made an estimation of how many people and man hour to do the job. From no less than 5 programmers i expected to work with me, it turned out that there was only one person available.

Currently, we’re on the final phase of this project. With so limited resources for this big project, i must say that we’ve been doing pretty well. What bothered me is whether i have done the right way managing my team.

Then i found this short article today, and i’m relief. Because that’s exactly what i’ve said to my team.

;-)

Feb 17

180px-Mullenweg matt

Many of you use Wordpress as blogging platform, but only view of you might know who's the guy behind this popular web apps.

Matt Mullenweg is the founding developer of Wordpress. He is a young talented developer lives in San Fransisco, California. He writes a nice blog at photomatt.net which i believe the first wordpress blog in the world.

Edgework's Brian Oberkich talked to Matt in 49:30 minutes interview. You should listen to this. Matt talked about Wordpress, Akismet and the zen of web product development.

As many other open source project leader, Matt is a nice and wise guy. He knows very well how to manage team of developers, how and when to deliver product to the end users, including take an action of any feedback from them.

There's a part on that inteview where he shared a funny story behind Akismet, anti spam system for blogosphere. Some time before he released Akismet to public, his mom gave him a visit to San Fransisco and lived with him for five weeks. Until at certain point when she decided to make a blog of her own.

Worrying his mom would also get spams offering porn site and would think this as what her son's doing all the time, Matt pushed Akismet's team to make a release version as soon as possible. :-)

Feb 17

svnku

Alright, i’m going to reveal some of my dark secrets. I can’t go through a day without doing certain things. Two of them are reading feeds and SVN updating using my Tortoise SVN .

Reading feeds might be a common activity for most people now. But checking out SVN repository? i don’t think so, especially when you’re not involved in the project.

But i’m telling you, it is a good thing to do for a developer. Following everything that happens in your favourite project’s repository can give you a clue whether it is actively developed or just an empty house that has been abandoned.

For example, i can easily know that projects like Zend Framework or Dojo Toolkit are still actively developed. While project like Ngeblog has been practically dead, since there’s no activity for the last four months. :-)

Sorry guys, i have to stop Ngeblog for now on, since i don’t have much time to maintain it. But don’t worry, there is Zend_Gdata that has similar feature and even more. And since version 0.7.0, Zend_Gdata has been moved into ZF core.

I also have signed Zend CLA last december to submit some of Ngeblog code to them (Client Login authentication). So officially, i am one of ZF developer now. Although there’s no single code i submitted yet till now. Arrgh, still got so many work to do in my daily job.

Anyway, back to SVN. For some projects like Dojo or ZF, getting files by SVN gives you more than by downloading the release package through their website. Dojo for example, gives you buldtools and test utility that i think it’s pretty useful.

The other advantage, of course, you’re always be the first to know the upcoming release. But you should beware, there’s always chances to any updating or even deleting some files in its repository. So keep your local files updated.

Oct 10

When i first started to write this post, i used “The Perfect PHP Framework” as the title. I thought with that kind of title i would get many people attention as i did before.

But then i decided to change it to “My Perfect PHP Framework”, not because i was affraid of people would criticize me, but because i realized this is the appropriate way of judging PHP framework. There is no such thing as “perfect” framework, for a reason i’ll describe.

So, my perfect PHP framework obviously not pointing out the name, instead the idea or guidelines if you want. But that doesn’t mean i never tried one, i tried many of them as you can see here,

myframework

Now, what is my perfect PHP framework? here you go ..

Continue reading »

Oct 04

Tidak, saya tidak pernah ditinju programmer. Dan sebagai programmer, sayapun tidak pernah meninju orang. Tapi bukan berarti saya tidak bisa, jadi tolong jangan coba-coba buat saya marah.

Tulisan singkat ini saya tujukan untuk anda yang tengah atau akan mempekerjakan programmer, yang berurusan dengan programmer, yang ingin jadi programmer dan tentu saja yang benar-benar ingin ditinju programmer.

Continue reading »

Oct 01

Mydreamapp.com

Sepertinya mydreamapp.com akan menjadi website yang sering saya kunjungi berikutnya. Bukan karena saya salah satu kontestan di sana, tapi karena mengikuti proses transformasi ide menjadi sebuah aplikasi nyata adalah sangat menyenangkan. Siapa tahu saya menjadi saksi hidup dari proses revolusi sebuah aplikasi yang akan booming dalam dua atau tiga tahun mendatang.

Continue reading »