Development Pearls

These Wisdom Pearls address the way that the Developer thinks about the career activities.

These pearls create a better understanding of the engagements and projects that make up their career.

The Key to Legacy Code Understanding

When a Developer begins a new assignment that is a “Brownfield” legacy project the first mountain to climb is an understanding of the current code base.

It is more than likely that thee will be code that is foreign to the Developer.

It may be developed solutions from design patterns that are unknown.

It may be aspects of the Developer’s “Science” that is new to the Developer’s toolbox. 

Embrace the fear, it is your opportunity for growth.

Tap into the power of Google and other on-line tools such as Pluralsight training center to give you the confidence you need to climb the “Code Mountain” .

Use the “Forces” around you but Only ask for clarity about the specific implementation of code AFTER you understand How underling design intent is being used.

Do Not Ask Questions that You,
as a Professional, Should Already Know
This Will Cost You Unrecoverable Credibility!!!

The Modern Developer Art and Science

Design Principles,  General Code Standards, Design Patterns and Development Processes are platform independent.

They apply to all development environments, languages and technologies.

They are referred to as “The Art of Software Development”.

They create a common “Paradigm of Thought” for all Developers seeking to travel on the World Class path.

Your though paradigm needs to be second nature to you while you are developing your “Science”.

The science of software development are the tools you used to create your development code palette.  

Develop Solid Art Skills that will Drive your Science Skills

How Good is Your Work Really?

No matter how good you think you are in how you develop your code solutions, the real test is what the developers who have the responsibility to consume or maintain your delivered code base.

Always evaluate you work from the perspective
of being the recipient of the work

Avoid the Emotional Ownership Trap

We need to have pride and confidence in the paths we choose to solve our technology challenges.

Practicing your Art to set the foundation for your Science solutions will always produce good results.

But never forget that there always a handful of good solutions other than the one you selected.

Do not let your Pride and Ego prevent you
from seeing, learning and accepting
alternative solution possibilities

Attention to the Details of Assembly Folder Structures

You have a responsibility to the Developer tasked with understanding and maintaining your code base.

Visual folder structures that map to Namespace encapsulation is a critical responsibility you have to aid to the understanding of the solution assembly stacks you create.

Always organize your projects in such a way that the Folder Names, File Names and Assembly Names create a simple abstraction of the details of the solution. 

A developer should be able to find any major area of your project
in less than thirty seconds

A Thought on Big Design Decisions

Most projects, that are more than just a simple Website, start without a true understanding of the desired outcome.

As the initiative progresses more information is available and a clearer picture of the desired outcome emerges.

It is better to defer big decisions to the last possible moment as a greater understanding is available at that time.

Deferring big decisions o the last possible moment
will help prevent rework
that will be required due to the maturity
of the requirements of the engagement

The Architect’s Sandwich

A major challenge for most large projects is an understanding all of the functionality that the Client expects to be delivered.

Most of the time this is an iterative process. As the project evolves more information surfaces.

The “Elephant” is the expected business functionality, the “Sandwiches” are the sub-projects created from currently available project requirements.

By creating a simple “Epic User Story” that defines the overall goals, smaller “Child User Stories” can be added during the project knowledge iteration cycles.

You want to create new “Sandwiches”
in the form of “Child User Stories”
that reflect the project functionality goals
as the project evolves

Preexisting Code Guidelines

Many of us use preexisting code blocks as a starting point for code development.

This is generally a very good practice as it gives us the ability to create designs that can be brought to market faster for our Clients.

The Issue with this process is when the copied code has feature or performance problems or is in poor shape regarding its lack of Best Practices and Code Standards.

All copied code should be included in your Unit and Integration tests and be treated as the “Green” stage of Test Driven Development (TDD).

All code chosen for reuse in your project should be part of your testing process and be refactored into Best Practices and Code Standards and be part of the “Yellow” stage of TDD.

Do not become a Monkey See Monkey Do Developer

Don’t Propagate Bad Code

If a Class has more than one responsibility for the calling class methods, then it is considered a “Fat Class”. Fat Classes tend to get larger as the project matures.

The Class becomes a “Method Container” for any new Method, regardless of its relationship to Class’s primary responsibility. The files can become thousands of line of unrelated code.

Over time, the software entities are unmanageable and become prime candidates for regressive errors when an unrelated section is changed.

Changes in one section, of the multi-responsibility Class, can cause run-time errors in other obscured sections making debugging more difficult.

Refactoring the Class into smaller Classes’s that implement their own Interfaces will define the Class’s Single Responsibility and prevent propagation of the problem.

