Just Kunil

This is the end of this blog. I’m moving to new blog: http://kunilkuda021.wordpress.com

See you there.

Regards,
-kunil

How do you differentiate them? If you’re going to interview them, ask these questions:

• Have you maintain other people’s program? What’s the difficulties that you have for doing it ?
• What kind of versioning system that you use before ?

This is the rationale for these questions.

It’s unlike popular beliefs that only experienced programmer that can create good programs. All programmers actually CAN create good programs.

However, the thing that differentiate veterans and greenies are veterans CAN MAINTAIN old program, greenies don’t. Greenies tend to create new program(s) to replace old programs. Remember this golden word: "Creating is easier than maintaining".

If you think that the old program was rubbish, maybe it’s ok to replace it. Bur for most of the companies, that I know, the old program is considered as part of their investments. Therefore, replacing old program(s) is a big no-no.

The second question refers to their ability to cooperate. Cooperate programming is very difficult. Without versioning system, it is almost impossible. Most programmer that never use versioning system usually never create/maintain complex software, or programs that need to be maintained for years, or work with other programmers. Simply saying that they’re not professional software engineer.

This is the little fun in the office. I hope you don’t get fat because of it..Hehehe

Ingredients (for 1 cup)

• 4 tsp of Milo
• 2.5 tsp of sugar
• 1 tsp Nescafe classic
• Milk (full cream version, not the powder one…My favorite is Dutch Lady)

Directions

1. Add Milo, sugar, Nescafe classic and a little of hot water. Stir
2. Add milk until your cup is full (cold milk is better)
3. Enjoy!!

