Summary

of
The Total Cost of Owning a Mess Code
MUHAMMAD AZHARI

Teams that started a project going quickly may find themselves working at a snail's
pace after a year or two. The team's output steadily declines and asymptotically
approaches zero as the situation becomes worse. Until the new team is capable of
performing all the functions of the old system, management will not replace the latter.
The initial members of the tiger team may no longer be alive by the time this race is over
since it might go for a very long period. However, dear Dilbert, the blame lies not with our
stars but with ourselves. It can be difficult to accept that we are all to fault, but it is time
to do so. Programmers have a significant role in the project's design and bear a large
portion of the blame for any failures, particularly those caused by subpar code. Even
when they are preoccupied with the timetable, the majority of managers desire quality
code. It is your responsibility to defend the code zealously.

Programmers have a challenging issue with fundamental ideals. To fulfil

deadlines, they are under pressure to blunder. Creating a mess will prevent you from
meeting the deadline. Maintaining clean code at all times is the only way to meet the
deadline and move quickly. If you don't understand what clean code is, it won't help you
to try to write it. Painting a picture is similar to writing clean code. The ability to distinguish
between excellent and terrible art does not imply artistic ability. Writing clean code
necessitates the methodical application of countless tiny strategies through a
painstakingly developed sense of "cleanliness." The secret is this "code sense." Some of
us are born with it, while others must work hard to get it.

The mess is tempted to expand by bad coding! People frequently make bad code
worse when they alter it. Broken windows were utilised as a metaphor by Dave Thomas
and Andy Hunt. In it, he makes the case that whereas bad code strives to accomplish too
much and muddles the purpose of its source code, excellent code shows careful attention
to detail. According to Grady, code should be factual rather than imaginative. Clean code
should reveal the tensions in the issue that has to be resolved, just like a good book.
When the suspense reaches its peak, it should make the reader exclaim, "Of course!".
Grady and Dave both want clear, readable code, but with a crucial distinction. Dave claims
that clear code makes it simple for others to improve it. No matter how beautiful the code
may be, if there are no tests, the code is not clean. Clean code is carefully maintained
code. Someone has spent the time to keep things straightforward and organised. They
have given the necessary attention to detail. Most importantly, they have cared. This
book, How to Care for Code, is about that.
 Ron Jeffries prefers straightforward code that executes all tests. has no duplicate
content. expresses all of the system's design concepts, reduces the quantity of entities
like classes, methods, and functions, among others. If an object or method performs
many functions, it should usually be divided into two or more objects. I feel like all
applications include a lot of the same components after years of performing this work.
Just keeping these two factors in mind while improving code may have a significant
impact. Clean code is characterised by little duplication, great expressiveness, and early
construction of straightforward abstractions. Clean code won't surprise you at all to read.
It will be straightforward, convincing, and evident. Clean programmes are so incredibly
well-written that you don't even realise it. It is made to appear absurdly easy by the
creator, much like all truly remarkable designs. The programmer is the one who makes
the language seem simple.

Over ten times as much time is spent reading code than writing it. In order to
develop new code, we are continually reviewing older code. We want to make reading
code simple since the ratio is so high, even if doing so makes developing code more
difficult. We may use a straightforward guideline from the Boy Scouts of America in our
line of work. Cleaner than when you arrived, leave the campsite. The code must be kept
clean throughout time; it is not sufficient to write the code correctly. We must actively
work to avoid code from deteriorating over time since we have all witnessed it happen.
You shouldn't expect this essay to turn you become a proficient coder. You cannot expect
to receive "code sense" from it. It can only demonstrate how skilled programmers think
and the strategies, techniques, and equipment they employ. The rest is up to you.