Article Series on Quality – A Round-Up

As announced earlier, I am writing a very exciting series of articles on QUALITY over at ActiveGarage.com – it is a 12-part series that touches upon some of the most critical aspects of building a quality-centric organization culture. Here is a list of articles already posted so far, in case you have not read them.

I hope you will enjoy reading it as much as I enjoyed writing it. The beauty of this series was that I came to realise the power of focused and theme-based writing. It can be a great tool to focus your thinking on a subject and collate that with your own experiences.

Quality is Happiness

Quality is not just “degree of excellence” or “conformance to requirements”. Quality is Happiness.

Happiness of people who work on product development. Happiness of clients who receive the product and are delighted to use it.

Only happy internal customers (peers, sub-ordinates, project team members, testing department) ultimately lead to happy customers.

If people don’t find the product they are developing to be useful, they would not be happy working on it. No one likes to produce anything that is useless.

When people believe in the vision/purpose of the product they are developing, they will happily “walk-that-extra-mile” to deliver Quality.

Happy people are more likely to produce better Quality. Great Quality delivered to clients makes them happy.

Unfortunately, most quality models focus heavily on “process” and less on “happiness”.

To comply with a rigid process is Management. To have happy, motivated people using process as a tool to ultimately deliver Quality is Leadership.

Three Lessons in Software Development (and more)

12 years in software industry have been quite eventful. Requirements Management, Design, Testing, Reviews, Methodologies, New Tools, Customer Feedbacks, Escalations, Expectations Management – it has been a roller coaster ride for me. I have thoroughly enjoyed it while learning some of the very important lessons.

Just when I was thinking of summarizing some of my key lessons in software development, I came across this wonderful series “Lessons in Software” over at Shaping Software Blog. Use following links to read all three parts: (Highly recommended reading)

I loved all of them but following three lessons resonated very well with what I strongly believe:

  • Coding is Easy, Humans are Tough (from Mike de Libero)
    80% of software development is a people sport. Technical knowledge is still very important, but not only enough. Programmers/Developers today are expected to know how to deal with other human beings (clients, managers and peers) and keep their goals larger than their egos. It pains to see people on a project teams operating from their egos. Most importantly, even clients need to understand the “human” aspect of software development. I have seen clients who treat people like Robots.

    Mike says:

Don’t get me wrong, there are some hard problems in coding but they are not as hard as figuring out what our fellow beings want out of a piece of software.  Humans tend to be fickle and contradict what they say.  On top of that it is very hard to communicate clearly and a barrier exists between “geek-speak” and normal vocabulary.  It becomes extremely difficult to figure out what users are asking for.

  • Learn Software Development, Not Coding (again from Mike)
    This has been one of the most important lessons I have learnt personally. Software development is an art much larger than just having ability to code. It is about comprehension (of requirements), design, execution (coding), communication and overall expectations management. Coding is one small part of overall game, so don’t underplay yourself by simply remaining a coder. Remember: Knowledge of Coding + Processes + Business Understanding = Great Software Developer

    Mike mentions:

Personally I make a distinction between coding and actual software development.  I think there are far too many people who focus on just the coding portion and not the bigger picture.  Many people can write code but it seems fewer people can design a system, test a system, write the code, document the architecture, talk to users to figure out requirements, create semi-accurate estimates, help other team members and when designing a user interface know the basics of user interaction.  There are things all developers should know about coding as well but I feel improving your coding chops is pretty easy and is done as you develop software.  Learning and improving in regards to software development is not necessary for one to hold done a job as a programmer.

  • Unit Testing is #1 Quality Practice (from James Waletzky)
    Code isn’t complete till it “works”. Good unit testing is a primary responsibility of a developer – not something that is shunned when schedules are tight. I have heard people arguing that they did not do unit testing because of a tight schedule. This only means testing team will take more time in uncovering your unit level defects. No time saved effectively. Great developers know that unit testing is extremely crucial activity which only helps them improve quality of their output.

    James says:

I often get asked the following question: if I could change one thing about software development to encourage improved early-development cycle quality, what would it be? Easy – improved unit testing. Historically at many companies, developers would write the code, run the “happy path” through the debugger, and throw the code over the wall to the test team for validation. Quality would be “tested in”. On more recent teams we have been doing much more unit testing  using code coverage as a feedback mechanism and quality has risen substantially. Additionally, unit tests give you the confidence to refactor your code at any moment in time leading to cleaner designs and more maintainable code. The icing on the cake is having the tests run as part of a daily build, so you always have quick feedback as to whether functionality is broken. The disadvantages are that unit tests take time to write and you add 50%+ more code to your product, but the investment is worth it.

I know this post has gone longer – but I could have still gone on and on. I strongly recommend that every Project Manager, Technical Leads, Process Experts and Software Developers should read these three very informative articles. Having done that, they should implement these.

At the end of the day, it all boils down to execution. Knowing is great – but executing what you know systematically is even greater.

What lessons have you learnt about Software Development?