Agile process as a product

I am a huge believer of Design Thinking and it is gaining some traction outside of the UI world. But it’s still pretty unknown by the programmer bunch. Often when thinking about UX ( User Experience ), people think about Graphical User Interface (GUI). It’s almost taken as synonymous. But an UX designer would certainly disagree with that.

An UX professional can be from an artist, a programmer or an analyst background. But one thing they need essentially is the understanding of users. Because the users are most often human, an UX professional needs to understand human behaviours. It’s probably a stretch to call them an expert in Behavioural Science, but I think they’d think so.

This got me thinking about the time I was studying User Experience Design and Human Computer Interaction (HCI). More specifically the Shneiderman’s “Eight Golden Rules of Interface Design”. The golden rules are designed around the limitation of human’s limitation to process information. And that makes me wonder if Agile frameworks are built on those rules. Let’s use Kanban as an example and see we can map them to the rules.

The golden rules in practice

Strive for consistency

Consistent sequences of actions should be required in similar situations; identical terminology should be used in prompts, menus, and help screens; and consistent commands should be employed throughout.

Kanban has the “pull” system in conjunction with the “Limit WIP” principle. Both elements has the consistency built in it. Pull system dictates that you can only pull from left column to right column. this is consistent throughout the board. While the limit is defined to WIP, it’s applied to all columns including todo column. But I guess Icebox and Done columns ( when used ) are the exceptions.

Enable frequent users to use shortcuts

As the frequency of use increases, so do the user’s desires to reduce the number of interactions and to increase the pace of interaction. Abbreviations, function keys, hidden commands, and macro facilities are very helpful to an expert user.

I guess this can be a more philosophical than actual application of tools. What I can think of is the use of continuous improvements to improve efficiency of process. The process should become easier to follow and more efficient as the team members build more trust and better relationship. If it doesn’t, a tool such as retrospective can be employed to facilitate improvements.

Offer informative feedback

For every operator action, there should be some system feedback. For frequent and minor actions, the response can be modest, while for infrequent and major actions, the response should be more substantial.

Visualisation is a big part of Kanban. The board is meant to give feedback on progress. How busy are we?. What happen if we pull this here?. We have too many tickets in QA column. When we do something about it we can see the board changes. When we are closer to the end of an iteration we can see the todo column drying up.

Design dialog to yield closure

Sequences of actions should be organized into groups with a beginning, middle, and end. The informative feedback at the completion of a group of actions gives the operators the satisfaction of accomplishment, a sense of relief, the signal to drop contingency plans and options from their minds, and an indication that the way is clear to prepare for the next group of actions.

Tied together with visualisation, you can start to see the importance of closure. A closure is achieved when a card reaches the end of the board. When the todo column finishes. When a card is pulled out of a column. Scrum do Sprints and pretty much reset every iteration to yield closure as well, indicating an end of something.

Offer simple error handling

As much as possible, design the system so the user cannot make a serious error. If an error is made, the system should be able to detect the error and offer simple, comprehensible mechanisms for handling the error.

Before error handling is the error detection. JIRA has this cool feature that will highlight columns that broke the limit. The growing number of tickets left in the todo column at the end of an iteration will indicate problems to the flow. When a ticket stays in a column for too long.

Process design to handle these problems should be simple. When a limit is broken, you shouldn’t pull more items into it. When there’s many leftover, take less tickets during the next sprint planning.

Permit easy reversal of actions

This feature relieves anxiety, since the user knows that errors can be undone; it thus encourages exploration of unfamiliar options. The units of reversibility may be a single action, a data entry, or a complete group of actions.

I can’t think of any Kanban specific tools for this, but Continuous Integration is pretty much what this is trying to cover. Having a good test coverage and an easy and continuous build and test setup such as Bamboo or Buildkite will help to improve confidence. And the ability to rollback is a pretty much the Undo button in every good UI design.

i like this rule very much because it doesn’t trust human being to do the right thing all the time. It acknowledge that shit happens and it shouldn’t be human’s job to constantly looking over their shoulder. It should encourage creativity instead.

Support internal locus of control

