Designing a new application or learning an existing one

Quickly becoming an expert in existing applications and designing new applications are two of my core strengths. For both, I utilize a Six-Sigma SIPOC diagram. A SIPOC diagram consists of Suppliers, Inputs, Processes, Outputs and Customers. I generally begin at the Outputs/Customers side of the diagram and work my way back to Suppliers.

The timing of the next steps depends on the development life-cycle methodology being used. Once a diagram has been completed and the planning phase is complete, the following steps can be taken:
1) Develop data access objects for the Outputs.
2) Develop test classes with mock data exercising the data access object.
3) Have Customers(consumers of the Outputs) verify output content.
4) Develop business Processes to populate collections of objects being sent to Outputs data access objects.
5) Develop test classes for business Processes.
6) Develop manager class for business and data access objects (business classes never call data access objects directly).
7) Develop data access objects for the Inputs.
8) Integrate data access objects for the Inputs into the manager class.
9) Test, Test, Test.

Keeping It Simple!

One of the first things I learned in computer programming class was the KISS principle: Keep It Simple, Stupid!

Keeping it simple is not as simplistic as one might think. One must contend with the initial developer’s style, the countless modifications the code has endured, the pushy colleague sitting beside you demanding the use of the latest design patterns, etc…

Here are my top coding practices to keep it simple:
1)  Use meaningful variable names, such as employeeList for an List of Employee objects.
2)  Classes should be single function.  Don’t use the same class to calculate employee wages and to calculate the difference in calendar dates.
3)  Data Access Objects are the only classes that should interact with any persisted data, whether its the filesystem, database or some other source.
4)  Data Access Objects should only be called from a manager class.
5)  Business logic should be in a separate class (Business Object), making it testable without any persistence interaction.
6)  A manager class calls the Data Access Objects and Business Objects, utilizing Collections to shuffle data between them.
7)  Unit test should be written to test all business object functionality.
8)  Don’t be afraid to simplify (refactor) existing code.  Executing the JUnit suite will prove you didn’t mess anything up.

There are many books written on this subject, but these are the main points that I communicate with my teammates.  The overall point is to simplify things, as if the next person to look at the code is entry level.