Ok. I’m stucked with this website (http://keluargapelangi.blogspot.com) that my friend sent me. So, now I’m a foster parent of a girl named Dewi (ok-lah, once upon a time, I would like to have real daughter too…but need to wait for the wive first…hehehehe).

So, here’s her first letter (thx for Dea from Keluarga Pelangi).

This is very classic software management problem. Yes, it’s true that we may need it. But what if we don’t need it afterall ?

Software engineer is a bit different from other paper-work. We do similar work with the paper-work (typing, correcting, fill-up the form, etc). But the different is this. In paper work, the more that you type the less work that you will have. In software engineer, the more you type, the more work that you will get.

It’s true. Every piece of code that you’ve just added will add more complexity to your program. It means more time to review, test, and debugging (not to mention that any code that you’ve written will be kept forever as long as the product alive –backward compatibility requirement). At the end, clients will ask "how come making simple program takes so long?".

My suggestion for this kind of problem is to be procrastrinate. Keep the request in your mind (or in your design sheet if you have), but don’t put it there. Not until someone really-really needs it.

This was actually the fairy tale that my lecturer told me years ago, before he started the OOP concept.

There were two man that worked for timber company. Their job were to cut down the trees. But the company only had two tools: saw (manual saw) and chain saw. The first person that saw the saw, took it right away and saying to the other person "I always work with this tool all of my life. I’m sure I can finish my job faster than you using this tool". The second person took the chainsaw, but he never used it or knew how to use it. But he didn’t want to be fired from the company. So, he managed himself to learn it anyway.

In the first few days, the first man who used manual saw looked very productive. He cleared out the forest very fast, while the second man still playing around with his chainsaw. But on the third day, the second man finally got an idea of how the chainsaw should be used. So, he started to work on that day.

In the end of the week, the man with the chainsaw could only finish 50% of what the man with the manual saw did. So, the man with manual saw said to him "You’d better replace your tool with mine", but the man with the chainsaw refused. He said "Let’s wait until the next week".

The next week, the man with manual saw worked slower than before. His human force didn’t allow him to work that hard for a long time. The man with chainsaw worked as fast as the last week. So, in the end of the second week, the man with the manual saw couldn’t cut anymore trees, while the man with the chainsaw was ready to cut the next forest.

The story is analogue with the procedural and OOP concept. Procedural programming allows program to be created easily, and faster than OOP one. But, while the procedural programming gains more code, it’s effectiveness is getting lower. The programmer that works with procedural programming spends his/her time to prevent the code breaking while new code is inserted. In the bigger code, such as OS kernel, programmer spends his time, not by adding new features, but by tracking defects and fixing bugs. At some certain level, procedural programming cannot be extended anymore and has to be terminated. This problem is the main reason why OOP was developed, to make the program reusable and extendable with less headache.

At first, OOP was just a concept and can be deployed using any procedural language. Then Eiffel (the first OOP language) started to put language barrier to force its user think in OOP concept. C++ was also developed to extend C language to implement OOP, but it never force its user to think in OOP. As the result, there’s a lot of people that use C++ similar like procedural programming. Sun was addressing this problem, by creating C++ compatible language but with strict OOP (think in OOP or don’t use this language), called java.

IMHO, programming language is not the main issue when creating a program. The main issue is whether the programer has such concept about quality, maintainability, extensibility, etc or not.

Addressed by Steve McConnell in his book "Code Complete".

There are two different programmers in this world:

1. Programmers who program in the language: He/she limits their thought to the language features (eg. if the language doesn’t support OOP concept, then the OOP knowledge cannot be implemented).
2. Programmers who program INTO the language: He/she decide what thought that they want to express, and then determine how to express those thoughts into their programming language.

Sure, everyone likes it: free software, no royalties, good quality, tested, proven to work, etc..who doesn’t ? But the fact is that the adoption of open source in embedded system is low.

IMO, there’s one single fact that create this issue: product lifetime. The problem with embedded system is that the product lifetime (specially for the processors) is very short. Some new processors or ASIC can only last for 2-3 years, before gone out from the market.

But the silicon manufacturers are not the scape goat for this problem. For me, its distributors fault. The manufacturers usually give 2-3 years time before they completely stop the production. So the product should have 4-6 years lifetime according to the manufacturers point of view. But distributors usually sees end-of-life notification as "don’t stock this part" sign, unless some company order these products regulary. As the result, once end-of-life notification comes out, we can only depends on the number of item that’s stocked in distributor side. Once they run out of stock, it means we’re out of business too unless we can re-design the whole embedded system using new components.

So, what’s the relation of this with open source ? The time that most of open source projects need, from creation until mature, is longer than product’s lifecyle. So, we can have the most qualified open source software, but it’s running on obsolete processor(s) or ASICs that’s no longer produced.

If only we can have dedicated open source developer, payed by the company’s community, maybe we can solve this problem…But who wants to be an open source developer ?

I’ve been working almost 3 years in the small company now (company with < 10 members). It’s an interesting point that most of our problem is that our developers gone so fast. Once they come, another 2-3 months they might gone forever. So, developing internal company capabilities are very difficult.

Lately, my company pushes the design formalization up to the limit. We have detailed documents about requirements, database design, protocol convention, architecture, stage plan, milestones, etc. It’s a bit tough for small company, where all of your work is changed into creating documents (we’re developers not type-writers anyway)…

But I guess this is just because I’m not used to it. For a long term, documents like these can save the company in the long term, because they can hold the knowledge inside.

Nggak tahu apa bisa dikonfirmasi kebenarannya ato ga. Ini cerita dari rekan kerja saya yang berasal dari Hyderabad, sewaktu kami mengungsi di Singapore untuk mendapatkan social visit visa 30 hari (lagi) dari Malaysia.

Sejarah IT Hyderabad dimulai tahun 1995-1996. Waktu itu, ada gubernur (head state) Hyderabad yang mendapat pencerahan.

Industri penyokong Hyderabad sebelum era IT adalah agro-industri. Masalah utamanya, hujan di Hyderabad sangat jarang. Katanya di tahun-tahun awal 1995-1996, hujan sudah hampir 10 tahun tidak mengguyur Hyderabad. Karena itu, dalam waktu singkat, jumlah pengangguran di Hyderabad melonjak (karena sawah / ladang tidak bisa ditanami).

Head state Hyderabad waktu itu (lupa namanya) kemudian punya ide untuk bikin semacam "job matching" service. Semua pengangguran, beserta skillnya, di-data dan dicocokan dengan lowongan kerja yang tersedia. Kayanya waktu itu jumlah lowongan yang terbesar adalah IT (call center..kayanya), limpahan dari kesuksesan Bangalore (IT Bangalore dimulai tahun 1990 - 5 tahun lebih tua dari Hyderabad).

Masalah Hyderabad waktu itu adalah jumlah penduduk dengan skill petani / agraris jauh lebih banyak daripada jumlah IT-skilled labour. Lagipula, IT waktu itu adalah barang langka dan mahal. Karena itulah, head state Hyderabad kemudian mengajukan pinjaman ke Bank Dunia, untuk mengembangkan sekolah/universitas berbasis IT.

Alasan yang dipakainya :

1. Dana pengaman sosial, karena jumlah pengangguran sudah jauh lebih banyak daripada yang bisa ditanggung pemerintah daerah
2. Memutus hubungan dengan industri agraris. Katanya Head State itu merasa kl industri agraris tidak layak dikembangkan di Hyderabad, karena hujan (air) sangat susah di Hyderabad, biarlah agraris dikuasai state yang lain.

Uniknya, sekolah yang pertama-tama kali dikembangkan di Hyderabad adalah sekolah kejuruan. Mereka menyediakan sertifikasi dari Cisco, Oracle, Sun, Microsoft, Linux (ga jelas apanya yang disertifikasi dari Linux), bahasa Inggris (ada semacam TOEFL gitu kayanya), dsb. So, bukan universitas bergengsi ala Nanyang / NTU singapore. Sekolah kejuruan itu pendek waktu belajarnya, murah meriah (karena pendek waktu belajarnya), dan diakui internasional (karena mereka menyelenggarakan sertifikasi internasional).

Dalam waktu singkat, posisi paling bawah di IT (jadi operator PC, operator call center, dsb) bisa dipenuhi Hyderabad. Kemudian, berangsur-angsur, karena jumlah "buruh" IT di Hyderabad lebih banyak daripada di state lain (kecuali di Bangalore), industri software besar mulai didirikan di Hyderabad.

Sekedar info, jumlah engineering resource di Hyderabad sangat besar, dan kompetisinya sulit (sekarang). Kata teman saya, 5 lowongan kerja di IBM bisa di-ikuti 5000-an orang peminat. Karena itu, tiap sabtu-minggu, banyak perusahaan besar membooking ruangan di univ/sekolah untuk ujian saringan masuk..