Experienced operators strongly desire the sense that they are in charge of the system and that the system responds to their actions. Design the system to make users the initiators of actions rather than the responders.

When I read this rule I think about micromanagements. The pull system enforces autonomy of picking up a task rather than being assigned to a task. You can still be told to pull a ticket, which is bad. But when someone is ready for a next task, without the intervention of the managers, they should be able to confidently know what needs to be done next.

To achieve that, a few things needs to be done first. Number one is to set priority as a team, and with that the prerequisite of everyone’s understanding of what the stories are through sprint planning. Next is the explicit rules such as “left to right, top to bottom”, and “Pull” system to act as the GPS, And there also need to be enough trust in the team so anyone is comfortable at making that decision for themselves.

Reduce short-term memory load.

The limitation of human information processing in short-term memory requires that displays be kept simple, multiple page displays be consolidated, window-motion frequency be reduced, and sufficient training time be allotted for codes, mnemonics, and sequences of actions.

The core of this rule in the context of process design is the effort to reduce multitasking and context switching. Not sure if it’s exactly Kanban’s principle but the general rule that my team ran on is a person only can be assigned to one ticket at a time. Kanban helps to visualise that by putting faces on cards. In a physical board, we can limit the number of face stickers in the reserve. But this constraint can be easily spotted during standup.

In the GUI sense, the board is encouraged to be simple. Reduce the number of columns. Smaller team size.

Process Improvement Plan

Process design is important. But every team is composed of different unique individuals. That makes it impossible to create a silver bullet framework. It can be difficult to start from scratch. Scrum is a good place to start if your team is new to Agile. Kanban’s first principle is to start with what you do. The next and most important step is continuous improvements. This IMHO is the core of the Agile movement. It is a never ending process of improving the process. So instead of designing a silver bullet process, we should design a process improvement plan.

But we often see the opposite in the real world. In Agile methodology, we often look at processes and tools as something to avoid. It’s understandable because the Agile Manifesto defines that we should value Individuals and interactions over processes and tools”. This value is often used as an argument against spending time talking about tools and processes. On one hand, this is a good interpretation of that value. It’s important to acknowledge it’s more important to spend time on improving interaction and individuals rather than following a set of rules. On the other hand, neglecting process could sometimes harm the interaction and individuals aspect of a team. In some of the well established frameworks like Scrum and Kanban, rituals and guidelines are often designed around people. They could help drive the interaction and individuals. But it is understandable that it can become a process pain.

Let’s take estimation for example. Scrum uses Poker Card estimation. Planning staffs often think that it’s a time consuming process with no much benefit. One of the Agile misconception is that it needs to be fast. And when it comes to estimation, people only think about that final number they need to tell their customer. When can we deliver this? Give me a ballpark! So some teams take the shortcut and get them from the team leader.

Let’s explore a little bit of a Scrum estimation ritual. Each member get a set of cards with fibonacci numbers on them. They represent “complexity” of a task. Someone, usually the Product Owner, would describe the task/project/feature/user story. Team members would then ask questions and discuss about the card. And everyone would secretly pick a number from the poker cards and reveal them at the same time. If the votes varies greatly, the outliers would need justify their votes. Revoting will happen until everyone’s happy with the estimate.

There are so much more details that goes into a simple process of estimation. There’s one about picking the baseline size, breaking down big cards, complexity vs time, equal opportunity. But most importantly for me as a developer, it forces every member to contribute and understand the story we’re playing to be able to vote confidently. It forces people to interact so they can have a confident vote.

Understanding reasons and benefit of each rituals is crucial in process improvements. Every conversation should start why do we do it and why doesn’t it work. With the help of the golden rules we can drive the discussion toward a process that is easy to use and one that people want to use.


Agile – From a developer’s eyes

What does it mean to be Agile? There are 3 common answers that I’ve summarised:

  1. It’s a corporate bullshit.
  2. Everyone interprets it differently, whatever works for you.
  3. You’re doing it wrong.

Somewhere between those lines, there’s a subset of people who truly believe that Agile is helping them so much in their daily life. I’m one of them.

