Hot To Code Quality ...

Today the business world is so dynamic. Expectations, needs and wants of people are changing instantly at non predeterministic unpredictable way. So do the Business Requirements. Hence it is inevitable that the software you develop today will always in need of dynamically changing it's capabilities in order to cater the various changing customer expectations. The challenge is exceptionally high, as in this industry (Software Industry), the technologies are changing even at a faster rate. This back ground paves the way for this article, on the need of writing quality code.  What do you mean by quality code?, why code quality is this so important? And how you write a quality code and what are the areas to think about? Following is a research about the same. 

As provided the dynamic nature of the industry, Software cannot be developed for life time, so that they meet the requirements of everybody for every day.  Therefore once the requirements change for existing customers, or once the existing product is needed for new customers with some modification, the product will have to scale or enhance for new features. When new technologies arise, and when new dependencies are introduced,   when you find bugs and vulnerabilities, you will have to maintain your product for stabilization. In either ways it is part partial that you maintain your product to remain sustain in the business. So code quality is directly involved with the sustain Engineering of any software product. Today many software companies spend millions of money in maintaining their products. Sometimes one would not believe, that generally maintenance cost top your cost structure of annual reports for majority of Software Development Organizations. Therefore " A quality code" is strategically such very important as it is the only sustainable way for your organization to reduce the rocketing maintenance costs.  

Following section will look at the issue from more technical perspective and will reveal some vital concepts to help you develop the code quality.

Generally quality of the code can be qualitatively discussed in terms of the following. 

a)      Readability 
b)      Extensibility 
c)       Reusability 
d)      Maintainability 
e)   Testability
f)      Design time concerns - The open closed principle 

Code reviews are the very famous ways of reviewing the existing code, in order to conform that the code meets above.

Readability

Readability of a code is vital as reading the code is the only way so that the feature enhancement developments, bug fixing, maintenance can be easily carry on. It is an inevitable fact in the software industry that original developers may not stay long with the project, so that the developers, who have the actual familiarity of the code, may not stay prolong for the maintenance cycle. With this tentative nature of employment turnover in  the business, generally software organizations may have to start maintenance work with brand new members who have no previous understanding of the code. More over, only very few small and medium scale organizations would maintain the costly learning organization. (design specs, training documentation,  product documentations,  Proper version control, release management, history logs, etc.) Therefore readability of the code is extremely vital for the reduction of maintenance effort and finally the maintenance costs. Readability meaning the ability to easy understand the code, its logic and the functionality it delivers with minimum effort.  For example, there  may be programming STARs who could write logic in two comprehensive lines, which general average developer may take 20 lines for that. However, the negative impact in such a STAR case is, since there is no compromise, shortening the code naturally enhance the complexity. So do it enhance the maintenance effort. Finally the cost of maintaining such bright code will be high compared to an easy readable code.

How do you enhance the readability? 

Readability improves once you reduce the complexity. Complexity may be due to various reasons. It could even include facts like complexity of the logic, complexity of the implementation, complexity of the math, complexity of the usage of programming language (Lambda functions, recursion, nested logics etc.). I consider reducing complexity is one part of enhancing readability. There are there universal coding practices which could help you to reduce the complexity of the code. Here directly i relate my thoughts to what you find in the web. 

1. Partitioning

A concern should be given to logical and understandable way of modularity considering separation of concerns. Partitioning Reduces the number of factors that have to be dealt with simultaneously.  It narrows the focus of attention. However improperly over partitioned, it could enhance the complexity.

2. Hierarchy 

Directs the span of attention and allows for levels of detail. This aids in the later construction and easy understanding of systems. The shape of the hierarchy is important and should reflect the functionality of the system.

3. Independence
 
The most important idea behind a lot of structured design is "High Module Independence" Objective is not simply partitioning a program into a hierarchy but determining the structure such that each module is as independent of all other modules as possible. Independence is generally achieved by minimizing the relationships between different modules (Coupling) and Maximizing the relationships amongst the elements of a particular module (Strength/Cohesion). The independence terms can be also achieved by making the responsibilities independent.

