LazyProgrammers: Front Matter and Chapter 1

Lazy Programmers

The Good, the Bad and the Ugly

By Michael C. Daconta

© 2021 by Michael C. Daconta, All Rights Reserved

Acknowledgements. v

Chapter 1 Introduction.. 1

Chapter 2 The Good.. 4

Chapter 3 The Bad.. 12

Chapter 4 The Ugly. 35

Chapter 5 Conclusion.. 49

Appendix 1  ACM Code of Ethics. 55

Appendix 2  Full Source Code Listings. 69

Index. 76

Figure 1  A Development Cycle. 6

Figure 2  Knuth Vol 3. 13

Figure 3  Destroying Architectural Cohesion.. 36

Figure 4  System Regression Analogy. 38

Figure 5  A Paycheck Programmer. 46

Listing 1. LazyInstantiation.. 9

Listing 2.  Bubble Sort14

Listing 3. Lazy Connection.. 16

Listing 4. Lazy Logger. 19

Listing 5. SmellyCode. 23

Listing 6.  TechDebt25

Listing 7 RetryLogic. 30

Listing 8. ImageTool39

Listing 9. ImageToolTest41

Listing 10. Maven Run of Junit Tests. 44

            This is the first technical book I have written in a while, and it feels really good to be back in this space.  Sort of like slipping into your favorite pair of jeans or sliding behind the wheel of a comfortable ride – it just feels “right”.

            I would like to thank my family, friends and colleagues that support me in all my endeavours.    First is family – we are a close-knit bunch and getting closer every day.  There is no filter and lots of laughter.  I am so blessed to have you all in my life!  To my sweetheart, Lynne, who stands by my side, holds me when times are tough and loves me for who I am: thank you. To my nephew Jeremy Belden, thank you for helping us every day without fail, without complaint and with joy in your heart.  You are a true blessing to us! Special thanks to my brother, Joseph Daconta, for helping me with the cover layout.

            To my friends and colleagues – it is so much fun to laugh, play and plan things together.  You add a richness, levity and vitality to my life that refreshes me.  Special thanks to my early reviewers – Shawn Vettom, Dave Boyd, Ed Danis, Tony Hong, Scott Hellenbach, Raymond Chian, Kevin T. Smith and Dan Green. Very special thanks to Bo Hong for creating an amazing cover illustration!  She is a truly gifted graphics artist who is destined for great things!

            To my fans and readers, let’s keep exploring this wonderful world together!

            Warm wishes,

                                                Michael C. Daconta

                                                Woodbridge, VA

 

           

In my 32 years of software development, I have worked my way up through every programming position from software engineer (level 1, 2, 3), Systems Analyst, System Architect (level 1, 2, 3), Team Leader, Chief Developer, Technical Director, Chief Scientist, Director, Chief Technology Officer and eventually various Vice President positions.  That list of positions is not to impress you; instead, it is to illustrate the breadth of my experience to include working with every type of programmer: young and old, stupid and smart, cautious and bold, and even lazy (lazy-good, lazy-bad and lazy-ugly[1] as we shall see).  I have seen this issue from both sides by being the manager of a self-described “lazy programmer” and from tackling technical debt caused by the layman’s definition of laziness (the reluctance or disinclination to work).  Given the tension caused by this ambiguity, I decided it is high time to settle this controversy.

Why is “Lazy Programming” controversial?

            Lazy programming is controversial because there are many articles on the web that praise laziness as a virtue[2].  That this flies in the face of the common definition of laziness is obvious.  Here is the definition of lazy from Wiktionary[3]:

Lazy (adjective) –

1. Unwilling to do work or make an effort; disinclined to exertion. 

2. Causing or characterized by idleness; relaxed or leisurely. 

3. Showing a lack of effort or care.  

4. Sluggish; slow-moving.

5. Lax.

6. (of a cattle brand) Turned so that (the letter) is horizontal instead of vertical.

7. (computing theory) Employing lazy evaluation; not calculating results until they are immediately required.

8. (Britain, obsolete or dialect) Wicked; vicious.

Some programmers even take this one step further and praise laziness as even a characteristic of “great” programmers.  For proof of this, they point to quotes from well know programmers like Bill Gates and Larry Wall.  Bill Gates is often attributed[4] the quote, “I choose a lazy person to do a hard job. Because a lazy person will find an easy way to do it.”  While that may be wrongly attributed to Bill Gates, Larry Wall wrote in the book, “Programming Perl”, about the three virtues of a programmer.  The glossary contains this definition of Laziness:

“The quality that makes you go to great effort to reduce overall energy expenditure.  It makes you write labor-saving programs that other people will find useful, and document what you wrote so you don’t have to answer so many questions about it.  Hence, the first great virtue of a programmer.  Also hence, this book.  See also impatience and hubris.”[5]

We will dig into detail on Larry Wall’s definition of laziness in the next chapter, for now we only want to focus on the attribution of a negative characteristic to a person as a mark of greatness.  Is this word play or language trick useful for the development of software engineering as a professional discipline? And this now brings us to the purpose of this book – to answer simple questions like this:

            “For skill development and the furtherance of your career, is Laziness a Virtue or Vice?”

            “For a team leader, should you develop Laziness in your junior developers or squash it like a bad habit?”
            “For the profession of programming as an engineering discipline, does Laziness enhance or reduce the respect our profession garners from society at large?”

This book will strive to answer these questions for you by examining the practices, hype and reality of “lazy programming”. 

To cover this topic from multiple angles, the perspective will sometimes switch between the roles of software developer, team leader and program manager.  The context and required technical depth dictate which role is most appropriate.  For software developers, code examples are provided (the website will contain examples in other languages).  For team leaders, commentary and summary analysis is often provided to understand the ramification of the techniques on team dynamics.  For program managers, system-level and program-level ramifications are highlighted.  Let’s begin this discussion with the “good news”.