I’m afraid I might have over-simplified the common sentiment of Agile in the tech community. However, what I’ve loved so much about this community are the people that have shown me how great Agile can be in the best way possible by bringing me in their journey, seeing the values for myself, and structuring frameworks and environments where I get to explore safely and help build a better culture.

And that’s one of the value in the Agile Manifesto, to value “Individuals and interactions over processes and tools”. We value individuals as human beings and trustworthy. We also value the interactions between individuals more than creating sets of rules or using specific set of tools.

There are many Agile writers out there that would be more comprehensive and most certainly helpful. But I’ve not found many that doesn’t focus on “delivery” or “customers”. As a developer who’s worked in various teams claiming to do Agile for over 5 years, and if you are also a developer, you would agree that most of these articles are irrelevant to us.

I’m not arguing that the customers are not the highest priority, they are. What I’m trying to say is that we’ve done so well in satisfying the customers we sometimes forget about the people behind it.

People are my passion. Human mind intrigues me and it’s my daily amusement to learn about myself, others and the interactions between. In this series, I’d like to explore on how Agile can help me as a developer and make my job less miserable. They’ll be focusing around people and not just developers but from a developer’s point of view. Stay tuned for the next one.

On workspace design and work culture

Despite being labeled as “hard to change”, culture is actually a very fragile thing. You’d often hear people say that it’s hard to build a culture. But also true that it’s difficult to maintain a good culture. So which is true?. I also think that workspace design has a subtle but important effects on shaping culture at work. let’s explore some of the examples of the modern workspace design and how they can negatively impact the culture.

Hot desks

Hot desking is when the employees are not designated with a fixed seat.

Boosting competitiveness and selfishness

Where one sits depends on how early they get there every day. Most of the time, their seat is reserved for them, their team mates know where their preferences are and I’m surprised to find that most of the time I actually find my seat to be empty.

However, when challenged with expansion or on team movements, the seating arrangement will change and slowly become more settled again.

It sounds like a good approach, but what culture are we really building here? The obvious good one is flexibility. Also the flock mentality that dictate that the people who works together will move in a similar fashion.

On the downside, it’s also building competitiveness. Not every desk is the same. Some has better monitors, some has better ergonomic. Often when complaining about not getting a good seat, the answer is “well, you should have came earlier”. But is that the culture that we wanna have in a productive environment?. There will always be someone that’s last to come in and will end up with the less idea desk. That person, even it’s not you, is someone who is a valuable member of the company. Having the setup that build a culture that put others in a less ideal position for one’s benefit is simply toxic.

Stripping you off you

Yeah sure, it sounds like a good thing, having everyone in the same behaviour. No conflict, no war.

No, it’s not that simple. We as an individuals are innately different and there’s that natural instinct to be able to tell one from another. Having a hot seat system means there’s no way to customise one’s desk. Every desk looks the same. There’s no way to fashion a photo of the loved ones or having fancy productivity boosters like custom keyboards or funny memes without the price of packing and unpacking them everyday.

Culturally, it’s creating a bunch of robots without creativity. Not allowed to customise their desk leads to the feeling that we are not meant to change anything, that self expression is not encouraged.

Employee engagements

Familiarity can be a powerful tool. People are drawn toward nostalgia for example, that forgotten familiar thing of the past. Hot desking doesn’t allow that to happen. Before one has settled in they have to move away. Not just the desk they are siting on, but the surrounding environment like the people next to them, the location from the toilet, the morning walk from the front door.

When a simple daily task is not familiar everyday, it can feel unsafe, like sleeping in a hotel room or being at a friend’s house for the first time. It’s difficult to feel at home when one is not familiar with it or to be able to build a routine.

Culturally, it’s building detachment. It doesn’t allow an employee to be fully part of the team. And when we don’t feel at home, we don’t feel safe.

Open Plan

Open plan office is when an office has no barriers between employees.

Diversity buster

The most common complained disadvantage of open plan offices are the noise. It’s common that conversation will pop up easily anywhere. It could be a good thing to encourage communication.

However, for some individuals, this form of communication is less favourable for them. Communication shouldn’t be forced but should be natural. More often, the lack of the safe space is the hindrance to communicate. Open plan offices doesn’t solve that problem.