Following too could be very useful in formulating your ethos for readability. No argument about being DRY.  So you are correct. The concerns here are quite coherent with the primitive three facts I described above. 

• Consistency

Applies to formatting, using braces, naming (variables, classes, methods, good uses of white spaces, refactoring)

• Size

If a function doesn't fit in its entirety on the screen in a normal IDE at a normal font size then you need a pretty darn good reason as to why not. Of course there are some valid cases for much longer functions but they are greatly outweighed by the egregious examples. Decompose as necessary to keep your functions simple.

• Comment Judiciously 

There is a tendency for some programmers to use comments as a substitute for readable code or to simply comment for the sake of commenting (like /* finished */ comments right before return true;. Seriously, what's the point? Most (good) code explains itself. 

• Avoid repetitive codes

If you find yourself writing the same sequence of statements (or very similar) over and over again, abstract or parameterize it. If you see very similar statements the tendency is to skim over them assuming they're all the same (when typically they won't be in a way that matters). DRY: DRY stands for Don’t Repeat Yourself. Also known as DIE: Duplication is Evil. The principle states: “Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.

• Careful when you use frameworks

 For example, when you use certain frame works and their inherent features eg: Autowiring of Spring, the introduced dependencies will make things very hard to understand as such frame works hide some layers of operations in the code. This make very hard to understand the code even for those people who have a good understand on the frame work.

• Avoid Deep Nesting

• Use Short BUT meaningful Names

• Single Responsibility Principle

Break code up into meaningful pieces that accomplish specific purposes.

• Clear Design and Separation of Concerns

Separation of responsibility between components (class, function, etc). This will include Keep your classes cohesive (it all works together) and decoupled (there are few dependencies between classes).  On the other hand this can be described as Separation of Code and Data.  Keeping a good modularity and a meaningful folder structure will also be useful here.

Extensibility

In software engineering, extensibility is a system design principle where the implementation takes into consideration future growth. It is a systemic measure of the ability to extend a system and the level of effort required to implement the extension. Extensions can be through the addition of new functionality or through modification of existing functionality. The central theme is to provide for change while minimizing impact to existing system functions. 

a)  Dependency injection.

Frame Works - provide a reusable context for components 
b) Component Technology (DCOM - Microsoft, SUN - Java Beans) 
c)  Use of Design Patterns 
d) Proper moduleing

Proper moduleing enhance the extendibility as it separates different concerns. 

e)  Separation of interface and implementation

Object-orientation allows us to specify the binding between interface class and implementation class in the following ways 
 i.      Class-based inheritance: whole classes are related by inheritance. The pattern of inheritance is fixed when the classes are created. 
ii.      Delegation: objects can be individually related, enabling each object to make its own decision as to when, and to what, it delegates. The pattern of inheritance can vary dynamically, making delegation a more flexible and powerful way of organizing objects.

Maintainability

Maintainability of the code – Provided the importance of software maintenances and considering the importance of service packs, patches, bug fixes as part of service agreements, or attempts of product stabilization,  here I would focus more on proper documentation, proper release management, proper historical information record and proper versioning on software development than any other fact. The argument is software should well maintainable. In order to track the bugs and the issues, keeping historical records on the releases, is so vital so that developers could easily capture a particular bug to a particular released version or afterwards.  

Reusability

Reusability could be achieved through various concepts that were defined above as well.  However I would also list some concerns below which could be useful when it regards reusability. 

a)    Remove the business logic or main code away from any framework code 
b)   DRY 
c)    Write unit tests for your classes AND make it easy to test classes. (TDD) 
d)    Single responsibility principle 
e)    Try to think more abstractly and use Interfaces and Abstract classes. (dependency injection) 
f)     Reduce coupling 
g)    Be Modular 
h)    SOA Reusability

a.       Services reusability

b.      Services orchestration

c.       Service Automation

Testability

As far as any software project is concerned, testability should be one major design time concern in order to make sure the ultimate functionalities are met. More than that generally large scale software products also  have various test sets, so that before releasing a new version, service pack or, patch, it is a general habit run those vital automated testcases. Orthogonal code design enhance the testability.The things have to consider here include