This process complies and supports the
Interface Segregation Principle in S.O.L.I.D. design.

Taming Murphy’s Law

We have all lived “Murphy’s Law”, in one form or another, in our personal and professional life:

“If Anything Can Go Wrong … It Will”

The primary thought paradigm to manage the inevitable appearance of “Murphy” is to “Plan for the Worst, but Hope for the Best”.

In Code development this means a “Bullet Proof” Error and Exception Handling process.

Error handling is not just “Try/Catches” that catch catastrophic run-time errors.

Conditional checking on every return result from a Method call for its expected content is the major responsibility of your error handling process.

Return response objects need to be guarded against the following:

1. Null Returns – This action prevents Null Reference Exceptions being thrown when a null object’s Software Entity is being set or consumed.

2. Empty Collections – Record sets that need content to perform correctly in the calling Class Method

3. Lower Stack Errors Collection Count – Error messages, which have been propagated from lower modules, let you know that the return result is not properly formatted for delivery.

4. Success Predicates Failures – The proper use the Request/Response pattern returns a simple Boolean “Success” predicate that can be conditionally checked for a ‘True” state. A “True” state guarantees that the resulting response is properly formatted and available for consumption.

All Methods that are primary candidates for Murphy attacks
should be well guarded with an Exception and Error Handling solution
that can create a code block for recovery, notification and logging

Managing the Complexities of Your Software Designs

Software development is inherently complex by nature.

The management of its complexity is the responsibility of all Developers on a team.

In Code Complete 2, by Steve McConnell, defines the management of Software complexity responsibility:

“The Primary Technical Imperative in Software Development is to Manage Software Complexity”

You should always be prepared to explain and justify any design that adds perceived complexities to the Solution’s project.

Occam’s Razor Principle for Software Development

Occam’s Razor, or Ockham’s Razor, is a principle attributed to the 14th century logician and Franciscan friar William of Ockham.  Ockham was the village in the English county of Surrey where he was born.

The original principle states:

 “Entities should not be multiplied unnecessarily.” 

The most usable translation of the principle for Software Development states:

“When you have two competing development solutions that create the exact outcome, the simpler one is always better.”

When developing a solution, if that little voice in you is screaming that you are over-complicating the code, look to Occam for guidance and refactor the code to a simpler design.

The Occam’s Razor Principle supports
Steve McConnell’s Primary Technical Imperative
in Software Development: Manage Complexities

The Reality of the Technology Relationship to Business 

A major contributor in failed or less than fully successful Software Development initiatives is the belief that Technology drives Business success.

Technologists tend to be rather egocentric in their belief that Business cannot succeed without Technology.

In reality Technology would not exist without the business requirement for its use.

Domain Driven Design (DDD), originally outlined by Eric Evans, tries to solve this dilemma by created a Technology model that is derived and driven by the Business model. The free download “Domain Driven Design Quickly” version by Abel Avram and Floyd Marinescu can get you an understanding of Eric’s original thoughts.

DDD creates structures that mirror the real world business environment using terminologies that are Business-centric not Technology centric.

These terminologies are referred to as the Ubiquitous Language: a Lexicon of Terms that all members of the Business and Technology teams understand with the same meaning.

Code is created with this Lexicon for its naming conventions. If the name or meaning changes, so does the code.

This process creates solution modules that can more easily adapt to the changing environment of most business solution initiatives.

Never think that Technology drives the Business goals:
The Business Goals ALWAYS drive
the Technology solutions in every possible way 

Your Development Toolbox

The creative outcome of an artist depends on the materials and tools the artist uses to create the artistic work.

Good materials in the hands of a poor artist will not produce any better work than if that artist had great materials.

Good tools in the hands of a poor artist will do little to help the artist produce great works of art.

A Great Artist will Benefit Significantly

… With Great Materials and Great Tools

In Technology tools are change rapidly.

 The task of even keeping up with the changes tool offerings presents its own challenges.

The Modern Developer must create a “Knowledge Pipeline” of emerging Technologies but also has responsibilities to learn the new tools available to implement those Technologies.

A modern developer must be aware of not just new Technologies
but also of the tool available to implement those Technologies

Some of these Wisdom Pearls are original and some are common beliefs passed down through the ages.

Power Resides in the Wisdom They Contain

… Easy to Remember and Repeatable

…… Share the Wisdom

Wisdom Pearls have great value when used in real life situations, both Professional and Personal.

Summon your “Inner Dragon” when times call for your “Wisdom Pearls“