This is a personal blog of Leong Hean Hong, recording the learning journey of a Jedi coder.
What we observed isn’t the actual reality itself. What we see is actually a reconstructed representation of what we’re looking at, and this representation is always incomplete and flawed.
Mark Joyner (Simpleology: The Simple Science of Getting What You Want)
As a software project manager, I am responsibled for gathering user requirements from users and communicating it to the developers. I find it useful to capture requirements by documenting use cases. In school, I was taught UML Use Case Diagram. I find it too abstract and too simple to be considered useful to customer, me, and the developers.
user-web-1. User can broadcast a message to his/her friends.
Preconditions:
Steps:
Postconditions:
This is an example of an use case. Each use case has a unique ID (e.g. ”user-web-1″), which makes it easy to communicate among team members. An use case title consists of an actor and an action. The actor indicates the types of users that will be using this software (it is usually an user role). The action describe what the user wants to achieve (e.g. register an account, post a message, send an email). Optionally, there may be a list of preconditions, which describes some perquisites/assumptions/context. The steps are a series of physical actions that user has to perform to achieve an objective. I will talk more about the steps later. Postconditions describes the consequences of carrying out these steps. Use case is written in such a way that an end user can easily understand. When the software is developed, an user can performs the steps in each use cases to verify if the software meets the requirements.
This is not a technical specification, use case should not contain technical detail. The steps should not describe the UI (i.e. layout, color, fonts). The purpose is to capture user experience. Designer should design effective UI to enable such interaction, developer should implement features that deliver this functionality. Each steps can be further broken down in finer detail. There is no rule on how detailed the description should be. I make sure it is as simple as possible (giving room for designer and developer to express their creativity), and detailed enough for me to communicate with both user and developer.
During the requirements gathering phase, all the use cases are documented in an Use Case Document (UCD). Whenever the implementation of an use case is completed, the tester (user) will use the UCD to verify that the implementation meets user’s requirements. Before each software release, there is a code freeze period where all documented use cases will be tested as part of the QA process.
Taken from Seth Godin’s blog post.
The job of the smart business person isn’t to fish in waters where coders are cheap. It’s to have enough initiative and vision that the best coders in the world will realize that they’ll do better with you than without you.
Business people add value when they make things happen, not when they seek to hire cheap.
Students are graduating in May, I have been interviewing many fresh grad for the past few weeks. Usually the master students have some working experience but bachelor students do not.
When I am evaluating a candidate, I mainly look for passion in software development, experience/knowledge is secondary, I do not care much about the academic result. Being good academically does not make you a good software developer. After all, most of the subjects learned in school are not applicable in our daily work.
I do not want people whom are just looking for a job. Passionate developers enjoy what they are doing. They will have desire to do the best and constantly improve their skills without being told to do so. Saying things like “I am keen in learning new technology”, “I am passionate in programming”, “I love software development” does not differentiate you from 90% of the other candidates. These are just can answers to my questions. Don’t say it, show it! If you have not even download the Android SDK and run the Hello World app, please don’t say “I have a strong interested in Android.”
If a person is passionate about guitar, he/she will frequently play guitar during spare time, even if this is not required by school coursework. That is why I like to ask “Have you ever developed any application that is not required by your school/work?” during interview.
Stream Media is looking for passionate developers! If you are one, you may send me an resume 
.
[The post was initially posted on MoVend Blog]
As a developer, I have to make multiple decisions everyday. When making a trade-off, there hardly is any right or wrong. Over time, the team develops core values, which act as guidelines for decision making. These guidelines then help the team members to make consistent decisions, allowing us to work effectively as a whole.
“How can I prevent, or make it difficult for a user to make a mistake?” This is one of the many questions I ask myself whenever I am designing an interface (UI and API). I use it as a guideline for making decisions. In order to achieve an objective (e.g. make a payment), the user has to perform a series of actions through interaction with the UI. When a user makes a mistake, he/she may be frustrated because the objective is not achieved. One method of circumventing this problem is to limit to only 1 possible way of performing a task. When there is only 1 possible way to perform a task, you can easily design a UI that guides user’s interaction. By reducing the possibility of making a mistake, user achieves the objective easily and fuss-free, coding then becomes easier as user action validation is simpler.
Limiting ways of performing a task is just one of the various implementation of preventing users from making mistakes. So then, how do you make it difficult for a user to make a mistake? Feel free to share your experience in the comments section.