1. IOC/dependency injection
2. Use of frame works

 Other Design time Concerns - Open Closed principle

The Open Close Principle encourages software developers to design and write code in a fashion that adding new functionality would involve minimal changes to existing code. Most changes will be handled as new methods and new classes. Designs following this principle would result in resilient code which does not break on addition of new functionality.

Must know not just about Software Licenses

We – Software professionals like everybody else down streets know that you need to have license to use licensed software, and you need not license to use open source software. Licensing was not an issue in majority of the Asian part of the world a two three years ago. However even that picture is ridiculously changing now. As project managers who travel across different geographies you must have to know precisely at least different type of license agreements and their respective legal obligations.  

One very confusing area is that terms free software and open source software are used interchangeably. I have borrowed following philosophies related from GNU. “In 1998, some of the people in the free software community began using the term “open source software” instead of “free software” to describe what they do. The term “open source” quickly became associated with a different approach, a different philosophy, different values, and even a different criterion for which licenses are acceptable. The Free Software movement and the Open Source movement are today separate movements with different views and goals, but may be they do work together on some practical projects”. Therefore I believe there is a propaganda based term clash between Open Source vs Free Software founders to demark their territories in the competitive landscape.

The TERM clash - Open Source vs Free Software

1. A free software license Definition

 : is a software license which grants recipients extensive rights to modify and redistribute, which would otherwise be prohibited by copyright law. To qualify as a free software license, the license must grant the rights described in The Free Software Definition or one of the similar definitions based on this.

2. An open-source license Definition

: is a copyright license for computer software that makes the source code available for everyone to use. This allows end users to review and modify the source code for their own customization and/or troubleshooting needs. Open-source licenses are also commonly free, allowing for modification, redistribution, and commercial use without having to pay the original author. Some open-source licenses only permit modification of the source code for personal use or only permit non-commercial redistribution. All such licenses usually have additional restrictions such as a requirement to preserve the name of the authors and a copyright statement within the code. One popular set of free open-source software licenses are those approved by the Open Source Initiative (OSI) based on their Open Source Definition (OSD).

What is important?

Therefore even provided the above definitions I too could not still find a clear difference between Open Source and free Software in terms of the purpose they stand unless otherwise the differentiation of the terms of license granting body. Let’s forget the craps for a moment and see what seriously we really have to know. I have heard, that starting in the early 2000s, number of companies began to publish a portion of their source code to claim they were open source, while keeping key parts closed. This led to the development of the now widely used terms free open-source software and commercial open-source software to distinguish between truly open and hybrid forms of open source. This is such a critical situation where as project managers we have to be careful and understand the legally obligated nature of the license. It says generally Free and open-source licenses generally fall under two categories: Those with the aim to have minimal requirements about how the software can be redistributed (permissive licenses), and those that aim to preserve the freedoms that is given to the users by ensuring that all subsequent users receives those rights (copyleft Licenses). I think this is the point where most writers and speakers deceive us. Knowingly or unknowingly they may be using the term Free Software for the Copyleft license and Open Source for the permissive license. Correct me if I am wrong. 

Copyleft license	Permissive license
Eg: GNU General Public License (GPL) Note: Any modifications made and redistributed by the end-user must include the source code for these, and the license of any derivative work must not put any additional restrictions beyond what GPL allows.	Eg: MIT license (Massachusetts Institute of Technology) BSD license (Berkeley Software Distribution) Note: Gives a user the permission to take the code and use it as part of closed-source software or software released under a proprietary software license.

Figure:  The distinction between Copyleft vs Permissive license

So in brief, the GPL license impacts "derivative works", but the MIT/BSD license does not.  This has huge implications.  If that too complicated - Let's take the following examples.

Code G is GPL licensed.  Code M is MIT licensed.  You wrote X.

You create project GX which contains your code (X) and G.  If you distribute GX (the source or binary) then you have to make GX available (this includes X -- your code -- which you might not have wanted to make available).  Why?  Because if GX is a derivative work, then GX is also licensed under GPL.

