DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks

The Enemy of the Great

David Bernstein user avatar by
David Bernstein
CORE ·
Apr. 02, 11 · News
Like (0)
Save
Tweet
Share
1.59K Views

Join the DZone community and get the full member experience.

Join For Free

They say that perfection is the enemy of the great and this is very true in software development. I used to believe that there was no such thing as the perfect design but now, after years of studying design, I think in many situations there is such a thing as a perfect design. The problem is that it is usually so complex that we would never want to implement it. But knowing it exists points us in a direction and gives us options for refining our design as needed.

I am known among my colleagues as a patterns guy but I use patterns only as needed. I know I can always refactor to patterns later so if I don’t have a requirement that need a pattern I will not use one. Doing the simplest thing is usually the best thing for now as long as my development practices don’t paint me into a corner.

When I teach design in my courses (http://techniquesofdesign.com/training/) I like to show examples of what good design is but I know that a lot of the time we are in situations that are so high pressure we just want to get something out the door that we are not too embarrassed by. But I find if we have a grasp of what good design is then we are far more likely to get close to it even when the pressure is on.

One of the most dangerous and inaccurate myths in software development is the idea that good development practices are much more time consuming then taking a “quick-and-dirty” approach. Sure, we have to make compromises when we develop and knowing the right compromises to make is an important skill to have as a developer, but often “pay now” verses “pay later” turns out to be “pay later and pay sooner than you ever imagined”. We can comfortably abandon gold plating but there are certain things that we should not abandon, even when pressure is on get something out the door.

When I study the truly great developers that I’ve had the privilege to work with there are certain things they do not compromise on ever. This is true in other fields as well. You will not find a construction worker decide a blueprint is too much trouble to fully execute or that certain materials called for in the Handbook of Civil Engineering are really not needed. When a 2’ x 8’ beam is called for in a support column it is not acceptable (or legal) to replace it with a 2’ x 4’ beam. The problem is in software the rules are not so cut and dry or even stated most of the time.

I met a chef once who told me he didn’t have time to be sloppy. When you prepare hundreds of meals in an evening you don’t have time to make your kitchen a mess. You must find ways to work sustainably. The same has to be true for us in software development.

Let’s face it, sloppy code is not really the right way to cut corners. Perhaps we should look at scaling back some features or at least changing their priority based on customer feedback since nearly half of all features put into software are never used anyway.

I am still surprised when I go into development shops where the developers live in a constant death march. Writing software should be sustainable. That is no way to build a career or to build a product.

Unfortunately, we developers sometimes get a bad rap among managers who see us as geeks striving for perfection at the expense of their schedules. In my experience this is rarely true. Most of the developers I meet are pros and we want to do our best but realize there are always compromises so we strive to make the right ones.

Software development

Published at DZone with permission of David Bernstein, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • Kubernetes vs Docker: Differences Explained
  • How To Check Docker Images for Vulnerabilities
  • A Brief Overview of the Spring Cloud Framework
  • Top 10 Secure Coding Practices Every Developer Should Know

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: