Thursday, February 27, 2014

Manual regression testing is horrible waste of human talent

It is horrible waste of human talent and Intellectual Capital (IC), if software development organisations let Testers (QA) doing regression testing manually. Regression testing should be automated using automation tools, and scripts. QA and testing people should be doing intelligent works than just dumb, repeated zombie works!

There are many task in QA process. QA is not just testing (QA != Only Testing). Rather than spending time in doing the same repeated testing, they can spend time in writing scripts and automate them. This way we can avoid the risks of missing the important regression errors/bugs and becoming bored of the same.

By automating you can build the system knowledge into it rather carrying in your's/people's brains (Test automation would be your system's knowledge source). Organisations can also avoid the chances/risks of people walking-out-with-this-knowledge when they leave the organisation. We can also save time and money on regression testing with automation. Test that are automated can be executed at high speed by the computers than humans testing and running it manually. This way you can get much faster feedback on the changes made by the developers. The biggest benefit of testing (other than finding bugs) is rapid feedback on the things changed or added by the development. Automation can give rapid feedback.

Testers alone are not responsible for Quality. Everyone is responsible for Quality.

Don't Fight Stupid. Make More Awesome!
                                             -- Jesse Robbins CEO from Opscode

Wednesday, February 26, 2014

On Interview and Two Most Important Questions

In any interview two questions are always asked. Interestingly, out if these two questions, one is asked in the beginning of the interview and other one is asked at the end of the interview. Both questions gets well attention and listed by the interviewer and have time allocated to. The middle content is mostly about the subject matter oriented, may be regarding tools, technologies and practices which both are comfortable at.

The 1st question is: 'Tell me about yourself' or 'Introduce Yourself'
and the last question is 'Do you have any questions for me?'

Both of these questions are very important because both  make an impact on the interviewer and mostly remembered by both the parties.

The 1st question is about & reveals who you are, why should hire you and how confident you're and about your communication skills etc.

The last question tells about and reveals your interest in company, job and the amount of homework you've done on the company by visiting their web site.


Automobile (bus) designers got arrested of a bus accident

Today, I saw a TV news of a bus accident and several people died due to this. It got fully burned when it hit the divider. The fuel tank broken when it hit and by the time the driver noticed the whole but burned and everybody in the bus died. This happened in the mid night when everybody was sleeping.

The bus owner and the driver got arrested. At the same time police took 9 other people into custody. The police said, due to the design faults in the bus the fuel tank burst and bus got burnt and people died.

This means in any other decipline other than software development people gets punishments. Today, software is being used in many life threatening equipment. Software is everywhere. Its used in cars, lifts, life sciences, healthcare equipment, virtually everywhere. The usage of software will increase even more and more.

Today, there are not any regulations exist on software quality. But when politicians become aware of this and if any evidences found on due to a bad quality software & bugs in them accidents happen and people died then politicians will establish regulatory commissions, pass auditing orders and starts inspecting the software and we'll be obliged to follow the documentation of every step then our lives will become horrible. Today, we are fortunate enough that there are no such regulations exist.

So be careful, and start using the quality standards and better practices to deliver high quality software.

Monday, February 24, 2014

Two most powerful words - 'Yes' and 'No'

I think these two words are most powerful in life and make and impact. There are many instances comes in our life where you'll use these words very carefully. We use these words most of the time in our daily life but we don't really think when we use these words in regular communications on day-to-day activities and its doesn't give any pain to each of the parties in involved in.

But there are some instances where using these words shed lot of pain or joy in our lives in each of the parties. Certain times even it becomes very hard to tell these words. We've to be very careful and have courage to say these words and asking something from somebody.

How to say 'YES' or 'NO' is an art also depending up on the situation. How to say 'NO' when you want to say 'NO' also needs judgement call. Saying 'YES' needs a commitment and act of risk taking. Saying 'NO' needs courage. These two words repels opposite energies. When you say 'YES' to one party the party gets its both negative and positive effect on other directions.

Don't say YES when you want to say NO.



Saturday, February 22, 2014

97 Things Every Programmer Should Know

I read this book long back and there are couple of other titles with the same 97 things.

1. '97 Things Every Programmer Should Know'
2. '97 Things Every Software Architect Should Know'
3. '97 Things Every Project Manager Should Know'

The links for the above titles are:
1. http://programmer.97things.oreilly.com/wiki/index.php/Contributions_Appearing_in_the_Book
Other contributions: http://programmer.97things.oreilly.com/wiki/index.php/Other_Edited_Contributions

2. http://97things.oreilly.com/wiki/index.php/97_Things_Every_Software_Architect_Should_Know_-_The_Book

3. http://pm.97things.oreilly.com/wiki/index.php/Main_Page

The contributors are industries well reputed people. I thought it will help to the programmers and architects.

HTH

Thursday, February 20, 2014

Interface vs. Abstract class.

One of my friend asked a question, what is the difference between an Interface and Abstract class. He asked when and where to use interface & abstract classes. I replied and thought the same would be helpful to others also hence turned into a blog post.

Here is what I replied.

Both Interface and Abstract class can be used wherever you need a contract.

However the Interface is purely for contract purposes w/o any concrete implementation but Abstract class can have some default behavior/attributes implemented. Still the abstract class need to be inherited but can provide some common functionality across varieties/specialization/role etc..

Interface has one advantage over abstract class. You can use it for multiple implementation inheritance. You cannot inherit from more than one class/abstract classes. You can have a class deriving from zero or one class and implementing more than one Interface.

Mostly both are there for specifying specialize the object capabilities. Like a bird that can Fly and Quack. But these capabilities should be modeled in separate Interfaces. If you put both in single class then and derive this class by one bird which cannot fly would unnecessarily fly!!!

Indeed objects plays roles and roles have responsibilities. Object can have different capabilities too. These should be modeled using Interfaces. For example: a Person can be a Son, Father, Employee, Manager, Driver, other Social activist. That means playing different roles in different situations. We cannot model all of these things in single object. We cannot push all of these roles and capabilities into single class. doing this leads to bloating and increases the complexity.

I don't encourage Inheritance. Inheritance leads to strong coupling. Using interfaces you can high cohesion. Instead of using Inheritance, use object composition. Wherever possible avoid Inheritance and favor composition.

Objects relationships also plays much role in this. like IS-A and HAS-A, Always favor HAS-A relationship. Avoid IS-A relationship.

So using Interfaces we can model and define individual capabilities of the object and then implement them in its own class, and finally compose them to form an Object with the only required roles/capabilities/specialization.

Object roles, capabilities, specializations can be better modeled using Interfaces. Examples of object capabilities modeled as Interfaces: Flyable, Enumerable, Quackable, Printable, Observable, Groupable, Rotatable etc.

My Presentations on OOD:

Object Oriented Design: Part-1
Conditionals and Polymorphism

HTH

Wednesday, February 19, 2014

SonarQube is an open platform to manage code quality

SonarQube™ software (previously known as “Sonar”) is an open source project:

SonarQube is an open platform to manage code quality. As such, it covers the 7 axes of code quality:



It coveres more than 20 programming languages through plugins including Java, C#, C/C++, PL/SQL, Cobol, ABAP...

For more information please visit their website: http://www.sonarqube.org/

Monday, February 17, 2014

Roles and Responsibilities of a .NET Architect

I came across the following job description for a .NET Architect


I see almost 90% of the software development job descriptions like above. Did you spot the problem in this?
Let me tell you what it is. The whole description is talking about the tools!!! Not patterns, principles, development practices, processes, procedures, problem solving methods or even any of the software development methods like Agile (eXtreme Programming (XP), Lean, Scrum et.al.).

There is nothing like, Object-Oriented Design, Patterns, Principles, Practices, Identifying the Code Smells, Applying Code Refactoring Techniques, Test Automation, Automated Developer/Unit Testing, TDD, Architecture and Design Patterns, Application Profiling, Quality Concerns, Performance fine tuning etc.

Do you think a 12 Yrs. Software Architect (.NET or Java or whatsoever) need not to know about these?
OR Do they think that things I mentioned are not at all required to mention in job descriptions? OR do they think that these things are inherent and already would have knows to the people who are qualified for Architect?

This job posting is from an HR - IT Recruiting consultant company. They don't know about all of those things I mentioned. They just form a company, subscribe to the databases of job portals (Naukri and Monster etc.) and put a bunch of template-zombies (TZ) to search the database for key words the IT company needed people. I don't suspect the software development people but the IT companies also have a department called HR/Recruiting who hold similar template-zombies (TZ) to find people for the positions open. These TZs then head to the job portals, looking for key words and handing over the resumes found for the given search criteria to for interview. There would be thousands of findings when they search. Then they turn to recruiting consultancy companies doing the same by handing over the key words and job descriptions etc.

Software companies spend very little time creating and fine-tuning the job descriptions for the position open. This could be the reflection of the Software development & IT Companies who hold similar development practices internally they follow.

Indeed ITES/Software development companies, when they got a project, they just look into the tools and technologies used  are rushing through finding people who knows them.

I once saw a company, and a project which is of Big-Data. They quickly thought Big-Data means MapReduce (MR) and hence rushed to find a resource who knows spelling of MapReduce :) and quickly find the people who knows about or heard about MR and recruited them.

One more problem I see with IT companies is calling software development people as "Resources". For them its just a Resource knowing xxx and yyyy technology. Thye don't just care about the who bunch of other things involved in software development.

On last thing... I see some of the job descriptions having 2-3 pages!!! Argh!!

Saturday, February 15, 2014

India mobile and internet users statistics

Slideshare tweeted an interesting link showing a presentation of the details of  India mobile and internet users statistics. This survey has done by Internet & Mobile Association of India (IAMAI) and presented by  IDEATELABS -- This is very insightful.

You can see this on Slideshare: http://www.slideshare.net/iibea/digital-statistics-2014-india?sf22752230=1

QA != Only Testing

In software development industry, there are many terms introduced very rapidly. There are many new technical terms and acronyms that sometimes confuse people working with. Novice engineers don't know what it is and why they are for.

To make this even more chaos, they interchange the terms and use one in other's place. Some software companies uses these terms in designations also. For example QA, it means it can be Quality Assurance or Quality Analyst. Both of these terms applies to the same underlying principle, task and process which is Software Quality Assurance -- An Assurance given by the development companies to the customers that the software developed by them has considered all the quality standards set by them.

Software companies use QA for instead of Testing. Software testing is a small activity of a larger process. There can be test engineers but they are part of the QA process. But many software companies put a QA label on a tester and call them as QA!!! and give work of testing the software. They never establish or follow the process required to complete the full life-cycle.

Many software companies have people labeled as QA, Sr.QA, QA Lead, and QA Architect!!! (God help us) who just do a labor for the developers, who throws some code on the faces of QA people.  Instead of automating, these people repeatedly tests the software modules developed by unprofessional, careless developers.

Software Quality Assurance (SQA) includes the whole software development process. Not just the testing. What the these testers do is kind of Quality Check (QC).