You are currently browsing the category archive for the ‘Software Development’ category.


Ever since project management was introduced to IT field, our lives as software development professionals have been scheduled around Projects. We literately are living with Projects. After we are done with one project, the next one comes. Or even better, the next one comes before the previous one finishes. If we are not doing a project, we must be busy planning for the next project. While we are so buried in the coming and going projects, it’s a good chance that we have missed the whole picture.


So, what’s a Project any way?

The official definition by Project Management Institution: A project is a temporary endeavor undertaken to create a unique product, service or result.

A project has the following characteristics:

  • Temporary
  • Have definite beginning and end
  • Create unique product or service
  • Have objective that indicate completion
  • Progressive Elaboration

By nature, a project is a temporary endeavor. Ultimately, it’s just the “means” not the goal. It takes us from one place to another. But, it’s the journey, not the destiny.


What’s the destiny, then? What’s the core? What’s the not-so-temporary thing in our work?

That’s the Product or more specifically, the Software Application, in software/IT industry.

A Product Development Team is responsible to create and continuously improve a software application that serves some meaningful business purposes.

A product/software application has its own life cycle:

  • Initial creation: from non-exist to the first Production release
  • Continuous improvements: as long as a product has users, it requires continuously maintenance (bug fixes) and improvements (new features)
  • Termination: just as anything concrete, a product may die, meaning users cease to use it. It maybe because the company goes out of business or simply because it’s replaced with another better Product.

The Projects happen in between a Product’s life cycle. We may have projects to initially design the database and the architecture. There maybe other maintenance projects to adding new features or doing refactory for the existing architecture. A formal termination/transition project may exist just to transfer the data out the phrasing out application to the new application.

Next time, when we think of the projects we are doing now, we can also think about the Product behinds it and where in the lifecycle of that Production this project fits in. That will help us better understand the goals of the current project.


Matter of fact, when we think deeper, handing out the application to the users is hardly the only thing we do. We also spend a lot of our time doing the following:

  • Deploy, Configure and Host the application
  • Technical Support
  • Document/Training
  • Manage the capacity
  • Manage the availability
  • Manage the service level
  • Manage the security
  • Manage the business continuity (disaster recovery)

In short, we provide a full spectrum of IT services to our users. And users actually evaluate us by all the services we provide not just by the Product (software application) we deliver.

So, it’s time to think what kind of Services we would like to provide to our business users. Then determine what kind of Products we need to deliver. Eventually, we will get to the Projects we need to accomplish to deliver the Product and/or the Service.

After all, it’s the IT Services we delivered that matters to our users, not the projects we are working on. Projects are just the tool we use to organize our work in order to provide better Services.

Jumping out of the boxes of the Projects, we will eventually find a wild wide world of Services, waiting for us to explore!

I still remembered clearly of one of my job interviews. The interviewer was a development manager and I was applying for the position of a Software Architect. We had some random talks just to break the ice. Then, out of blue, he asked me, “So, you are an Architect. Would you please tell me what the most important features of a good software architecture are?” A millions of ideas were flying around in my mind. My answer on the spot was “Simplicity and maintainability” since I have been in charge of maintaining and continuous development of an application for years before the interview. Most of my frustrations have been the results of the initial designs not considering the future extensions of both the functions and the scalability of the system.

After the interview, I have been pondering around this question again and again and found that there is no single good answer to that question. It really depends on the circumstances.

A good architecture design should at least consider the following three groups of features:

Group 1: Functional

  • Functionality
  • Usability

Group 2: Non-Functional

  • Flexibility/Extendibility
  • Maintainability/Simplicity
  • Scalability
  • Robustness
  • Availability
  • Performance
  • Security

Group 3: Project level

  • Cost efficiency
  • Time to the market

The non-functional features are most neglected ones, especially in the inception phrase. The clients and the business users usually focus on functions and when they can get it with how much cost. Usually, they won’t think of non-functional specs like availability or scalability at the beginning.

However, neglecting those non-functional aspects of the architecture can have dire consequences after the application is deployed and up running. It usually will cost 10 times as much in maintenance to reverse the mistakes made in the initial design.

To add more complexities, some of the features are against each other, e.g.

  • Flexibility vs. Maintainability
  • Scalability vs. Performance
  • Security vs. Usability
  • Robustness vs. Flexibility

