Part 2 Getting Ready - 2.4 Crafting Considerations
2.4 Crafting Considerations
41. Getting Organized
Have you worked
with programmers who are organized and thorough? Have you noticed one thing?
They think through, plan and start writing lines of code as if they write a
beautiful poem from the first word to the last, and compile it in one go at
least 90% of the times. They have laser
focus. They know what they do. They do not depend on any search engine or
programming language references. In
addition, their productivity is far higher than that of novice programmers who
cannot take anything but a trial-and-error approach to programming. They are organized and prepared. They know what they are going to do and how.
They choose and use the right tools and techniques. Their speed and accuracy are
matchless!
I have worked
with star programmers and learned from them.
I have observed them write programs in PL/SQL, JavaScript and Java with
ease. I have paired with them and seen
the way our code shaped up from the first character to the last, so swiftly and
neatly.
You will find
star programmers in every project or organizations. When you find them, collaborate
with them and create learning opportunities for novices!
42. Practice to Perform
As programmers,
we used to practice and compete. We contested to write the most efficient code
that had no errors. The completion was stiff.
More than winning or losing, it helped us realize our capability, learn
to solve tough problems and improve.
Learning and practicing as a group was an enabler for us.
In addition, we
learned new languages. In 1996, my team
members and I learned Perl 5 by reading through textbooks and solving all
programming exercises at the end of all chapters. We did not leave any stone unturned. That was
fun! A positive reinforcement! Later we developed and implemented an
application that went production and lived for more than five years.
It is very
disheartening to witness self-proclaimed constraints in the form of a standard
list of ten or twenty programming exercises or a fixed textbook to complete a
programming course in some of the colleges and universities. You need to do practice a lot more to become
a software professional.
Practice.
Practice with star programmers. You will perform!
43. Initiate DP
Elbert Hubbard, an American author and
philosopher said, “Constant effort and frequent mistakes are the stepping
stones of genius.”
Constant effort
is important. How about frequent
mistakes? They are important too. Let those
be new mistakes but not repeated mistakes!
That is what he meant.
DP stands for
Defect Prevention. Initiate DP as early
as you can. You do a mistake. You are aware.
You know the side effects of it and the overheads required to correct it. In addition, you decide not to commit that
mistake again and you implement that decision.
That is DP in simple terms.
Undoubtedly, the most efficient way to produce quality software is to
prevent the injection of defects in the first place.
Consolidates a
list of frequently encountered code review issues along with additional key
issues. Let your team focus on 20% of
the issues that happen 80% of the time as well as critical or trivial issues
that could erode customer satisfaction. Facilitate a team meeting to prepare and
finalize this comprehensive checklist - a checklist with approximately 10 to 25
issues that can be composed in 1-page in a readable format. As a team, agree on preventing these
issues. Print this checklist and posted
in each developer’s work place to create a visual effect - ‘The more you see, the more you remember and
follow.’ Let it be a one
pager. This is because a checklist
running into several pages will not create the same visual effect and produce
equally good or better results.
We experimented
this approach in a project. It worked wonders!
During the initial days, our developers did self-review of their code to
ensure defect prevention. That was the learning period. Gradually, they prevented many of those
issues during coding itself! After a
few weeks of development, our team identified new items to be added to the
checklist and replaced them with those were no longer needed in our list. This becomes a monthly routine.
Let me quote
Elbert Hubbard once again. He said, “The
greatest mistake you can make in life is to be continually fearing you will
make one.”
Bottom
line? Do not fear to make mistakes. Do
not fail to prevent them either!
*-*-*-*-*
44. Spaghetti, Frustrations and Us!
It starts from
nowhere. Initially it feels like a sore throat. Within hours, it is
nose block. You lose sleep and develop headache. Sometimes become
irritable. It saps your energy. Within a week, you feel very
weak. Next time when there is a change in weather, you take
some precaution. Try to avoid the virus. Yet, you do not have any
control. It can hit you again! That is about common cold and virus.
You guessed it
or not, let me tell you now. A similar thing happens to software
engineering teams. Knowing that we have adequate control, we fall into
the same trap repeatedly. It is not about common cold or virus! It
is about Spaghetti, Frustrations and Us! What not?
One of my
ex-colleagues from a top-5 services company in India called me over phone when
I was walking out of a meeting room at work.
That conversation is worth sharing with you.
I return to my
desk while catching up with his call over the first thirty seconds. He sets the
contest.
He is distressed because his team has been plagued with this
issue. Code quality issue!
He asks, “Which
tool do your team members use?”
I think for a
moment and say, “Tools are important. Think about a senior citizen going
for a medical test and returning home with great results!”
Puzzled, he
asks, “What? What do you mean?”
“Think! How
can you work with your team in creating healthy, beautiful code? How can
that experience help you in using a tool to find only those hard-to-find issues
so that it saves your time?”
With disbelief
he retorts, “We have engineers who know programming. We train them. What
else can we do?”
Obviously, with
no time to continue, I accommodate his point of view and say,’ “Yeah. I know. “
With some
concluding remarks, the call ended. It was not over. He was going to
call me again in a week or two.
He called again.
We had a long conversation on how to avoid code quality issues.
Spaghetti code
is not created in a day or a week. It is the result of several weeks of
inattention to code quality. It is a mess! It happens again and
again! It will continue to happen unless we change the way we do
programming. I will continue to surface unless we change the way we
inculcate programming practices.
What can we do
to improve? We have to make ourselves and our team members see,
understand, analyze and practice. We have to self-review and
set the bar high. We have to declare that any piece of code meant
for peer review will be of certain standard! Here are some tips.
- Paste a sheet of good quality code at workplace – preferably at the desk of every novice programmer. Introduce a new sheet every month.
- Send email flyers with code snippets to illustrate what is good and what is not.
- Start every meeting with a two-slide presentation to show and discuss code quality violations.
- Send a page full of bad quality code to team members and ask for their comments. One who finds as many valid issues is your shining star!
- Induct new engineers with a one-hour peer review or pair programming per day during the first ten days.
- Provide a repository of spotless code to fresh graduate engineers. Keep this repository updated and relevant.
- Practice self-review and prevent mistakes. Let the self-review checklist have not more than twenty-five specific and measurable items. Let the team make the checklist, implement it and keep it live.
- Learn from peer reviews.
- Use a static analysis tool. You will be happy to see a low number of good quality issues and learn from them. It will no longer be a long list of issues and false positives.
- Collaborate with customer. Let the customer understand all the groundwork you have done to improve code quality. Review with customer expert. Prevent recurring issues.
Form a team of two
or three engineers. That is your team of code quality champions. Let
them drive this initiative.
*-*-*-*-*
45. Attitude Drives Quality
The attitude of our
team members drives the quality of what we deliver. This holds good for
everyone including those want to invest in creating software, business owners
who intend to build systems with the help of IT teams and IT teams who create,
test and maintain systems.
The way we
communicate and act reflects our attitude. Which ones of the following do you
prefer? Isn’t it easy to identify and choose attitudes that lead to high
quality deliverables?
“Bugs or defects
are inevitable. We will fix them when we find them.” OR “Striving to write bug-free code is
essential to improve deliver a high-quality product.”?
“My code
compiles. My work is over.” OR “I need to test it and fix bugs early, if any.
My work is not over yet.”?
“Refactoring is
going to take too much time. It is not in our scope.” OR “We need to refactor
it now than later to optimize efforts.”
“When you report
a problem, bring one or two solutions too!” OR “That is a valid problem. Thanks
for bringing it up. Let us solve it!”
“My tasks are
done. I am leaving now.” OR “Let me help Sam. He seems to have stuck with an
issue.”
“Why should we
ask the customer? This is working and seems to be sufficient.” OR “Why don’t we
ask our customer and validate our understanding? We are not sure about it!”
This is one key
factor that differentiates organizations that produces excellent products and
deliverables from the rest!
46. Integrate Early and Frequently
This happened
sometime in 2001. My family wanted custom-made
furniture in our new apartment. We
shortlisted an agency to do the work.
The approach they followed was very interesting. Two of the senior experts involved in the
work did not stop at taking measurements and coming up with designs. They
worked closely with their team. At
regular intervals, they made sure that all the parts fit into the whole. They made sure that the doors, the shelves
and all other individual parts fit well together. This is because their work was about creating
custom-made furniture.
In IT industry,
no two projects are the same. Once, with
a team of fifteen engineers we developed a product. We wanted to program the
top twenty key features in eight weeks. At the end of eight weeks, we planned
to integrate all the source code and initiate testing so that we will have
tested features ready for demonstration.
That was our initial plan. Our
first attempt to integrate the code took us more than five working days! We
worked more than 15 hours on all those five days. That was painful.
The ordeal
project teams go through in integrating or putting together all the source code
written by team members over several months is as good as a nightmare!
There is a
solution to this issue. Create an automated build script. Start with daily
integration and move onto frequent integrations per day. This practice is known
as continuous integration. When you step
up from continuous integration and deploy code in production seamlessly, you do
what is known as continuous deployment or continuous delivery.
Do you know?
Several software systems we use in our daily lives, including Facebook are
deployed frequently. That is an efficient way to deliver new features, and bug
fixes to end users!
*-*-*-*-*
47. Who Injects Quality?
‘It is the
testing team. We did not do enough
testing. Our quality assurance practices were weak.’ This is what we hear when
buggy products result in customer complaints.
Who injects
quality? When this topic came up at a
conference, someone argued, “Well. The testing team or your quality assurance
group – however, you call them, need to stop or raise the red flag when a
product is buggy! In spite of this
simple truth, why do we see some disasters time and again?”
Good question. I
agree. We must raise and respect red flags.
Let me rephrase
my question. Who can potential inject
bugs in software? It is obvious! Anyone
and everyone involved can inject bugs.
This makes it clear that everyone in the team is responsible to put
quality into the product. Is there
anyone who is not?
*-*-*-*-*
48. Manifesto for Software Craftsmanship
Robert Martin,
one of the 17 founders of Agile Manifesto is also one among the leaders who
initiated ‘Software Craftsmanship’ movement during 2009 in order to emphasize
on the importance of product quality.
Here is what he said in this manifesto.
As aspiring Software Craftsmen, we are raising the bar of professional
software development by practicing it and helping others learn the craft.
Through this work we have come to value
Not only working software but also well-crafted
software
Not only responding to change but also steadily adding value
Not only individuals and interactions but also a community of professionals
Not only customer collaboration but also productive partnerships
That is, in pursuit of the items on the left we have found the items on
the right to be indispensable.
Whenever I read
Software Craftsmanship manifesto, I am able to see the focus on quality along
the following four critical dimensions.
Product Quality
- ‘Not only working software, but also
well-crafted software’ provides a clear-cut direction on product quality in
terms of architecture, design and code quality.
It goes beyond those to cover several aspects of product quality that
are necessary for any product to be valued as well crafted by end-users as well
as maintainers.
Business Quality
- ‘Not only responding to change, but
also steadily adding value’ is all about delivering business value. The quality of how a project team steadily
adds value by delivering the most valuable features on time with quality is
more important than responding to change and establishing a comfort
factor. This approach values the budget
approved by project sponsors. This is
what I call as delivering business quality.
Professional
Quality - ‘Not only individuals and
interactions, but also community of professionals’ summons the need to
build the culture of knowledge communities or communities of
professionals. When we limit ourselves
to ‘individuals and interactions’ we tend to limit our contributions as well as
learning opportunities. When we become
part of knowledge communities, we open up immense opportunities for sharing as
well as learning. Sharing and learning
are very critical to improve professional quality.
Engagement
Quality - ‘Not only customer
collaboration, but also productive partnerships’ enables us think in terms
of engagement or relationship quality.
Customer collaboration cannot be confined to ensuring success at project
level. It has to be extended further to
cultivate productive partnerships. That is the way to ensure engagement
quality.
Do you belong to
this community? You know SOLID principles. Do you know programming principles?
When I interviewed a random set of developers, I found that almost 50% of them
are unaware of programming principles. Search and learn. Alternatively, get in
touch with one of your experts!
49. Reusability and Half-life
A library of reusable components is
one among the strategic engineering assets of any successful organization in IT
industry. Such a library of reusable
components contributes not only to productivity during coding and maintenance
phases but also to product quality throughout the life cycle of any software
product.
Several years ago, I was leading
the Software Reuse initiative of my team and we had setup a portal called
‘Reusability Center’ that served as a central component library for the entire
organization. During those days, we
had prepared a checklist to verify if a component is ready in all aspects to be
a part of our library. We had a set of
senior technical leaders who used to handhold and coach young engineers in
creating reusable components. With all
these, our initiative survived for a few years and stalled after a major
organizational restructuring.
Obviously, the
level of motivation and confidence in identifying, promoting and accepting
reusable components is different at different ecosystems. Organizational culture, leadership
commitment, team size, geographic spread and technical maturity are some of the
key factors that make or break reusability related initiatives. That is why any initiative on creating a
library of reusable components becomes an uphill task in organizations.
Read my article ‘Reusability,
usability and flexibility’ published by EE Times on the importance of usability
and flexibility when you want to promote reusability.
Here I am going to share one more
phenomenon related to reuse.
We learned about Isotopes in or
school days. Isotopes are different forms a single element as they have the
same number of protons but different number of neutrons. Half-life is a well-known characteristic of
radioactive isotopes. In simple terms,
it is the time take for a radioactive isotope to lose half of its radioactivity.
Just as radioactive isotopes have
half-lives, the languages, tools and utilities we use in our work life come
with have half-lives too. A certain
version of your language hits its half-life as soon as there is news about the
next version. A few months after the release of its next version, there is a
firm indication that the earlier version is going to end its life. This means that you need to understand this
phenomenon and upgrade your reusable components – if you want them to live
longer. Also, this means that you need
to capitalize on your idea of creating a reusable component well before the
half-life of the languages, tools and utilities you are considering. Else, who is going to use your reusable
component?
To sum up, let us understand two
facts. One, reusability is beneficial – it improves productivity and quality, it
improves elegance and it reduces maintenance overheads. Two, understand the
half-life phenomenon - create and release reusable components swiftly and
maintain them to extend their life.
Finally, be consistent and
persistent when you make it a strategic initiative.
*-*-*-*-*
50. Learning from IBM San Francisco
During late 90s, the term ‘object-oriented
frameworks’ was a big time buzz among the corporates and academia. A team of engineers at IBM started working on
IBM San Francisco Project in 1995 and released the initial version in August
1997. The goal of this project was to
develop a business framework that can support distributed applications. Dr.
Dobb’s Journal reported this as the largest single Java development program in existence
because it was developed over three years with more than two hundred
developers.
This project, in my opinion was the
foundation for several other frameworks that became popular in the
industry. The design concepts, patterns
and principles of IBM San Francisco framework, inspired several teams to come
up with new frameworks. Spring framework is a very good and popular example
here.
What happened to IBM San Francisco
project? Sometime in 2000, IBM decided to cut its investment in this
project. Reports and discussions on the
Internet attribute the fate of this framework to customer adoption,
flexibility, customizability and so on.
Some analysts wondered if this framework would have worked well in
today’s world of technologies.
In our industry, there are several
moving parts. Every part has a half-life period. Products and frameworks come
and go. Winners emerge!
Jim Barksdale joined as President
and CEO of Netscape in 1994. He used to
say, ‘In a fight between a bear and an alligator, it is the terrain which
determines who wins.’
Understand your terrain and become
a master to deliver! You will succeed!
Comments
Post a Comment