Culturally, it’s discouraging diversity on communication preference. Everyone is expected to be loud and clear, or to be interacting frequently.

Ignoring trust

Supervision is one of the benefit of having an open plan workspace. Having each other seeing what one is doing all the time is meant to be more productive because it reduces distraction and personal stuff.

But it also destroys trust, or neglect the need of one. You don’t need trust if you can see them all the time.

Team work when it’s not needed

It’s nice that most workplaces have great and kind people who are happy to help when needed. Sometimes collaboration will only be effective if everyone is in the same space.

However, even in an open plan, one can pass their day without talking to anyway but still be productive. Friendship is often forged from collaborations and meetings which often happen inside a closed space or outside of the office.

It’s also annoying to disrupt someone when they have their headphones on or when they’re concentrating on something. And sometimes people are actually annoyed by one’s constant nagging for help and most people don’t hide it well.

Culturally, it’s building insensitive. It’s encouraged that one shouldn’t be afraid to walk to another person and disturb them. And not just the person we are interacting but other people around us that could be distracted by things that we do.

I guess what I’m trying to say here is that we should be more aware of some negative impacts everything can bring in a culture. Most of these impacts are not a showstopper. But it’s important to acknowledge them and try to mitigate them when possible.

Debugging PHP the hard way

Having to maintain a massive Object Oriented web application written in PHP, it’s amazing how many times I’ll have to use the same functions over and over again in multiple different places. I’m listing them down here before I forget.


The most used one, and the only way I can print anything right now in the application I’m working on without screwing up everything. It prints out the message into the application error log, which I then tail -f and keep it running in one monitor. Way to go multiple monitors.


How do I live without this. Even with the power of IDE ( I’m using NetBeans ), it’s frustrating sometimes to find out what the class of the object actually is. Especially in “well designed” object oriented application full of decorator and factories, it’s easy to get lost. get_class() produce the exact class of the object. Can’t live without this function.

var_export($object, $return=false)

var_dump() used to be my ultimate savior, but with the limitation on the printing into the web without breaking anything, I’ll have to print everything to the log file. var_export() does exactly that when the “return” flag is set to true. Although most of the times it ended up with recursion error, it’s still pretty useful.


Got to find the way to trace where something started. Pretty straight forward when combined with var_export() and error_log() as mentioned in one of the brilliant StackOverflow answer.

$e = new Exception;

error_log(var_export($e->getTraceAsString(), true));

What are your favorite debugging snippets in PHP?

Sharing objects between Modules in AngularJs

It turns out that sharing objects between angular modules is as simple as injecting a module into another module. Say myApp has some controllers and providers or other objects and myApp2 want to use some of those controllers. When creating myApp2, inject myApp into it and myApp2 now has access to all the objects in myApp to the extend that the HTML can use the controller from myApp without any extra codes.

// Common library of some sort
app = angular.module("myApp", []);

app.value('someVal', 'This is a val');

