Effective Communication

Sharon-Zeev-Poole-Why-effective-communication-is-the-most-important-business-skill

Better to be looked over than it is to be overlooked

Communication is not just what you’ve got to say, but also how you package it. In other words, effective communicator delivers his message in a tactful manner. In this article, I’d like to share some tips I am learning during the journey of becoming an effective communicator. It’s certain that you could do the same given enough patience, learning and practice.

Tip 1: Know what you want to say

Good communicator often plan what they way to say before actually saying it. They start with writing an outline. They ask themselves “Does this get across whatever I’m trying to say”. And they continue refine the message until it does.

Tip 2: Know your audience 

WISDOM strategy is associated with six questions that would help to better understand your audience.

  • What do you want the audience to learn ?
  • What is their Interest in what you’ve got to say ?
  • How Sophisticated are they ?
  • How much Details do they want ?
  • Whom do you want to Own the information ?
  • How can you Motivate them to listen to you ?

Tip 3: Choose your movement 

Before communicate to someone, especially if you are asking for a favor or the person you communicate to is a powerful and busy person, you should take time to workout what their priorities are.

Then following by timing it properly. Please avoid ‘confronting approach’ by stopping someone while they are rushing. Instead,  you should come when he or she is relax and less busy.

Remember,  you should always start by asking “is it a good time to talk about … “.

Tip 5: Involve your audience

Engaging the audience in early draft would enable building good working relationship that often produce a better outcome.

Imaging if you are preparing a presentation or business proposal and you know that the audiences would like to make some decision during your presentation. You certainly don’t want to surprise them. Instead, you want their agreement and approval event before the meeting start. You can achieve your desired outcome by proactively building a good working relationship with your audience in the beginning.

Tip 6: Be active listener 

If you don’t listen to them, they don’t listen to you. So, it’s wisely to choose to listen to people first and stay engaging and actively listening.

Tip 7: Get back to people 

During the discussion, if there is any thing you are unsure or not knowing, you can say “I will get back to you later”. And you must, right after the meeting, find out exactly what it was and email or arrange a short discussion with the audiences.

I hope you find those tips be helpful for you. Until we meet again, keep learning and growing.

 

 

 

Great Questions on Scalability

The definition

Scalability is one of the biggest architectural concerns in modern software developments. In technical term, scalability enables a system to gracefully respond to the demands that are placed upon it, e.g. storage IO, database access, CPU utilization, memory utilization , App servers farms and network utilization are most common area requires scalability attention.

The challenges

In my experience, when designing or even developing a scalable solution, it’s difficult to make the right prediction on the demand for the future system and the potential area of optimization. Those are coming through the real experiences upon the system being up and running in production and being used and assessed by users.

It is arguable.

As the architect whom are responsible of the scalable design and solutions, we must plan in scalability as part of the development and deliverable cycle. It could be achieved by chunking, testing and details monitoring to validate the system behaviors.

The options

Two most common options for scalability are scale-up and scale-out. Scale-up means to buy bigger hardware. Scale out means to have multiple sets of hardware that can response to the same requests.

In my early career, the scale-up is often the favorite choices because it provide full control and ownership the the hardware and, most importantly, it is usually budgeted. Not even virtualization of VM concept was employed yet since the technology is not so popular. Then after cloud was introduced in latest 2008, there is a momentum shift to scale-out option which is more cost effective. Why? It simply allows to start small and add system resources as the demand for system’s capability increases overtime.

The questions

Now it comes to the most interesting part of this article: the area need to consider when designing and implementing scalable solutions. For me, I like to ask questions because I often have different answers sometime that interest me and cultivate my interest to ask more. So, here they are.

1. How many users (online and batch) will concurrently access the system ?

2. How much data will the system be able to manage ?

3.  How many read / write operations per second does the data store need to handle ?

4. What is the peak concurrency access to the system ?

5. How much data can be cached to minimize the depth within the system that the requests need to travel before being responded to ?

  • Can data be cached outside the system in content distribution network (CDN) to help to keep traffic away from site ?
  • Is it worth caching ?

6. Is data replication required for the system ? How long is it acceptable for the data synchronization to take place ?

7. How much logging and events are required to the system to support the operational needs of the system, for now and future performance analysis ?

8. Are there area of data contention ?

9. Are the CPU intensive operations ?

10. How do you plan to measure usage of the system ?

11. Do you plan to meter services to throttle excessive usage ?

12. Do you have ability to auto-provision additional servers to meet the demand ?

13. Can you schedule batch operations to occur at non-peak times ?

I leave it for you, the readers, to decide which questions are most important for you.

The practice

For me, it is important to setup the set of rules and alert so that key personnel will be notified upon certain threshold, in related to system performance. For example, the operational warning for operation team will be triggered upon system resource reaching 80% utilization. If it is over 90%, the urgent notification is needed. And action to be taken to resolve the problem. I love the idea of auto provision base on system usage, it is fully automated and greatly improve the system performance. It is certainly that the rule for demolishing those underutilized VM or instance should be set.