Essentially you cannot design a system that’s perfect in all aspects since one aspect’s gain may come at the cost of the other aspect.

So, a good software architect should keep all the above aspects in mind when designing a software product. He must strike a balance among those aspects to achieve the optimized result.

But, how to walk on the thin line?

Here are some tips:

  • Understand requirements: Extend beyond the functional aspects to non-functional aspects.
  • Reasonably project/predict the future: Imagine how this application will be deployed, who will use it and what the usage patterns are. How fast the product may sell in the market?
  • Build in the flexibility but not too much: If the future is hard to predict, at least give yourself some leeway to build some flexibilities to handle the uncertainty. But, don’t overdo. Architects tends to design too many abstract layers just for flexibility. Do try to suppress that urge and maintain a good sense of simplicity in the design.
  • Continuous improvement: Circumstances change all the time. Nobody can precisely predict the future. So, do revisit the design periodically based on the ever-changing reality.

I always consider software architecture design is a work of art. It requires not only technical knowledge and skills but also a sensitive mind to capture the reality and reflect that in the design. A software architect is always walking on a thin line trying to achieve the balance among competing forces. So, a well-designed piece of software product is well worth appreciation and respect, just like any master pieces we saw in a museum.

An opportunity to manage an existing software development team opened up in another city. Due to personal reasons, I cannot make the move. However, it triggered me to think what I should do if I am asked to take a lead on a new development team.

Leading an existing team is absolutely harder than building a new team up from scratch. The big difference is the trust between you and your teammates basically doesn’t exist at all. Nor does the trust between you and your partners from sales, service, technical support and other IT teams like analysts, testing and deployment.

All you can build upon is the chemistry between you and your hiring manager. He/she must have some deep confidence in you otherwise he/she won’t hire you to do the job. However, if that trust is built upon the first impression established through reading your resume and briefly talking to you in the interview, it can turn sour pretty quickly if things are not going on well. You are also facing the risk of losing your hiring manager suddenly and completely due to some reorganization, which is common in big enterprises.

I have witnessed a dozen or so new managers come and go leaving no trace. This is definitely dangerous water even for experienced navigators. Don’t imagine you will quickly shine as much as you did in the old familiar post. We all have to realize that our current success is built upon years of hard works and good relationships we established over a long period of time.

So, what will I do if I have to take the hat as the manager of a new team? How to secure the success of the new team? I will do it in three phrases.

Phrase 1: Learn and Understand

The important thing to keep in mind is that things are different! All dev teams are different in three perspectives: People, Process and Technologies.

People is the most important factor in the equation. There are three groups of people critical to get my job done. My boss/manager, my peers and my team mates. They are EQUALLY important. Yes, my boss can hire and fire me. No doubt, he/she is important. But, my peers, the managers of the analysts team, the QA team, the deployment team, the sales, marketing, service, technical support, hosting center, network engineering, other applications teams we need to integrate with, can also determine if my day will end up with smooth humming or frustrating yelling. And my team mates, they are the key performers. There is not much one people can achieve but for a team, there is no limits. By the way, my team mates are more familiar with the product, the process and the technologies than I do. They are the residents and I am the new comer.

There are many things to be understood about people. I will start with understanding their motives (what makes them come to work everyday) and their priorities (career, family, or self-realization, etc.) first. Then, how do them prefer to communicate, verbally (face to face/phone) or written (email, messaging, etc.) and what’s their communication style, casual or formal. For my team mates, I will go deeper. I would like to understand their strengths. One of my former bosses asked me to take a test of StrengthFinder 2.0 to discover the 5 strengths I have. I found that useful both to me and him. It won’t hurt to get up close and personal like knowing the educational background, the families, kids’ names and birthday, favorite sports team, etc. All those will set the great foundation of strong future relationships.

To understand the Process, I will follow through the application life cycles, from requirement, development, test to deployment, operation and optimize. Along this cycle, I will understand which team is involved, who is the head of that team, what tool is used, who maintain that tool, where are the documents, how products (new build) goes from one step to the next. There may be some vertical processes like budgeting, security, availability, capacity, service continuity (disaster recovery) to be understood.

One thing worth taking note is the current stage of the product. Managing a product that has never been released to Production and a well established Product in maintenance mode is fundamentally different.

As a development manager, the technologies details are not as important as the people and the process. So, I won’t drill down into all the nuts and bolts of the application. But, I must know all the business functions of the product, all the internal modules, their relationship, who the domain expert for each module is and all the external touch points.