app.controller("controller1", ['$scope','someVal', function($scope, someVal){
$scope.someVal = someVal;

// My actual module
app2 = angular.module("myApp2", ["myApp"]);

app2.controller("searchController", ['$scope', function($scope){
// ... some controller's codes
<body ng-app='myApp2'>
<div ng-controller='controller1'>

Note that the HTML is using ‘controller1’ which is from ‘myApp’. I’ve built an app in AngularJs and going to create another one using the similar format. It also means that most of the codes are going to be shared. I’m glad that I don’t have to do much refactoring.

Methods of getting direct feedback from Servers

With the web technology advancing so rapidly and information is getting bigger and flowing faster than ever, many web applications nowadays can’t live without constantly checking for new data from the servers.

The most basic form of a websites deals with HTTP request from the webpage to the server. The user send a request in an url form and the server response with the content that was requested. End of story.

Say that you are viewing a page that tell you how many times a jumping sheep has been jumping and it is jumping in average of once every 1 – 10 minutes, you might want to refresh your page every few minutes if it has been jumping or not. But with today’s technology, there should be a way that we get notified whenever the sheep jumps.

The main challenges of getting a direct feedback is that web application usually support a huge amount of users and they could be located anywhere in the world. It is simpler to think that the server just give the information whenever it’s requested. Instead of being busy trying to send updates to every connected clients (if they are connected). However, let’s explore the possible implementations.

Auto refresh

If you’re building a website in the 1990s, this is probably a very viable options. It’s simple to implement and logically sounds. The requirement is simple, you need to know when the sheep in your server jump, but the server is not capable of getting to you and every one of you. So we set up a simple Javascript to auto refresh the page every few seconds.

The drawback is, page refresh is rarely favourable in the fast moving content packed web applications. By refreshing the page, you will need to refresh other resources needed where we are only interested in a simple integer that tell us if the Sheep has jumped. So, let’s move on.

Ajax Long Pooling

Ajax open up many great possibilities that until this day has become one of the core protocol in building responsive web applications. With Ajax, we can send a request without refreshing the page. This also enable us to implement a much more efficient auto refresh that doesn’t request the full page request. Instead, we send a smaller HTTP request in the background and update the page using Javascript.

In addition to that, we can set the connection to stay alive until we get a response (or time out). Anyhow, this will still involve the web browser to constantly sending new requests every now and then to get updated. One drawback is that the server might be idle for few hours without any new worthy updates, so the resources used to send those requests might just end up in waste.

Web Sockets / Comet / Probably other terms

lastly we have web sockets. With the web servers and browsers needing more and more frequents interaction, there is finally a way that the server can be event driven instead of request driven only.

Web Sockets allow a more interaction connection where the server can be allowed to send response based on events that happens in the server itself. In this way, the web browser (client) doesn’t have to constantly send request for updates, but simply be event driven as well that only reacts when needed.

This will also reduce the overhead of constant new requests that happen between the client and server.

However, web sockets may cause some compatibility issues depending on the server technologies used and also the browser. But we’ve seen an increasing support for this technologies that allow developers to create more and more responsive applications.

One popular technology that works well with Web Sockets is Node.JS. But there are ways to work around Django through Redis or other library that can provide us with this capability.

Reduce SQL Injection Risk in Python and psycopg2

It will be surprising that a slight different in your line of code can have a great impact in preventing SQL injection. Try to spot the difference between these 2 lines below.

# code 1 (with python string format() function)
db.execute("select * from some_table where filter = '{}'".format("going to Sam's party"))
# code 2 (with psycopg2 sql prepare syntax)
db.execute("select * from some_table where filter = %s", ("going to Sam's party"))

It probably looks obviously different, but for a second it looks like it shouldn’t give much different result. But sadly it does.

The first code use the python standard string formatting feature where given a string containing curly brackets as a placeholders like “This is a {}”, and with the format() method, it will fill those placeholders with other strings.

# Example
sample1 = "this is a {}, and also a {}".format("pen", "weapon")
# this is a pen, and also a weapon 

this looks fine for now. But try to do one for the string that we pass into the db.execute() above. If we print the string, it will give you the result below

select * from some_table where filter = 'going to Sam's party'

Notice the extra single quote on the filter? This will cause error and of course opening a whole world of opportunity for SQL injection attack. With the single quote unescaped, the rest of the string can be injected with other commands that will cause serious maintenance headache.

-- example: imagine the replacer string is "bleh'; drop table some_table; insert into user values ('some new malicious users'); --"
-- your query will become
select * from some_table where filter = 'bleh'; drop table some_table; insert into user values ('some new malicious users'); --'
-- note that double dash (--) is used for commenting. So the extra single quote will be ignored.

So, why does code 2 is a better way of string replacements? Because it has built in special character escaping mechanism in which all strings that are passed thorough this method will remain as a string instead of becoming a malicious codes.

db.execute("select * from some_table where filter = %s", ("bleh'; drop table some_table; insert into user values ('some new malicious users'); --"))
the code above will produce sql below


select * from some_table where filter = E'bleh\'; drop table some_table; insert into user values (\'some new malicious users\'); --'

Slow fgets in PHP. or does it?

We have a piece of codes that looks something like this

$old_file = fopen($filename, 'r');
$new_file = fopen($new_filename, 'w');

while($buffer = fgets($old_file)) {
  ... \\ $buffer is being edited here
  $buffer = $new_buffer;
  fwrite($new_file, $buffer);


It all works fine and very speedy all the while until one day we decided to run this piece of codes from a network drive.

Oh ya, did I mention that it’s running on a Windows Server?


When the codes above is running on the Network Drive, it slows down to almost 1 minutes per file, which normally only takes 1 seconds or less on a local drive. What went wrong?

Probably just like any debuggers will do, I went and print the execution time needed for each blocks of codes. Given that a while loop is a while loop, I didn’t put a timer inside the while loop, but only before and after the while loop.

The conclusion was that this particular while loop is taking most of the processing time. And as what most modern programmers will do, we ask Google about it.

“PHP fgets slow on network” I searched. Lot’s of results are complaining that fgets is slow. Hmm, now I know. But what’s the alternative? many. But hmm TL:DR. Too long, let’s find another shorter more to the point article (probably not this one I’m writing).

Searching on I read somewhere suggesting to comment out the fwrite() and try again. I did that, and it works faster. And of course it doesn’t solve my problem, but it seems that I’m going the right way. And voila, move the fwrite outside of the while loop, and it goes back to the better speed.

$old_file = fopen($filename, 'r');
$new_file = fopen($new_filename, 'w');
$buffer_holder = "";
while($buffer = fgets($old_file)) {
  ... \\ $buffer is being edited here
  $buffer_holder .= $new_buffer; 
fwrite($new_file, $buffer_holder);

So in short, don’t write into file line by line, write them at once. This way, you don’t have to go back and fort from Malaysia to US, but one trip is enough.

a real man only takes one trip

From Unicorn to Unicode

What is worse than knowing that Unicorn exists in some other dimensions but you will never be able to see it?

My answer will be the xA0 character from some encoding world that I don’t even know to exist. Being an Earthling, the only encoding world I’ve been and known is the Unicode. More specifically the UTF-8 realm.

Interestingly, many Unicode based systems reject the xA0 (or any nonconvertible characters) and totally crashes the system. Take Python for example, and also PostgreSQL later on.


In Python, there is a function call unicode() that convert a string from other encoding to Unicode.


However, the “errors” handling is defaulted to “strict”. It means that it will complain that “Something is wrong” whenever there is an error. Basically it means that it will break the system when there is an untranslatable character in the object that you are trying to convert.

There are two other options in handling conversion errors.

  • “replace” to replace the untranslatable character to the official Unicode replacement character
  • “ignore” basically replace the untranslatable character with an empty string.


When inserting non Unicode strings into an UTF-8 (Unicode based) databases, PostgreSQL will try to translate them first. Same thing will happen if the said string contain an untranslatable character, it will throw you an error.

This can be a hell of a problem because it technically break your system if your system is a one of those systems that process input and save them into a database.

So the solution is usually to try to catch these unicorns before they escaped into the database.

The adventure of the Old Mac line breaker in the Python world

There are many representations of a new line, End Of Line indicator, or a line breaker. You probably heard of the terms Line Feed (LF) and Carriage Return (CR). They are technically characters like the letter “A” and small letter “a”. But instead of printing the letter, they tell the system that it’s the end of a line. However, different computer system uses these 2 common characters in different ways but let’s narrow it down into the 2 most common ones, namely the Unix version “LF” and the Windows version “CR+LF”. But wait a minute, there is this Old Mac version as well that uses only CR character to represent the end of line.

Interestingly in the Python’s universe (and probably some other even more racist universes), the Old Mac convention is by default not a line breaker. If you read a file full of lines that only ends with “CR” using the standard file open() function in Python, they will come out as a single line text.

As a slightly less racist developer, we need to build applications that can support as many types of stuff as possible. Here are 2 tricks to help you ensure the file you are reading is read properly the next time you use it.

When reading a file

# Use the 'rU' mode so it understand the Old Mac properly
file = open('filename', 'rU')

If you happen to be working with File upload in Django, this might be useful


# First, read the uploaded file and convert it to unicode using unicode() function
# Second, stream the file using io.StringIO function with the Universal-newline mode turn on by setting newline=None
import io
stream = io.StringIO(unicode(request.FILES['foo'].read()), newline=None)