The takeaway

The key to scalability is to test and validate our assumption about system behavior. It is to drive system pass its limit to the breaking points so that we could find out how system fails under load.

Great Questions to Decide on a Technology

As Tech Lead or Software Architect, we need to know what technology currently available and what they are capable of doing. We can’t possibly know everything, but we need to be broadly familiar with nearly ALL of it. We have to always live with passion about technology as an adventurer. Constantly we need to choose a new technology in order to increase the odd of resolving existing problems at hand. Great! So, what should we ask first before jumping in?

Following questions are the ones I collected and constantly used:

Question 1: What type of apps is the technology being used for ? Are other areas within our industry using it ?

Question 2: What problem does it solve ?

  • Does the technology align with our product development needs?
  • What percentage of capacities will you use it ?
    • If it’s relatively low percentage, do you have clear justification for its worth since there is extra overhead involved (e.g. paying significant amount and resource)

Question 3: What problems does it introduce ?

  • It is important to understand the operational impacts the technology will have on our organisation.

Question 4: Where are people struggling when they implement it ?

Question 5: Is there good online support ? Does it have active community ? Can we find the information about it in Stackoverflow ?

  • We need strong community when the real issue arise and need to be be resolved fast.

Question 6: Is there active development around the technology ? Any growing level of interest in it from company or community ?

Question 7: What are the alternative ? Where is it going and does that align with where we anticipate the business going ?

Question 8: Does it have a road map ?

  • Where is it going ?
  • Does it align with where we anticipate our business growing ?

Question 9: Are there books written about it ?

Question 10: What revision is it ? Has it gone beyond a 1.0 release ?

  • Using a technology before a 1.0 release can be very tricky when things go wrong.

Question 11: What are the cost associated with it ?

  • One-time charge ? or per user or computing power ?
  • It’s important to know it before trying to sell it to business

Question 12: What are the licensing implications ?

  • Di they affect our intellectual property or the ability to charge for our product ?
  • We need to understand the licensing impacts on our business in term of our ability to generate revenue and how it limits us

In retrospect, I found those questions extremely useful in affirming a right decision and stop a wrong choice from being made. Often I used it to identify the mistake that I made so that I could improve my future decision making.

Last but not lease, picking up and learning new technology is always very appealing to us as Software Architect or Tech Lead. But we must remember that technology needs to be appropriate for the problems at hand.

Design Patterns and TDD : SOLID Approach to Development (Intro)

I am strong believer in TDD as an effective approach to modern software development. For new feature, it is like a dose of clarity for any ambiguity  requirements or assumption that us as developer use to made. It’s critically important for any extension of existing features that make us feel safe with backup of comprehensive tests cases. In a way, it encourages us to make change and provides intuitive approaches to solve and guard the those changes from any defect.

I could spend thousand words to continue on TDD pros and cons but it is not the focus of this article as well as subsequent ones in this series.  So let adjust the the zoom, shall we.

As developer, I believe we are all aware of SOLID practice, design pattern, TDD and so on. It is practical CS knowledge in real world. However, I believe many of us have been struggling in the application of these knowledge. I mean really use it in day to day work and develop a way of thinking. For me, I find coding practices is like martial art practices or any other sport require regular muscle exercise. I must constantly do it on daily basic. The more I do, the more automated behavior I developed, the more automatic thinking in practical way I become, the less I need to think about it. The key point I want to make is that we should make it as part of our habit so that we don’t have to think about it when we perform any coding activity, we just do it naturally.

Having that in mind, I plan to develop a series of Design Patterns and TDD practice that I will cover all 23 design patterns, its implementation and lots of practical example of using in the the real world project both individually and mixtures of a few pattern. It will take a few months for me to finish this off. Looking at the ending encourages me, why? because i believe it will help me and you to be a better developer.

This series code has been published regularly to Github as https://github.com/mikenguyen69/design-pattern-code-sample. Feel free to check it out and modify or contribute our further enhancement on real world application. The initial version is in C# .NET (7.0). Upon finishing, it will be extent to another popular language such as Go or JS.

Following are the list of topic that covers in sub-sequence articles in this series.

Part 1: Creation Design Patterns

  1. Abstract Factory
  2. Builder
  3. Factory Method
  4. Singleton
  5. Prototype

Part 2: Structural Design Patterns

  1. Adapter
  2. Composite
  3. Decorator
  4. Bridge
  5. Facade
  6. Flyweight
  7. Proxy

Part 3.1 Behavior Design Patterns

  1. Command
  2. Strategy
  3. Observer
  4. State
  5. Visitor

Part 3.2 Behavior Design Patterns

  1. Template Method
  2. Chain of Responsibility
  3. Mediator
  4. Iterator
  5. Interpreter
  6. Memento

Stay tune until we meet again 😉