Danny Kwok

There’s no box

Recent Posts

  • AMS vs DevOps – Month End Closing

    It is month end closing! The first day of the month is usually the financial closing month as well. From a system view, there is always a heavy server load from last minute orders or batch job running monthly. This usually cause a whole lot of recurrent issues. I will do a quick comparison on how AMS (Application Managed Support) and DevOps view this standard issue.

    AMS (Application Managed Support)
    • AMS will wait for issues to occur and await instructions to react and rectify the issue.
    • More support tickets will mean more job done.
    • The issue are addressed at face value. There will not be RCA (Root Cause Analysis) unless requested.
    • AMS resolve symptoms to ensure low severity and faster SLA
    • AMS are measured by SLA from support ticket. It is usually worthwhile to repeat same ticket type as response time will be fast due to known issues.
    DevOps
    • Problems and risks are mitigated with business and system development knowledge.
    • Zero support tickets is the key objective to system stability.
    • DevOps conduct RCA for all issues and proposed enhancements or BPR (Business Process Re-engineering) resolve the root cause.
    • DevOps adopt short term and long term fix to prevent further recurring issues.
    • DevOps can be measured by low support tickets and positive Customer Experience (CX).

    From the comparison, you can see the obvious benefits of transforming your AMS to DevOps. However, there is a reality that DevOps are much costly than AMS. So, which approach should you be going for?

  • Carbon Footprint Report

    Many organization is in need of sustainability approach and strategy. A quick dirty way to start off is always the Carbon Footprint Report. So, what exactly is a Carbon Footprint Report and how can it be dirty and quick? This is 3 simple steps to start your sustainability movement using Carbon Footprint Report.

    Step 1: Communicate Report Objective

    In my real life experience, building a Carbon Footprint report is actually the easiest part. Most forgot to communicate the report objective to all the stakeholders. Often, the Carbon Footprint purpose is lost in translation. So, it is not surprising that its creation is a one time event and not being utilised.

    Step 2: Monitor your Checkpoints

    Another positive outcome you can derive from Carbon Footprint Report is the setup of checkpoints. There are many instance where the report is generated and processed as raw data. This is unproductive as you need sustainability checkpoint. The checkpoints ensure your sustainability efforts are monitored and guided in the correct direction.

    Step 3: Broadcast your Win

    The last part is the most important part. With one small step using Carbon Footprint Report, you can broadcast your sustainability achievements with continuing checkpoints. This reinforce your benefits of your sustainability program and creates more awareness. You may also develop a domino effect to other applications in setting this report as a key success part of all Sustainability program.

  • Data Gap

    Have you ever heard of Data Gap? This is a common issue from legacy application and processes. Data Gap are missing data in a required dataset. They are hidden risks to the Organisation and incurred unnecessary cost. In my latest project, data gap is the single biggest contributor in the support ticket. So, what and how can we do to remove Data Gap?

    Signs of Data Gap
    • Increased support tickets with data updates as resolutions
    • Additional fields in manual process vs existing fields from integration.
    • Mismatch of data fields between source and target system.
    • Added requirement of data translation and exception logic used in integration and reporting.
    Ways to handle Data Gap
    • Harmonisation of data for source and target system.
    • Business process reengineering of existing SOP (Standard Operating Procedures).
    • Removal of dead fields and update requirements to automate missing data retrieval
    • Change management of users to identify and manage Data Gap

  • Multimodal TMS

    Multimodal design is gaining in popularity for Transportation Management System (TMS). Multimodal refers to the different types of transport mode like truck, barge or air. Does multimodal creates more complexity for your TMS? Here are some tips to consider for multimodal design.

    To start off with multimodal design, you will need to ensure you have expertise or SME in-house. They are required to tweak and harmonized the multimodal data.

    • Transport modes have common grounds. Look at existing data for comparison. Remember the 80/20 rule.
    • Find the common fields from your commercial who will tell you their views in cost margin and ease of selling the products.
    • Go for simplicity and ease of maintenance in your solution design. If it is more than 5 steps, consider to review and revise your solution.
    • Utilise Agile for tweaking and improvement with data.
    • Build your multimodal knowledge base. This is incremental efforts and takes time to nurture your in-house capabilities.

    Multimodal design are advanced model and sign of maturity in your TMS program. Majority of TMS SME will apply various forms of multimodal approach. Till date, the best solution is not geared toward complex and elegant design but rather on simple and fast approach.

  • What Coder you want?

    We often review technical skillset for different projects. In our evaluation, we notice similarities in many candidates on their programming languages. So, how do you really differentiate what you want? I will liken coding to sport players at times. There are technical, flair or elegant coders similar to star players in a soccer team. The question is how to you spot this gems?

    Quick Tips
    • Who are you looking for? A star player, coding machine, or a problem solver.
    • Set a benchmark on the types of resources.
    • Look for project trends and the role they play.
    • Ask specific scenario based questions to the role you want.

    If you are a coder yourself, ask yourself which role you play best! The best fit will bring out your best performance. If you are hiring for one, what coder you need to make up the rest of your team?

  • Agile Exit Plan or DevOps

    When you are doing Agile, you naturally gain a new skillset on exit planning. This is due to the time box that is set for your changes. Waterfall favor extensive test coverage, testing and sign off. On the other hand, Agile focus more on code quality, speed with CI/CD (Continuous Integration/ Continuous Delivery) methods. In another words, you formulate your exit plan while building for Agile. This is also commonly known as rollback plan.

    In recent times, this is rename as DevOps that function in similar manner. In my team, I always emphasis End to End knowledge i.e DevOps and a need for Agile Exit Plan. Here are some ways of building your Agile Exit Plan while moving towards DevOps.

    • Good Agile deployment must have resilience way to monitor and rollback your codes.
    • Data integrity is a majority of deployment errors. Cultivate good code quality with exception handling.
    • Train SME (Subject Matter Expert) who can provide good advice on exit plan for each Agile deployment.
    • Develop 80/20 rule for your Exit Plan. Factor 20% as exception and focus your resources on the 80.
    • If you do not have CI/CD, consider a feature toggle approach or canary testing in your Agile deployment.

    It takes years of practice to master Exit Plan with waterfall approach. However, Agile is so intense that you can hone your skills within a year or two. If you are also handling Production like me, you are DevOps before you realise it.

  • Agile Code Refactoring

    For the past week, I have been doing some serious refactoring and Agile Code quality control. Some may ask why can’t I outsource this to contractors or other team members? There are many reasons and I will list some of them for general learning.

    Code refactoring is usually done for many reasons and one of them is upgrade of legacy logic to current logic. In many cases, code refactoring takes a long duration amid a waterfall approach. In my case, I adopt an Agile refactoring approach. This approach warrants certain criteria and conditions.

    • Project timeline is very short and agile refactoring approach is best suited for this nature.
    • Code refactoring requires deep knowledge of domain and technical aspects of the system.
    • There is a need to remove old codes that are irrelevant. Therefore, junior member or contractors are not able to provide the decision making.
    • There is also refactoring for performance and upgrade of solution to current ones.
    • Some codes are layered and entangled in logic. Sometimes, a rewrite is better taken to obtain the same output.
    • Some codes are obsolete and require total removal. It take guts to cut away this cancer.

    Code Refactoring is seldom recommended as it is time consuming and resource intensive. Decades old codes, performance issues and recurring user tickets could point a need to refactoring. You may choose to adopt Agile Refactoring approach instead. However, this approach can only be undertaken by SME (Subject Matter Expert) with deep techno-functional knowledge.

  • Agile Traits

    I am asked a question of what traits should be in my team. To me, being Agile can be trained to some extent. However, some traits are natural to Agile and suit the person well. This is what makes the person perform exceptionally well in an Agile team. Here are some quick guides to look out.

    Natural Trait for Agile Team
    • Thirst of knowledge and passionate to learn.
    • High intrinsic motivation.
    • Ability to innovate and embrace changes.
    • High integrity and self monitoring.
    • “Never say die” attitude

    To tease out these traits, ask hard scenario based questions. You can also expose team to such scenarios and raise their awareness. Some members will thrive while others lag behind. You may want to redeploy laggards to maintain a high delivery Agile team.

  • Agile Code Quality

    I have the “chance” to review old codes while upgrading. The “perfectionist” me end up refactoring and recoding some of the logic. This is a very typical issue of outsourcing enhancements. You can see layers and layers of codes on each other. Some overlap each other doing the same thing. It is no wonder that object locks and table locks occured!

    This bring us back to the fundamental of code quality. With Agile, how does we ensure code quality with speed?

    • Agile is about discipline with quality.
    • Each iteration must include improved code quality.
    • Code quality is proportional to performance. If your performance is degrading, it is time to review your codes.
    • If you find the code hard to read, it is a sign of poor quality. Good codes are structured nicely and easily readable.
    • Documentation is the code. Good codes means lesser documentation. Let the codes speak for itself.
    • Your character reflect your coding. Good Agile coder emphasis quality deliverable and “do it right the first time” mentality.

    In short, Agile requires high level of code quality due to speed and ease of change. While this is often neglected, do be mindful that this is reflected to the next Agile coder. You will not want to make me turn my head and vomit reading your codes.

  • Definition of Done

    Today, I am convinced that the definition of done is harder than I thought. For those familiar with Scrum and Agile, you should know this term well. Many are faced with the expectation of Done from different perspectives. This is a quick tip to define what is “Done”.

    Checklist to define Done
    • Done is a matter of perspective. Recognise differences and compromise.
    • You need to decide and quantify Done.
    • Communicate and set clear checkpoints to arrive at a common Done.
    • Add duration to Done. A long duration to Done may not be Done.
    • Involve key stakeholders and be careful of noise that will cloud Done.

    I am pulling my hair to complete some “Done” work from my ….Grrr!