Agile Zone is brought to you in partnership with:

In the course of his 30-year career, David Bernstein has trained more than 6,000 developers at hundreds of companies on how to improve their software design and construction. His company, Techniques of Design (http://www.techniquesofdesign.com), provides customized training, coaching and consulting to software developers and development teams around the world, enabling them to master essential practices, including Agile, Scrum, XP, test-driven development, design patterns and related techniques, for building high-quality software more rapidly. David is a DZone MVB and is not an employee of DZone and has posted 18 posts at DZone. You can read more from them at their website. View Full User Profile

The Enemy of the Great

04.01.2011
| 837 views |
  • submit to reddit

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.

References
Published at DZone with permission of David Bernstein, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags:

Comments

Shumona Kapil replied on Sun, 2012/02/19 - 9:27am

Totally agree. Developers aren’t given enough credit here. Most developers are good at what they do and don’t deserve to be on constant death marches! It’s just not sustainable!

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.