Note -- let's now say that someone takes your GX (since you published the source code) and makes GXY (by adding his Y code) -- now if he distributes that code (or binary), then GXY has be licensed under the GPL and the source code has to be made available.  This is a property that some people call "hereditary", other call "viral", and some prefer the pun "copyleft" -- which is the opposite of copyright. 

Let's now create MX which contains your code (X) and M.  If you distribute MX (code or binary) then you have to indicate that part of MX contains MIT licensed code.  But you don't have to say how much of it does, where it is used, how it is used.  You don't have to make X available.  And you can license MX any way you choose. You can license MX under MIT if you want, and publish it.  You can also license MX under GPL -- (you'd be licensing MX, but not altering the license of M -- since it's not your code to re-license).  You could also sell MX under a commercial license.

Note -- it would be pretty difficult to sell GX since anyone can get the source code from you -- so why would they buy it?  Moreover you cannot add any restrictions onto GPL licensed code -- so you cannot, say give it for free on the condition that someone donate a $1 to charity.  So in effect, if X is a valuable asset to you, creating GX (and distributing it to a 3rd party) just devaluated it.  This will cause some to be concerned about using GPL code if they deal with other code they value (e.g. have patents, secrets, etc.) 

Credits 

Google/Wikipedia

Charaka Danansooriya

The virtual Project Manager

Today you will find everything on cloud.  We will find people working for a same software development team yet around the clock from different  geographies.  This setup works well for either big or large organizations bring benefits of costs based on the geographical economies of resources.  However it is the general tendency in the international businesses is that majority of these projects are administrated locally – the central administration is involved in making strategies, defining targets,  and paying for different clients based on contract agreements they made. How nice it would be If you can hire talents (eg: 1 Sri Lankan, 1 Scandinavian, 1 Brazil, 1 Russian, 1 Vietnamese, 1 South African, 1 Fiji)around the world let them work together and pay them as you do from home ? Such approach would even reduce costs of local administration, time for making contacts and contract, get best talents, etc … However such a model is not that easy in practice as there will be lot of dilemmas and challenges related trustworthiness and integrity. 

If one could overcome such challenges, he could be a great virtual project manager.  By principles this should be possible now. There may be people doing this. But I never have met such. It is not a new practice that interviews,recruitment, training and development, daily status meetings, etc are  possible over internet from diverse geographies. Even in some countries like Netherlands, they also have gone to the level so that they could have legitimate AGMs over internet. Internet based question papers, internet based video conferences, are now providing a real time experience not more different from the old physical face to face to face interviews/meetings by any mean. A project manager could even record the interviews and have better chances to compare and make better decisions. The point here is even if you recruit locally or even if you recruit globally the challenge is not very different, but infact global recruitment has better choices. I know that there is always a big argument about the employee turnover in a virtual project and no project manager will want froggy employees who jumps out in the middle or else who sell the trade secrets. However as i said before the same challenge is always everywhere at the same level for any project manager even if he limit the recruitment to the locals. Therefore the threat is equally everywhere but people who go international are having better choices. Having said that it should be worth rather than guessing, you jump in to the solution. If you try so, you will find lot of support from the cloud. For me cloud is cheap. You only pay for the service what you consume - most likely a monthly bill. No water Bills, No infrastructure maintenance costs, No power bills, No system administration staff, a reliable service you get 24*7 which will ease your administration efforts.

What do you find in cloud for you to manage your software project effectively?  Simply 

1.       Software as a service

2.       Infrastructure as a service

3.       Platform as a service

What else you want to go virtual?  Simply nothing... If you got money  just give a try to be complete virtual. There are lot of opportunities. More importantly everything is already on cloud if you could find a bunch of talented folks like to contribute remotely : may be from home or doesn’t matter from anywhere ;-) as if long as they work for you.

 Pictures speak thousands. So borrowed the pictures cheaply from Google.

Charaka Danansooriya

How do you introduce quality to your small code project with unseasoned developers?

What is quality? 

