After only 12 posts published here, I decided to stop. Here's why:

1. Going local.
   I decided to make future posts in Bahasa Indonesia. Instead of making posts in English, it would be better if I help enrich the web with posts in Bahasa Indonesia. I believe the posts will have more value then.
2. Going faster.
   Reason number 1 was the only reason I need to stop posting here. However, I also have a hard time accessing posterous using my 3G wireless modem. It's quite slow. Slower than Wordpress, much slower than Blogger. Why not use email you say? I prefer writing and publishing a post through the web interface so that I have better control of the posts layout; especially when it comes to placement of images. Posting through email is not going to help.

That's it. I'm saying goodbye to Posterous -for now.

During my years of working as a software developer, the thought of experiencing an on time and under budget project never really crossed my mind. Sure I always started by being optimistic in every project I handled. However, with the rare chance of an on time and under budget project, I know better than to have my hopes too high. No matter how small the project was, delayed and over budget was something to be expected.

Fortunately, there was one project (let's call it Project OLE!) under my management that was on time and under budget. Project OLE! was a small one. I can't tell you any further about the requirements but let's just say it was something any dedicated web developers could single-handedly finish in 1 month.

I was given 2 months to finish the project by my client. Calculating the resource I have -along with the budget to provide these resources- and the amount of work to be done, I was delighted to have 2 months. That 2 months would definitely give me -and my time- a good amount of time to develop using Prototyping methodology and deal with the changes requested.

The project runs according to plan. All the major functions was completed in the first month. My team used another week to improve the user interface and discover known bugs. By the end of the 5th week, we are ready to present the first prototype to my client. 5 week of hard work and over time really paid off.

After the presentation, as I expected, the feedbacks were plenty. Some of the major functions needs revision. There are part of the functions that does not comply to what my client really wants. Another problem was that some of the requirements are missing. All that was the result of an insufficient requirements gathering process.

Fortunately, we only need two weeks to work on the feedbacks and then we immediately move on to present the result. The outcome was fantastic. My client was satisfied and thankful for a job well done. They even said that the web application would help to increase their productivity. Frankly, these words were much more valuable than any amount of money we'll get from the project. It's just that we still need the money to survive, don't we?

Within the last days we have before closing the project, we prepare the application for use in my client's server and provide small scale training sessions for intended users of the application. That was the conclusion of the project. Pretty simple, right?

Project OLE! was the first on time and under budget project that I managed personally. I just hope it won't be the last. It got me thinking of the things that made the project possible to finish on time. I tried looking back from the beginning to the end of Project OLE! to find out what made the impossible possible.

Was it the way I manage the project? I don't think so. I never did anything special while managing the project. Was it my team members? I did hire developers with sufficient skills so that they could immediately get started on the project, but that's what I do in every project. Was it the budget? No. It would be stupid otherwise. Was it the client? Yes!

It wasn't the preparations, it wasn't the process, it wasn't the team, it was the client. My client made it possible for me to finish the project in time. How is that possible? That's because they listen. This is the main -if not the only one- thing that differentiate Project OLE! from other projects I've managed.

In Project OLE!, my clients listen to what I have to say. They listen to my suggestions on how to make the application worth implementing. They ask us for what was the best options to accommodate their needs and then they listen to what we think is best for them. Along with an open-minded point of view of not wanting all the things they want in the same time, they don't ask for something ridiculous or outrageous features. It was obvious that this client of mine played a vital role in the successful Project OLE!

In other projects I've handled, the situation was the opposite. Clients tend to be the cause of delayed and over budget projects. With their know-it-all behavior, they always think they know what's best for them and have us developers do the impossible work even though in the end they would regret their own decisions.

Project OLE! was special and it will always be a pleasant memory for me. Even though I know that there is still a small chance of encountering an on time and under budget project, I never thought I'd come across it myself. Hopefully I could work on another on time and under budget project as Project OLE! in the future.

Ever since I graduate from college, I've been working with software vendors; either as an employee or a partner. With more than 4 years of experience, I pretty much know what it takes to be a competent vendor. I also know what it takes to make my clients see me as incompetent. Today, after almost two years working as a government employee, I really know what it takes to make a software vendor look downright incompetent.

What I'm going to share will be based on my own experience after having a series of disappointments caused by the inability of a software vendor to provide sufficient skills in implementing and supporting a running project. A little different from most software projects, the implementation of the current project was done by the client. All the vendor needs to do is provide training and support on how to use the software required for the implementation.

Now for the series of disappointments. The first one was the inability to provide capable trainers. I could say that the lack of capabilities includes both knowledge and experience. If it were simply a lack of experience then I might understand, given that the implementation of the current project was quite rare in Indonesia, but when the trainers don't understand what they're supposed to teach then there's nothing more to say.

The above affected the project schedule. The delay piled up to months; not just weeks. There was even a time when the training was suspended because the trainers were unavailable. The training session was scheduled for 1 or 2 weeks but it actually ended after 2 or 3 months. It was finally concluded after the summoning of an expert from abroad. Apparently they couldn't find a single human being from Indonesia who share the same capabilities.

I'll cut the story short and moved on to my next disappointment. During support, it took days for them to come up with a solution to a software problem. This might not be a problem if it happens once or twice. However, in my case, it's happening most of the time any problems occurred. It made it looked like this vendor doesn't know what they're handling. Truly disappointing.

Can it get any worse? Yes. There are times when they actually revealed how incompetent they really are. They admit to the fact that they are asking the problems in a public forum and are waiting for an answer. What's wrong with that? Asking is not wrong, but admitting that you're asking shows you don't know what you're dealing that you have to rely on some strangers (who doesn't hold any responsibilities whatsoever) to get an answer.

Has it hit the bottom? No. While admitting to opening up to a forum, the vendor actually ask us (the client) to participate in the forum. Wrong? There's nothing wrong about participating in a forum, but we're paying you (the vendor) for support. Isn't there supposed to be a high level of service defined in the SLA that forbid you to go that low?

The root cause of all these problems lies in human resource. I could say that I've reached a conclusion that the vendor we're dealing with can't provide sufficient human resource to tackle the training and support in the current project. I even believe that this problem was related to the fact that the vendor relied too much on the resource provided by its subcontracts. Things got out of hand when their subcontracts won't keep up to their requests.

Their list of incompetence is longer than what I've shared above, but the rest of the problems were minor or similar to the ones I've mentioned above. There's no telling how things end up the way they are in the project. One thing for sure, the vendor made a bad start and fail to improve it along the way.

In my previous post, I share my point of view about how technical skills was like a double-edged sword for IT managers. Either these managers have them or not, technical skills might prove to be counter-productive. It all comes back to the managerial skills of each manager and how they put their technical skills to enhance that managerial skills.

In this post, I'd like to share real life examples of IT managers I've encountered to date. I haven't met all types of them because I've only been in the IT industry for 5 years. Yet I believe I have plenty of things to share regarding this matter. I'll try to mention a few of them and show you how they perform as managers from my point of view.

During my years working as an IT professionals, I've met with plenty of people with exceptional technical skills. Some of these people were managers, but only a few of them that I considered as being successful. An example of the unsuccessful ones were the one who simply don't realize that managers need to manage things instead of doing everything by themselves. Everything went quite smooth except for the fact that this manager don't have a clue on what his subordinates have accomplished. This is quite obvious because he spent too much time working on his own project.

Another unsuccessful manager with exceptional techical skills is the one that expects too much from his subordinates. I've mentioned this in my previous post. This type of manager was the one who estimates tasks or projects based on his own skills instead of the capabilities of his subordinates. It was to be expected that the tasks or projects got delayed because most of his subordinates can't keep up with his expectations. What's worst is that instead of improving his managerial skills, he wind up taking over the work by himself. This kind of behavior will then lead to the unsuccessful IT manager I've mentioned in the previous paragraph.

Successful managers with techical skills, exceptional or not, actually knows how to estimate work while considering what his team are capable of. When his team works on an PHP-based project, he knows the difference in knowledge among his team members. When his estimation missed the target, he could easily discover the source of the problems and could easily execute a contingency plan, e.g. the team needs an overtime or additional manpower. Even if he doesn't really understand the core of the problems, his technical skills would serve to help him better estimate the problems at hand.

Estimation is always a big problem for managers. In my opinion, this is a much bigger problems for IT managers without technical skills. I personally experienced working under such manager who miscalculated requirements for a project that made the project got delayed for more than two months. This is not a rare thing in most software projects though.

One successful manager with no technical skills that I know was one that made decisions with the help of his subordinates. He carefully discuss the tasks for his team members to improve his estimation. He would then got a rough estimate of his team capabilities and what his team could a accomplish within a certain time frame. This manager must of course put quite a trust to the team members involved during project estimation.

One of the downfall with the above behavior is the constant dependency toward his subordinates. It wouldn't be so bad if he had trustworthy subordinates, but we can all see what will happen if his subordinates tried to fool this manager. We should always open the possibility that someone would trick his manager to reduce his workload.

Continous learning and experience is the only key to break such dependency. Just because we have trustworthy subordinates should never be viewed as not having the need to acquire any technical skills. Coupling technical skills with managerial skills is always a good achievement for managers.

Above all else, the success of being a manager lies heavily on managerial skills. It's not about how we do something. It's more about how we manage people to do something. Technical skills is not essential in this matter, but it does provide certain benefits in estimation and problem solving.

The question whether IT managers should have technical skills or not might be an old one. Some say technical skills are essential for IT managers, but some say the complete opposite. I personally think technical skills are a great addition for IT managers, but what matters the most is how these managers put their technical skills to use.

Without any technical skills, we usually get a manager who can't really estimate the time, scope, and cost of a task. This results in a depressing working environment because his subordinates can't keep up with his expectations. Both the manager and his subordinates could never understand each other because what the manager want could never be accomplished by his subordinates.

Similar problems could also be found with IT managers that have technical skills. The gap between expectations and accomplishments is still there. IT managers that have technical skills might understand completely what he's trying to achieve. He actually understands what needs to be done in technical level. Thus he expects his subordinates to cope with his expectations. The problem of course lies at the fact that his subordinates might have a lower level of technical skills than the manager himself.

The core function of a manager is to manage people and resources. That means a manager must know how to put his people and his resources to use BASED on the competence of his people and the availability of his resources. Every task should be estimated based on the capabilities of his subordinates and not by his own capabilities.

Regarding the examples above, a manager without technical skills could minimize the gap between expectations and accomplishments by involving his subordinates during work estimation. That means the manager must put his expectations to the ground to avoid putting too much pressure to his subordinates.

This also applies to the manager with technical skills. This kind of manager should avoid estimating any work using his own standard. As with the manager without technical skills, this kind of manager should also perform estimation based on the capabilities of his subordinates. The benefit of having technical skills in this area is that the manager could directly collaborate with his subordinates regarding any technical issues.

With sufficient technical skills, an IT manager doesn't have to heavily rely on his subordinates during estimation. He could have a good grip on any technical requirements and any technical problems during his work. This provides a better understanding of the work at hand and a better way to lead his team.

That is why I believe technical skills could be a great ADDITION for IT managers. It helps them get a better estimation of work and a better understanding of the problems faced by his subordinates. The only downfall is the possibility of creating a big gap between his expectations and what his subordinates managed to accomplish.

Some people have the tendency to hold total control over application. These kind of people would very much go for centralized applications instead of distributed applications. With centralized applications, it is without a doubt that application management (in any form) would also be centralized. With this type of management, every changes -major or minor- could always be monitored.

It's not that I disagree with such control, but it should not be used to justify the choice of using centralized application. We can have the same amount of control with distributed application. It might require more resources to control a distributed application but at least we can have less workload in one place.

One thing most people kept in mind about application management is data structure. With centralized application, we can easily define one type of data structure. Any changes to the application that affects the data structure will have effect on every user. There will be zero possibility of mismatch between the server and the client.

With distributed application, control over data structure are sometimes considered an issue. Changes in one client might not reach the central server. Thus opening the possibility of data mismatch and eventually data loss. Still I believe this is actuall NOT an issue. We can easily define rules regarding the structure of any data to be used in our distributed application. That way any changes to the client should follow the rules defined. This is in fact offers more control to the application compared to the centralized infrastructure.

Following the above, we can easily see that it is distributed application that offers total control. We can have different clients with different functionalities but with one set of rules for the structure of data. We can do what we want with the clients without having to ruin the whole application architecture. More control, right?

Sometimes people simply make excuses of why centralized application are better than distributed application architecture without actually comparing them on the same domain. These excuses are made simply because they are more accustomed to centralized applications and that they view distributed applications as a bunch of isolated applications.

I personally have nothing against centralized architecture. It's just that there are times when centralized should be chosen and there are times when distributed should be chosen. My preference towards distributed applications in this article and my previous article regarding this matter was directly connected to the infrastructure of where I work (the Directorate General of Taxes). In other circumstances, I might go for centralized architecture.

Continuing from my previous post about migrating from twitterfeed to dlvr.it, I wanted to really emphasize on the basic and that is easier feed management. The picture I attached in this post shows you the basic interface for feed management in dlvr.it called Routes.

Each route defines the Source, i.e. the feeds you want to deliver, and the Destination, i.e. the place you want them delivered. For each route you have to define at least one source and one destination. This is somewhat typical to any other similar services. However, dlvr.it made it easier if we want to add new sources to the same destination or the opposite.

In the picture I attached, I have a route with 4 feeds configured to be delivered to 2 destinations. Adding the last 3 feeds to that route was easy and quick because all I need to do was to add the feeds without the hassle of reconfiguring the destinations. With this, I can also avoid the hassle when adding a new destination to all 4 feeds.

This is a major difference with twitterfeed because in twitterfeed one feed means one delivery configuration. If I want to add a new feed then I'd have to do the same configuration all over again. If I want to add a new destination then I'd have to configure all my feeds one by one.

Twitterfeed has provided a great service to date, but I guess it's time to move on. Hopefully dlvr.it will provide a stable service no less than what Twitterfeed has to offer.

It's pretty rare for me to face the decision between implementing a centralized application or a distributed application. Up until today, most of the applications I've developed (or at least involved in developing) is centralized whether it's a web application or a desktop application. Since I am now working in the Directorate General of Tax (or was it Taxes?), stumbling to that kind of decision is inevitable.

If I were to choose between those two types of application architecture, I'd choose distributed. I might be new on this issue, but I do have a few thoughts to back it up. Some of the reasons why I choose distributed architecture over centralized are as follows.

1. Less work load in one place.
   With distributed architecture, we can easily share the work load for each application. In the case of centralized architecture, one server (or a group of server) needs to handle the request of a lot of clients. With distributed application, one server only required to handle a (much) smaller amount of clients depending on how much application server is actually distributed.
2. Islands of problems.
   If a problem occured in a distributed application, then we could isolate it only to the problematic server. This way we could avoid a total break down of the system and prevent a complete stall in our business.
3. Higher flexibility.
   This is one of the things large organizations have. The larger they are, the more branches they have. Although this is not necessarily true, it does applies in the Directorate General of Tax. Within its branches, requirements for an application differs. To really accommodate all the requirements with a centralized application should be difficult. With a distributed application, we can isolate these requirements so that it wouldn't affect the overall performance of the system.

They are a bit shallow, I agree. With more research I should be able to get a more complete view of the advantages of distributed applications. Within this short blog post, I'd really like to emphasis on the third reason I mentioned above.

With distributed applications, we can also distribute the continous development of the system. That way when new requirements arise in a certain branch, we simply modify the server that the branch was using instead of modifiying the whole system. If the requirements can actually be used in all branches, then we can distribute the modification to all the application servers.

One main concern with distributed application is security. Most data that was kept and used by the Directorate General of Tax are confidential data concerning taxpayers. This kind of data is not something that could be easily distributed. I believe this is one of the reasons why distributed application is rarely a feasible option.

In any case, my analysis is far from complete. Hopefully this will be the first of a series of post concerning enterprise application development from my point of view. Look forward to write the continuation of this post.

Most bloggers, including myself, wanted an easy way to share what their posts throughout the Internet. This is where services like Twitterfeed comes in. I've been using Twitterfeed to share new posts from my blogs. Up until today, Twitterfeed has never been disappointing. However, I was let down by the fact that it still doesn't provide native support for Google Buzz.

A few days ago, I found out about Dlvr.it. It provides a service quite similar to Twitterfeed. Though if I'm comparing it apple-to-apple, I think Dlvr.it has more to offer. Despite that, the one thing that made me interested in using Dlvr.it is that it supports Google Buzz. I really look forward to testing this feature.

I decided to use my Tumblr blog for the test because unlike Tumblr also don't support Google Buzz natively; unlike Posterous. Configuring Dlvr.it for my Tumblr blog was easy. I didn't have any difficulties following the steps to start sharing my Tumblr posts using Dlvr.it. The interface was quite friendly and easy to understand. Now I can easily share my blog posts to Twitter, Facebook, and Google Buzz.

As for the apple-to-apple comparison between Twitterfeed and Dlvr.it, these are the differences that I noticed:

1. Twitterfeed has Prefix and Suffix. Dlvr.it has both of them plus a Find and Replace/Remove feature. Using the last one, we can replace any word in the body or the title of our blog with another word.
2. Dlvr.it has a more advanced word filtering feature. One, we can choose specific field to be filtered, such as title or body. Two, we can have the filter keywords to act as a positive list, a negative list, or an ignore list.
3. Dlvr.it has scheduling feature. In my case, I don't really need this because I'll be using the scheduling feature provided in my blogging platform.
4. Dlvr.it has a direct post feature. This is something like what Ping.fm (or such services) had to offer. I don't think I'll be using this though.

The list above is far from complete. If you're interested in knowing what is there in Dlvr.it, then feel free to give it a try.

Today I realized that Blogger in Draft added a new sharing button that enhances sharing from Blogspot blogs. The new sharing button allows blog readers to share each post to a few social networking sites. Currently the sharing button only support 3 social network (i.e. Facebook, Twitter, and Google Buzz), 1 blogging platform (i.e. Blogger itself), and 1 email sharing. I've tested all the buttons and I didn't find any bugs.

This feature should eliminate the need for a third-party sharing button but only if Blogger could provide support for more social network. I've already add one to my blog thinking that most of my readers might be a Facebook or Twitter user. Though this is not the case for blogs with larger audience.