Code Renaissance is about building great teams and great software. By exploring best practices, team interactions, design, testing and related skills Code Renaissance strives to help you create the team and codebase that you've always wanted.

Interesting Phrase - Paving the cowpaths

I just came across an interesting phrase: "Paving the cowpaths". It refers to creating programming automations for archaic processes (instead of redesigning the business process with existing technology).

The Rules

Novice to mid-level programmers are learning the rules and challenge the rules they don’t like (often out of convenience) whether the rules are good or bad.

Senior level programmers know the rules thoroughly and have often developed a dogmatic opinion of which rules are right and wrong.

Programming Gurus are those who methodically question when and why to either break or follow the rules. They examine what contexts make the rules valid and look for changes in context. They question their preconceptions and are open to new opinions. They are the ones who eventually change the rules and the ones who make new rules.

Aphoristic Code Musings

The word-play that follows is my own. Hope you enjoy.

Fixing bugs is easy; it’s figuring out whats causing them that’s hard.

Hours saved in requirements will cost you days in rework.

Hours saved in design will cost you weeks in maintenance.

How fast your application is delivered will be quickly forgotten; How reliable and maintainable it is will be often remembered.

Unidentified stakeholders: faceless assassins who will use hidden requirements to drive a stake through the heart of your project.

Avoiding clipboard inheritance

Clipboard inheritance is the practice of copying code from one location (class or method) to another in order to transfer functionality. This is highly likely to introduce bugs into your application for several reasons:

  • Any bugs in the copied code will be transfered to the new location.
  • Fixes will need to be made everywhere the code was copied; it's easy to miss one.
  • Mistakes are often made when adopting the code to it's new location and code that is specific to the old location can easily be overlooked.

Instead you should follow the "Once Only Rule": Any significant piece of code should be in one and only one place (this is popularly know as DRY - Don't Repeat Yourself).

This will mean refactoring the code to extract the functionality. If the code is repeated within a class then it should be extracted to a new method that can be used throughout the class. If the functionality is used by multiple classes then the functionality should be extracted to a new class which can be used by the other classes (composition).

Clever Kills

Clever Kills. I heard this aphorism for the first time this week and it immediately struck a cord. I have found that one of the first casualties to clever or novel approaches is maintainability. There are two nails in this board that I often hammer on.

The first is that complexity for complexity sake is evil. Complexity increases development time and reduces the clarity and maintainability of a project. It is important to evaluate the ROI (Return on Investment) on complexity in your code and design. An investment in complexity must yield returns in other areas (scalability, redundancy, configurability, deployability, etc) that are also a constraint of your application or environment.

Notice that I said that what you get in return should be a constraint of your application or environment. Designs should be as simple as possible given your constraints; no simpler and no more complex. Even if you expect that at some point the application will have functionality added to it, a simple application can be easily refactored in the future to handle future demands. Requirements change and the further in the future the needs are, the less clearly they are seen. A small single form application for 3 users probably shouldn't use n-tier architecture (even though there are lots of benefits to n-tier architecture) unless such an approch is standard or otherwise required in your environment.

This brings me to my second point; standard approaches are standard for a reason. They're typically clear and concise or, if they aren't, then at least they are well documented and widely discussed. Because of this -- and this is the best part about standard approaches -- anyone can maintain them. If you loose maintainability in a critical application (and when they're not working they're all critical, aren't they?) then it would take a huge trade off in another area to offset that loss.

If there is a standard way that meets the requirements then use it. Standard approaches have stood the test of time. Odds are your clever solution will fail somewhere down the line due to things you couldn't (or just didn't) foresee.

Welcome to Code Renaissance

Welcome to Code Renaissance.

This is a site dedicated to software engineering best practices and the exploration of what's new and interesting in our field. Mirriam-Webster's definition of the Renaissance talks about a period in history characterize by "flowering of the arts and literature and by the beginnings of modern science"; it's secondary definitions quantifies a renaissance as "a movement or period of vigorous artistic and intellectual activity". I believe that scientific fields can also undergo renaissance periods, which I define as times of great discovery and experimentation followed by standardization and reliability in the field.

Established fields like architectural engineering have already gone through their renaissance periods. If a bridge fails, it is likely because well establish construction guidelines and design techniques were not followed. If a software development project fails, well, there are guidelines and design techniques that could be pointed to, but they are not yet widely agreed upon or used in the industry. In addition, I believe many are yet to be discovered as programming concepts continue to evolve.

It is my goal to review important techniques and concepts, particularly those that I believe should be industry standards. I would also like to explore ancillary fields of study that have the ability to enhance or benefit software engineering projects.