It is the general acceptance despite the fact the nature of the business you are in, the term quality is always given a narrow customer oriented theme today as an approach for better commercialization. But for a young new project manager the view towards quality from the perspective of customer may not descriptively helpful for him to manage his project healthily to meet the desired objectives. Customer perspective is good and the aim of the focus is always to enhance the credibility towards customer while making the customer ultimately happy about what you deliver. If that is the only purpose of the quality what happens when you get continuous pain in ass complaints on, scalability, maintainability, adaptability, need of better incremental change management, need of effective communication, need for cost minimization through various approaches like reduction of correction and rework, optimum use of resources so and so forth. More over what happen if you cant provide a delightful life for your co-workers? you cant' provide a safe workplace?  when you can't keep the moral of your team at an adequate level ? ... Therefore given the customer kingship, quality should always in view of everything you engage daily.  In other words Quality must be given a broader perspective.

The quality Mission

Given the above introduction an ideal project manager should well define his quality expectations covering the better deliver of customer expectations as well as covering the expectations of all other stakeholders making their stakes well align towards the project objectives. It should always enhance and improve the quality of life of every stake holders in general in connection to the stakes and interest they hold towards project while making them genuinely delightful about their contribution and commitment. OFC , this is not easy. 

How? : A Simple quality approach

In order support the above quality mission in your project you could find various ideas to enhance the quality. As a new project manager of a small startup project team you are always responsible for every single penny you spend. So first of all you will need to understand your budget now. Resources are not always free. Understand the resources you have.  Since you are small you may not be maintaining huge resource calendars, and nor huge resource pool. When you dont have budgets to hire quality experts, organize quality workshop; you just try them your self. Not very hard, you will have to be a good motivator, good mentor, and good  a good coach. Use it as an opportunity polish your skills and confidence.

It is always a best way to start your quality program from the workplace. Then you can think about the quality of the people, quality of their skill, and finally quality of your product.Clean organized and nice workplace will always enhance the moral and reduce rework, brings better visibility of what you all do to every body whilst improving effective communication. Remember the communication and reminding of quality is very important to your small team when you start. It would take some times to establish ground rules and quality oriented culture among members of your small team. At the start you must plant the roots to make a conducive quality orientation to your project team.  Since your budget is limited and you operate at small scale I would suggest you must first look  at cheap quality procedures. There I suggest workplace organization approaches like 5s. Such approach will give you and your team a big relieve and will create a nice clean and stress free divulging environment to surface emerging talents. Many people think 5s is displaying banners and bill boards in and around. True 5S is very helpful and reduce lot of rework, and improve efficiency in your small office room even in the software development environment as state in the beginning. As a project manager you could provide effective leadership there and you yourself can organize one hour 5s small workshops or discussions like arrangements in order to train your staff. For instance once a month you could repeat such programs till you inculcate the roots in to your project team culture.

Then you must think about approaches to enhance the code quality (the quality of product), quality of people and their skill. In order to enhance the individual skill level, train and develop your human resource pool, you yourself can be a good mentor and a coach without much much cost. This is one great opportunity for you where your technical knowledge, interpersonal skills and leadership skills and confidence as a project manger going to be challenged. Parallel to this, it is also the best time to implement quality assurance measures according the quality plan you prepared at the early stages of the project.I have seen that various software testing approaches are knowingly or unknowingly practiced by many project groups with or without view of assuring quality and controlling the quality.

