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

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.

Advertisements

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 »

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 »

Most of the days, we wake up in the morning, brush our teeth, wash face, have a brief breakfast and rush out to work. But, there are some special mornings. When we open our eyes, we start to see the world differently. This morning is one of such for me.

Maybe I have stayed in the development department in a big organization for too long. I was so used to the layback, slow-moving, stable, orderly working style. So, when I had the opportunity to go through a demo session of a competitor’s application yesterday, I was completely shocked, not only by the application, but also by the attitude they treat their work.

We developed our application in a typical “elegant” way of big organization. And they developed their application like a “startup” company.The differences are in sharp contrast. I listed some here:

  • We wait for the requirements being given to us by other departments like Sales or Marketing vs. They go out to talk to frontline Sale people and to customers directly, for example in the trade show, to figure out the requirements firsthand.
  • We are proud of the technologies we used and focus on latest and advanced technologies vs. They are proud of the product itself and focus on how it can satisfy customer needs.
  • We focus on internal architecture design and build for last vs. They focus user interfaces and usability and build to sell.
  • We live with the legacy system and spend a lot of time integrating with it vs. They completely write all the logics in contemporary technologies.
  • We value stability vs. They value innovation
  • We limit our releases per year vs. They release much more frequently
  • We only serve one customer, our business vs. They look for opportunities inside and outside the organization
  • We have never been worried about “selling” our product. We assume the business would take care of it and Sales people will sell it vs. They constantly promot their idea and product to the business. They made the business realize how great their product was by doing the demo, comparing the features and showing the statistics numbers.

It’s a typical example of “fast vs. slow”. In current business environment, the one who can sense the changes ahead of others and quickly adjust itself for the changes will survive.We witness more and more triumphs of the “internal marketing” or “project marketing”. Although we ARE the internal development department, we have to realize the business has choices nowadays. We cannot assume that we are the sole service providers available to the business and they will eat whatever we feed them. Those old golden days for IT are gone!

Business is business. If you would like to survive, you have to go out there and compete. You must build the best product in the market, and constantly market your service to the business leaders. If you don’t do that, the competitors from any corner of the world can come and replace you. So, wake up you old development! Time to act like a young startup now!

November 2017
M T W T F S S
« Dec    
 12345
6789101112
13141516171819
20212223242526
27282930  

Blog Stats

  • 59,873 hits