Those above are all basic homework for a new development manager. Besides that, I will specifically understand the following:

  • Goals/Expectations: What to achieve in what time frame?
  • Challenges/Problems: What are the problematic areas? What are people constantly complaining about? What make the developers’ life miserable? Where are the mines and traps?
  • Image: How do my boss and partners see my team? If negatively, why?

This phrase may take several weeks to several months depending on how big the team and how complicate the process and organizational structure is. I will definitely have a talk with my new boss to get his/her agreement first. I will refrain from making any big changes in this period. Maintaining the “business as usual” status will be the best.

If the team or the product is in bad shape before I take the lead, this period may post a challenge. I may feel a lot of pressures to make quick moves to show some improvements. Then, this phrase must be shorten or may be combined with the second phrase.

Phrase 2: Build Trust

I strongly believe that productive works can only be produced by good team work. Good team work comes out of Trust. Lacking of trust will end up with all the internal barriers, unnecessary power struggles, finger pointing and inefficient communications.

But, as I realized already, a new development manager doesn’t enjoy the luxury of trust in the new poison. So, the next logical thing to work on is to build up trust.

First thing to do is to show people I really care. Reaching out to everybody in Phrase 1 and trying to understand them is a positive message to demonstrate I care. I will take one step further to show people I care by communicating back to them about my understandings of their expectations, their priorities, and maybe their frustrations too. Along with that, I will show my intentions to work with them in finding the solutions.

Next step, I will demonstrate that I am trustworthy. I can deliver what I promise.

To do that, I will pick the lowest hanging fruit with the highest priority. There is a simple formula to identify that specific area, Visibility = Business Value X Impact / Previous Performance. That means this area delivers enormous value to our customer, has significant impact not only to our customer’s experience but also to our partners’ performance, but previously the team either neglected or did a lousy job. Improvement in this area will have the biggest visibility and can help turning around the negative image of my team.

Once this area is identified, I will do the following:

  • Define the goal

Based on the understanding of the expectations, I will set the short term and the long term goal for this area. This goal must be S.M.A.R.T. (Specific, Measurable, Achievable, Realistic and Time-bound). More details about goal-setting can be found in a previous blog of mine.

  • Establish the measurements

Measurement is always the first step to achieve a goal, which must be measurable. Without the measurement, I cannot prove to anybody that our team makes some progress in this area towards the predefined goal.

The measurement should be Key Performance Indicators for this area. For example, for availability, it should be percentage of system availability, for development efficiency, it should be number of features/bug fixes in each release, for problem management, it should be number of production issues, etc.

The measurements must be published periodically, every month, every three months or every release. It should be distributed to all the concerned parties, not limited to IT department. The more external pressure, the more motivations to improve the measurements towards the goal.

All the measurements come with some management costs. So, I will prefer automatic measurements coming out of some tools or software programs. That will guarantee the objectiveness of the measurement and also cut the management costs.

  • Find the path

Goals set. Measurements published. Baseline established. Expectations sky-high. Pressures piled up. How to deliver?

I can drill upon my previous experiences and my technology know-how. But, that won’t be enough and won’t be efficient.

The key here is to release the creative talents of my teammates. It’s not about myself. It’s always about the team. It’s about establishing the new image of the team.

They know the system better than I do. They know the processes better than I do. They already know how to fix the problems! From my years of experience in IT industry, I can safely bet my money on it that somebody in the team already knows where the problem is and how to fix it. They are either not willing to bring up their ideas or they haven’t been giving the opportunity to express themselves.

I will setup several brainstorm sessions and a lot of one-on-one conversations with all my teammates to find out the right path to achieve the goal.

It’s very important that the entire team will feel he/she is involved in defining the path, the solution. It will be their personal success too if we succeed as a team. Any bright solution will fall apart badly without the whole-hearted support from the team. There will be different ideas and maybe fierce debates. People with lower voice volume may feel left out or rejected. It’s my responsibility to make sure everybody feel their voice is heard and seriously considered. To broker such a consensus is a true challenge of my leadership.

Eventually, we will have a plan, a roadmap to achieve the goal. I will have one or two backup plans in case the first one didn’t work out. I will communicate the plan(s) out to all the stakeholders to get their buy-in.

  • Improve iteratively