Software quality assurance (SQA) consists of a means of monitoring the software engineering processes and methods used to ensure quality. The methods by which this is accomplished are many and varied, and may include ensuring conformance to one or more standards, such as ISO 9000 or a model such as CMMI. These conformance approaches are generally costly and indeed will need some expertise and resource to a startup small project. I recommend here to the Project Manager; just get the basic idea of what is quality assurances. Don’t ever contrast quality assurances with quality control. Quality control always deal with verifying or testing the final product for conformance. But in contrast quality assurance is ongoing; in the sense while you develop the product you think about the quality, and conformance of you code at to the least level that the product flawlessly meets the defined functionality agreed. Test driven development is a good approach, but it is also costly in terms of time and scope and effort, and not good if your team does not comprise seasoned developers who know better about writing correct unit test cases.  Therefore whren you are operating at small scale with not very talented and not very seasoned startup team,  I suggest you should first start quality assurance with a functionality checklist. You can define phases to the project – based on the progress, doesn’t matter if you are agile or non-agile, clear about requirements or not exactly sure about requirement; however try to define your phases based on the functionality you burn down. Up on the checklist if you have a QA team you can ask them to start writing test cases, If you don’t have a separate QA team ask one or two of your guys to write unit test cases to cover your check list. If you get lot of integrations in the latter phases make sure you also maintain a check list to test the component wise integrations.  Then you can write integration tests or system tests to check the integrated interfaces.

However I would want my article to be short as much as possible. The above approach seems very untraditional for an experienced practitioner. One would find it is such preliminary. But I have experienced that the approach earns results when your project scope is relatively small, your team is small (like 5 – 8 members max) when your budget is limited, when your team is unseasoned, and you are running out of time. Good Luck !!!

Motivators for Project managers

" Project Managers should be Motivators." Well that is fair enough to understand. As a project manager you are responsible for the motivation level of your team or others. Well ... What about yourself? ; who is responsible for your motivation?  The Project Manager – He himself has to be a self-Motivator. Does that explain?

Herzberg's Two factors - Look at Motivators

Whatever said and done it is agreeable that the project managers life is very stressful. He would need to find Motivators which make him inspired about a success of his work. It is a common theory that there are two factors which could affect the motivation of people according to the two factor theory for motivation of Herzberg’s  called Motivators and Hygiene factors.   Looking at the Motivators I would suggest project managers should align their attitudes more orient towards Motivators in order to be successful in their career. Looking at Motivators, the Challenge they face is one positive factor. You have enjoyed the challenge than bittering the challenge in every Friday night.  So take day today issues as challenges and try to win them. Don’t try to beat them. Wining and beating are two different things. You win – you share. You beat - it is sense of hatred and arrogance. Winning is empathy. The Winner get lot of support and whilst he becomes charismatic. That will make your tomorrow’s challenge a piece of cake. Yet you become a genuine Hero.

The work you finish

The other motivator is Burn Down. What you burn down is indeed a motivator. Successful accomplishment of deliverables or phases must be celebrated. Make this celebration an opportunity  to recognize people, reward them and motivate them. You don’t always need to use financial rewards, or Parties to make your staff happy. Just a genuine word of appreciation would do it.  But make note that your word has a honest value and it is genuine appreciation and not an illusive dishonest bait to deceive your staff or to your management. If you do appreciate with hidden agenda's or just to get your work done in a self centered way, others will feel it. They will not support you in long term. Remember always that you are a grateful person and your staff is your blood. Ideally As a project manager it is nothing that could keep you happy and motivated than successful deliver of product within agreed budget and within the agreed deadline with no quality complaints.  Have you achieved that pleasure ever? One would hardly or ideally do that. But whatever at last it is what you deliver is what is going to make you proud. So you got the credibility for yourself. Neither to the PMO nor to the customers nor any others but you.

Thrill of being a champion problem solver

You can also enjoy and motivate yourself as a champion problem solver. Your staff is getting paid, your staff is doing well and happy with their life, your PMO is doing well – because you and your team doing it well. So you are a leader of a responsible but winning team. The responsibility you hold to the community, the responsibility you hold to the staff,  the responsibility you hold to all other stake holders in the project is incomparable. Always remind your responsibility and imagine how people depend on your genuine work with the best integrity.

Team Spirit second to none

Always keep the team feeling in air.  A man could enjoy nothing as much as intimacy. Having a nice team culture and leading a confident team is always inspiring. Team spirit always help to keep your Moral high as well as your team’s moral.  It will relieve your stresses during a challenging day.

Charaka Danansooriya

Purpose

This blog is expected to share the professional experience and knowledge among project management practitioners all around the world. Further it expect to provide a platform to discuss issues and challenges of project managers they face every day.