How we move to agile practice

One of the key revolutionary of Agile Practice is to make software delivery more success via interactive feedback loop. In the nutshell, most of the software failure comes from lack of adaptability on user need and requirement. The fact is that users, most of the time, seldom have a concrete picture of the final products and we, as the software builder, often make a lot of assumption about it. As the consequence, to please customer demands for unreasonable change request cause disaster on our initial design and dramatic efforts to adjust. As the consequence, we fail to deliver the project with initial plan, even if all the contingency budget are all used-up. That is a kind of short stories for such a broad topic. If you are interested in digging more on reason why software is failed, you can refer to here.

Back to our main topic of this post, I found it be quite excited to share our special journey. For me, the outcome is determined but the process is exciting part. We should keep challenge the odd and make the process be flexible to work for us. Each of us would have different journey because the uniqueness of individual situation.

Some background on our team. We are not product or software delivery. Instead, we are mixed of 80% operational work and 20% of development related, for the time being. It’s kind of DevOps mixture but it’s not exactly the same. To some extend, i believe we are unique 🙂

The journey started in February 2016. Initially, I led a team of three members performing much of development and Enterprise Drug Data Migration (EDDM). And then I took over entire Data Production Team so the team size has been merged to total of seven people. The team role is to support the entire Digital Products in term of Data deliveries or integration.

In term of agile movement, the key milestones for 2016 and 2017 are briefly described as below:

The confluence is still being well kept as part of tasks document by individual team member. The key idea is to capture 1) what is the pending work each individual yet to complete or wish to complete and 2) pragmatically documenting and planning for a successful work day.

Confluence is well-served us as the documentation flat-form hence we still retain its usage for the year to come. But those related to work tasks would be move to JIRA flat form accordingly.

Following is the overview of processes that have been done in our agile transformation journey. It’s a quick overview but I promise to elaborate in details for coming post in this series. Each of the step process embodies a series of deep review and experiment that tailor the practice to suit for us. Again, it’s our unique journey. But I hope to give away some important point on the process of thinking and decision making.

Key take away:

• It’s a journey and it’s important to determine the core change element before you start
• Deliberately and patiently move thing forward. You need to get yourself ready to keep repeating your points and have faith in people.
• It takes time to see some improvement. And it must come from people’s action and response

It’s time to say good bye and looking forward to see  you again!

Cheers,
Mike

Data Structure – Part 1: An introduction

1. Introduction to Data Structure

Data structures are essential part of any programming language that provide a way to organize the data for the program in a way that is efficient and easy to use.

It allows us to perform three basic operation on the data which are adding, accessing and modifying.

Each data structure is designed to be good at one kind of usage pattern, often at the expense of another

The decision of which data structure to use is based on the analysis of how the data is likely to be used.

Following is an overview of data structures which are discussed in details in this series

2. Big O

It’s a kind of framework for analyzing performance, that gives us a sense of how many steps it will take to complete a task or algorithm.

For example, following code result in function of O(n) called “linear time” since it will be executed n times.

//Compute n factorial n!
int NFactorial(int n) 
{
     int result = 1;
     for (int i = n; i > 0; i--)
     {
          result *= i;
     }
     return result;
}

Here are several common running times and their Big O notation, order from fastest to lowest:

Constant time	O(1)
Log n time	O(Log(n))
Linear time	O(n)
Quadratic time	O(n2)
Factorial time	O(n!)

Note:

• When expressing a function’s running time in Big O, only the most significant term of the function is written. E.g. O(n^2 + 2n + 1) = O(n^2)

In general, there are two approaches to complete a certain task

Approach	Consideration
Brute force	Useful with small data sets which doesn’t require any set-up cost
Clever	Useful with big data set in which the hidden costs due to set-up is worthwhile

3. Generic

Generics provide a way to reuse code while still having type safety. Generic was added since C# 2.0.

The <T> bit means a class is a generic class, specialized on some type that will be called T, when someone comes along to use our class, they replace the T with the type whey want.

Code example

class MyGeneric<T> 
{
    private T data;
    public T Data
    {
         get { return data; }
         set { data = value; }
    }
}

MyGeneric<int> data1 = new MyGeneric<int>();
data1.Data = 10;

MyGeneric<string> data2 = new MyGeneric<string>();
data2.Data = "This is awsome!"

To be continued…