I am not a believer of luck. All the achievements are results of continuous hard works. So, I will never expect to achieve the high-shooting goal in short period of time. That’s cheating. I will break down the long term goal into small achievable steps. Each is just a hand’s reach from the previous one.

I will work with my teammates to carry out the plan we determined. Things may go wrong. We may have to put in some long hours. So be it.

But, I won’t stick to the plan without flexibility. A plan is just a plan, a reference and a guide. I will periodically measure our progress to see if we are on the right track towards the goal or we are heading the wrong direction. As a team, we will constantly revisit the plan according to our progresses and modify the plan if necessary.

If we fail to achieve intermediate goal, we will admit honestly to the stakeholders. Give them our honest understandings of the reasons for the failure and the remedy plans. I will always remember building trust is more important than actually achieving the goal. I won’t risk losing the trust to cover up a mistake.

I believe we as a team can make significant difference by focusing on one specific area and by go through goal and measurement setting, path finding and iterative improvements.

Delivering what we promise to our partners constantly will build up the trust level. In the process of delivering, I will also build up the trust among the team. As a team, we can work together to deliver some outstanding results. That positive feedback is essential to the team-building effort.

Phrase 3: Continuous Improvement

After the initial success and the sense of establishment, I will move forward to make some adjustments that have long lasting results.

I believe the impressive Productivity come from good Practices. Good Practices come from good Processes. Good Processes come from the good Cultures.

If I would like to get some short term achievements, I will focus on Practices. If I would like to establish some long-lasting results, I will focus on changing the Cultures and Processes.

I have written some blogs about the ideal cultures for a development organization including goal-oriented, innovation and humanism. I will add continuous improvement to the equation. Continuously improvement means never being satisfied at the current status and always thinking of how to make further improvements to get better results. Time goes by. Change is constant. Any good design or smart policies will soon be obsolete. Contemplating on the previous successes leads to future failures for certain. Only team seeking for continuous improvement can continuously stay current and relevant.

The ideal cultures can only be cultivated by establishing the aligning processes and policies. For a development team, the processes determine our everyday activities e.g. coding, source control, deployment, testing, production support, performance tuning, capacity planning, etc. In my experience, the ineffective and inefficient processes attribute to most of the problems of the development teams.

There is no one recipe for all the development teams. The industry standards, such as ITIL, PMP, RUP or Agile, can be used as references. But each development manager must determine the right processes for the development team according to the size of the team, the mix of the team members, the available skill sets, the external requirements, the available toolsets, etc. Establishing the right processes is another delivery iteration requiring goal setting, path finding and continuous improvements.

Besides achieving the external goals for the business, I will put people development at the same importance. The output of the team is the sum of the output of the individuals in the team. Developing my team members is the most efficient way to improve the productivity of the team. But, more importantly, helping other people achieving their life goals is the most rewarding thing I can think of.

In a team I worked before, all the team members were required to attend an educational course of “The 7 habits”. The course was based on Steven Covey’s best seller book, “The 7 habits of the most effective people”. I personally benefit tremendously from that book. I will encourage my team member to either read the book or attend that course.

I will start with understanding the career goals of my team mates and help them achieve their goals. I will help each of my team members to build a career development plan and assist them to achieve their career goals with their every day works. The best way to achieve that is by empowering them. They should gradually cultivate the capabilities to make independent decisions in the areas they are responsible for and I will make sure those areas expand as their capabilities grow. Eventually, I would like to see one or more of my teammates can fully take over my job with the same effectiveness and efficiency. That will be the celebration time for me and the time for me to move on to new challenges.

Leading an unfamiliar team is no doubt a challenge for anybody. But, it can also be rewarding. The uncertainty and the new challenges are the things that make the experience exciting and worth expecting. I am confident that I can make a difference by going through steps of understanding, building trust and continuous improvements. I am looking forward for future opportunities to put through those ideas into actions. And opportunity only favors prepared minds.


Serving in an IT department of a non-IT company, I learned over the years one or two things about our business partners, who are our best friend and patrons, at the same time our ultimate source of headaches.

Bittersweet Partnership

After all, my job is to help them to be successful in their fields, in Sales, Marketing, Finance or Service. In a sense, IT department exists only because our business partners need us. And we need them too, to define the requirements and specs, to decide about the business logics, to promote the products we developed, to sponsor our projects, to give us feedbacks for improvements, etc. So, it’s truly a partnership.

