Good programmers get a bit emotional, sometimes aggressive, forcibly compelling and coercively convincing when they see poor quality code in the repository. At times, they land into protracted conflicts with the other team members about code quality issues and the priority at which they should get fixed. I have been in several of these unwieldy situations and heard distinctive reasons from programmers about “Why they checked-in that unwanted piece of code? “. Some programmers stated that they have no time, they are under intense pressure to deliver and they just want to get things done. Some(The eager coders), constrained by their skills and knowledge, were more receptive and wanted to learn and change their code for betterment. I have also heard extreme statements and great proclamations like – “I care more about meeting deadlines for customers than writing good code. We can always re-factor it later” – Management cherishes them and keeps these individuals forever (for their amazing adoration for customer deadlines). Actually, what they are trying to say is that they will write good code when in a project, requirements, budget, priorities, deadlines and teams will be fixed and under acute control to give them the luxury of good code development. They don’t live in a real world of ‘pragmatic software development’.
Let me bring some wise advice to these insane programmers, these minimalist minds who believe they have to write least quality code to get things done, and refactoring code is a ceremonial activity – an ostentatious action, which is usually done if and when they have time (They will never have that time). Refactoring is not an exercise done on deficiently composed, ineffectually thought, wrongly intended working-code. It’s not a backlog item which needs to be prioritized later.
It’s hopeless to assume that one fine day
you will abruptly pick the crap you have created for months and fix it. Infect, an awful, terrible code never gets re-factored (Unless of-course, if your job or reputation is at stake). Refactoring improvements are about your experimentations with design; your intense desire to make ceaseless code and design improvement – everyday with every visit to code. It’s not an end-of-iteration or end-of-milestone movement. It’s an intense cognitive activity for improving the design of code that last difficult times after beginning the secret life into the repository. How can refactoring be fortuitous activity accomplished after the working-code is shipped? No way! Good programmers write good code, even under extreme pressure of software factory, and they improve it continuously with slightest opportunity. They make real project constraints work for them and align with their exceptional yearning to forever produce excellent quality code.
I have worked with some very good developers and also knocked my brain out with some lamentable ones – who ought never to be coding.
I recall re-writing entire production code developed for past one year in straight 4 months with a new team. We called it code refactoring that time, so that code owners don’t get offended (or embarrassed). My company never ascertained the cost of re-writing. Infect, I was asked about the ROI of refactoring the work well-done. I never knew how to convince project management that the code they released with enormous fanfare was almost impossible to extend, maintain fix, and was the cause of the large bug list and customer dissatisfaction. I could not get the project-time for the team to work on these mammoth re-writing effort. We did it off-line, in-parallel to day-to-day deliverable and re-wrote most of the existing product code. Six months later, we had some positive feedback about reduction in production failures and improvement in customer and partner sentiments. Programmers who composed that earlier code-crap, got promoted for meeting all deadlines. I am still in touch with developers who re-composed the new improved code.
I wish, I had a tool to measure the cost of poor code quality to the company – every day, every hour. I would have displayed hourly metrics on the big screen for every bit of code that gets checked-in (I understand that’s too much of a love for “Beautiful code”).
I often wonder, why programmers undermine the product quality with deficiently composed so-called “working-code” (and still earn their credits)? It’s so easy for programmers to trick uninvolved management and project stakeholders in the short run. More often than not, management has one single measure to track the project progress and current risks to delivery – It’s their sheer capacity to meet immediate milestones and demonstrate a working piece. Furthermore, they see programmers’ productivity in terms of total work delivered, total tasks completed and aggregated errands finished. Productivity seen in context without a reference to quality is not an effective measure. Bad Programmers are shrewd to use these limitations to their benefits(not in all companies though). They write code that sucks, make it work, make it breeze pass through a QA tests, release the product, add the work done to their resumes and then wait for a large backlog of bugs to be formed for creating strong dependencies on them during the long maintenance cycle of this “Big ball of mud”.
They run iterations after iterations of fire fighting and bug fixing to make it suck more (and they earn more credits for fixing it). Management is happy as they see everyone involved and loaded. A quick analyses of bug backlog in these situations will reveal that number of these bugs should not have been there if programmers would have been less rushed and hasty, and more careful, thoughtful and attentive about the code. If the programmers had cared to learn some new stuff, Googled a bit more, reviewed their code with someone, re-factored it, composed some tests to verify their code or simply visited their working-code once more they would have been able to avoid many of these large bug backlog pains. These rushed and eager code monkeys say- “It works, it meets expectations, it has passed the QA tests, and shipped product will always have some unknown bugs which cannot be avoided”. They forget that complex-poor-code will discover new, unimaginative ways to generate new types of bugs. Technical debt will shoot like a chain reaction and grow like an irrepressible cancer killing your ability to enhance product. It will consume your capacity and budget; it will slow you down; and it will frustrate your people. Project Management teams find it hard to handle these situations. The only way they think they can ensure product quality in these circumstances is by having a QA team of much greater size compared to the programmers team, and working for longer release cycles (Quarters and years). What a way to ensure employment to people.
It’s not easy to convince programmers and short-sighted project management that:
“Working code” != “Shippable code” &;
“Working code” != “Work Done” &;
“Working code” != “Correct code” &;
“Working code” is also != “Well Crafted code”.
Infect, this whole understanding of “working-code” is flawed. It’s so easy to write code that works most-of-the-time and call it a “working-code”. This “Make it work for now” attitude has cost a lot of companies in the business of writing code. It indicates very constrained and obliged mindset of people who develop and lead these projects. Is the only purpose of writing code is to ensure working features quickly? What happened to your system quality concerns – Maintenance , performance, scalability, modifiability, extendibility, adaptability etc.. Big-cost of the project comes when we address these non-functional requirements. I have hardly heard a technical stakeholder pose a question like – What is the quality matrix for your classes and functions used to develop this feature in the current iteration? What is the improvement in technical debt? Which code did you improve in this iteration? They silently sit thorough end-of -iteration demo’s watching working features. I am a great fan of end-of-iteration product demos. It’s the only way to verify that you have built “what product stakeholders truly wants not what they said they need”. But, unplanned , unorganized, unconstrained demos to show stakeholders the project progress has a profound negative impact on the design and code quality. Programmers, pressurized to deliver the working-code for the demo, deliver “The working code”, but that is never the “Complete code”. Teams need to define their “Definition of Done” with intense code quality criteria and ensure that all user stories they have developed in the iteration do meet this “Definition of Done” for the code before they demonstrate user stories to the stakeholders.
What differentiates passionate programmers, those who build incredible products from the common ones who write very ordinary code (to make their living), are intrinsic qualities and virtues of CARE , ATTITUDE, SELF-DISCIPLINE, HUMILITY, EMPATHY, backed by excellent programming skills, great technical competence and continuous desire to improve
(as if, in a long, never-ending, journey of mastering the ‘craft of great coding’).
Care brings sensitivity in your behavior and action, it ensures serious attention, genuine consideration and application to do things correctly and avoid any damage or risks to others. If you care about the product, customers, peer programmers, QA, support and maintenance people or any other who is affected by your code, you will ensure you always craft good code.
Positive, rational attitude opens your mental locks, provides you with a lens to evaluate everything correctly and judiciously. It inculcates professional approach, helps you rise above wishful intentions during extreme times by building mental models which foster positive perspective and intense desire and commitment to code quality and software as a whole. It brings that motivation to continuously learn and improve whatever you do. And, it applies to the code you compose every day at work.
Self-discipline with a consistent commitment to self-development is the number-one approach for building competencies in an individual. Self-discipline refers to the training that one gives one’s self to accomplish a certain task or to adopt a particular pattern of behavior required to achieve desired goals (A great code). Self-discipline helps you build perseverance, restraint, endurance, thinking before acting, finishing what you start doing, and the ability to carry out one’s decisions and plans, in spite of inconvenience, hardships or obstacles. It helps you build great programming skills and consistently practice and improve it to perfection.
These qualities of programmer build the right mental models necessary for development of incredible programs.
It takes a lot of time, commitment and effort to develop these intrinsic qualities to write good code, they are sometimes ingrained in the culture and values of the organization, experience of developers and their background – their values and principles, colleges they attended, people they have worked with, how they have grown in their professional career, how they have learned and acquired skills and knowledge and how they have been measured and mentored. All good learning minds poss these qualities and consistently exhibit them, not only in their coding activities, but in everything they do and value.
Project management barely measures these qualities (Call them competencies). They do not know how to quantify them. Even if they do, project management is so short-sighted that they cannot see things beyond immediate releases (At the same time, they do like to have year long plans and want to get everything in their control). I don’t think you can have one disposition towards code and different towards your other delivery activities.
Passion for writing a great code also has it’s impact on the teams and the organization. Programmers who will care about good quality of code will care about their team, their colleagues, the quality of deliverables, quality of customer satisfaction and business success. They will set high standards on everything they do and improve, they have more chances of innovating and creating new things. Passion for quality is a state of mind achieved by continuous commitment to excellence.
Your code evolves, shines, emerges through precise improvements, refactoring experimentation, insightful discoveries and thoughtful reviews. Revisit, what you wrote last day,reflect on it, improve it, consult and review it with peers; Never close it forever.
Coding is a craft which gives you an identity and defines your attitude. It is what you are and speaks a ton about your passion towards what you do and what you relate to. Code conveys lots of things about the team work and quality of work you produce – it communicates your attitude towards what you do, quality of teamwork, relationship and collaboration between team members, quality of development management, what gets measured in the team, motivation and frustration levels of the team members(who are going to leave soon. ) etc.. I have seen two people sitting side by side writing very different quality of the code. Even when they were actually working on the related modules, they never cared to collaborate, to look into each others work and learn. On the other side, there are programmers who have learned from open source communities by looking into the good code developed by remote developers they have never seen.
Yeah… but don’t thrash people and don’t be condescending, and demeaning of others efforts. Encourage them, honor their opinions, appreciate what people do, teach them good coding techniques, help them to build the qualities.
Which of this books have you read and practiced?
Technodeation 