However, we constantly fight with our business partners. They want too much from us within unrealistic short time. We insist on an absolutely necessary infrastructure change they don’t understand and consider too risky. We are furious that they keep changing their mind about the requirements in the last minute. They are bitter about the delay of the new release. This list can go on and on.

Read the rest of this entry »

re-invent the wheel gifts, re-invent the wheel gift, re-invent the wheel merchandise, gifts for re-invent the wheel, gift for re-invent the wheel

In the recent town-hall meeting, our vice president of application development mentioned that in her experience, usually applications will only become great in their version 3.0. That’s in terms of feature richness, usability, stability and performance.

This insight fits well with my own experience and observation. The implications are developers are spending a lot of their times doing re-factory, which means rewriting the underline implementations for the existing functions.

At the first glance, re-factory seems to be an awful thing: tedious, time-wasting, boring, but unavoidable. However, if we really want to tame this beast, we need to take a deep look at its origins and natures. And it may come out as a necessary and valuable way to improve the quality and the business values of our applications.

Read the rest of this entry »

At the days when the first computer was designed in 1940s, the software development business was born. It has been evolving fast and furiously ever since that.

Talking of software development, we, developers, will immediately think of programming languages like C++ or Java or their ancestors like FORTRAN or COBOL. Programming with those languages, or “coding”, is at the center of our software development career.

However, several new software development trends started to threaten the crown position of “coding” in the kingdom of Software Development.



Read the rest of this entry »

The Chinese colleagues in my organization usually go out every Monday to have lunch in a nearby Chinese restaurant. It’s a good time to share some common concerns about the economy, the stock market or the food security in China. Topics like work or technologies seldom emerge in the lunch discussion, unless somebody start the complaint, like what happened this Monday.

One of my colleagues complained that he spent hours trying to decipher the myth that some messages failed in processing with no reason in Production environment. Eventually, he found out the deploy team rolled out a new server last weekend, which was not configured correctly. The new server, participating in a cluster, grasped some of the messages and failed them. That explained why only some messages failed while other went through successfully.

But, why did it take him so long to figure it out? Two reasons, first of all, he wasn’t aware of the environment change (roll out of new server). Second, there weren’t enough logs to show which server processed the messages. He was browsing through the logs of all the known servers trying to find traces of the failure, with no luck. If there are some central logs or database records showing which server in the cluster processed the message, the error will be obvious.

Read the rest of this entry »

I talked about the two most important cultures for a development organization, Goal Oriented and Innovation in my previous two posts. For a development organization to survive, it must satisfy the goals of the business it belongs to. It must align all its activities with the business goals and strive to achieve those goals. If the development organization would like to play a more important role in the business than just providing “commodity” technical services, it must continuously innovate in technologies and processes, in development process as well as the business processes.

But how can a development organization achieves its preset goals and how can it innovate? What’s the ultimate strength of a development organization? Not the thousands of computers it possessed and managed, not the technologies it embraced, not products or services it delivered, or the intellectual properties it possessed. I can be one hundred percent sure to say that the core competitive advantage a development organization has is its people. People are the most important resource that a development organization can draw upon to meet any ambitious goals it may have. Innovations are like springs, flowing freely to all directions. But, if we seek its origin, we will always find one or several highly educated, talented and engaged persons. Thus comes our third ideal culture:

Ideal Culture Number Three: Humanism

Read the rest of this entry »

As a developer and later a technical architect, I have been doing software development for almost nine years after I graduated from school. I witnessed the fast evolvement of new technologies, for example, from Java Applet in the early days to AJAX recently in front end field and from EJB to Spring in the business logics field. However, the process we do software development changes much slower. In one organization, the same process is usually used for all types of projects, from new and complicate multi-year projects to simple and repetitive bug fix releases. I feel the knowledge we have in software development processes are way behind the knowledge we have in technologies. To me, the software development process and methodologies are more fundamental and important than specific technologies. Because it affects the entire lifecycle of software development project, the entire software development team and every aspects of the software product.

Read the rest of this entry »

If you put your heads down working in the enterprise applications for a large organization for many years, you may already missed “what’s hot” in the industry. It’s time to update your knowledge base, and your RESUME with those hot buzz words.

Front End



Read the rest of this entry »

August 2020

Blog Stats

  • 60,395 hits