Discussions about software patents always make me doubt the validity of Computer Science both as a science and engineering field.

Science, as a whole, is focused on gathering knowledge through a defined method and set of experiments.  The ultimate goal is to learn new things and share them for the greater good.

Engineering is focused on applying knowledge to solve well defined problems.  This is achieved by following codes and guidelines set forth by years of experience and sharing of solutions.

Computer science, in the form of commercial software development, does not follow either of these models.  New knowledge and innovations are patented.  Experience and amazing solutions are hidden behind non-competence and non-disclosure agreements.

Why does the illusion of Computer Science live on?  More importantly, why isn’t it maturing like other science and engineering fields?

par·a·digm – example, pattern; especially : an outstandingly clear or typical example or archetype

Merriam-Webster dictionary

There are many paradigm pitfalls that we, as developers/designers/analysts, fall into. The most common reason for our consistent trip-ups is the comfort we feel when using a concept we have successfully implemented before. Unfortunately, staying in our comfort zone stifles creativity and often leads to bad designs. Here are some paradigms and ways to recognize you are falling into them.

More…

Smarty is a templating engine for PHP.  Traditionally, Smarty is used to abstract presentation logic from business logic and act as the View layer in an MVC.

Abstraction of presentation logic is an important, but often debated practice.

To further abstract business logic, I use class interfaces to hide information from the view.  Namely, the Iterator and ArrayAccess interfaces.  Implementing these interfaces in all value objects allows developers to treat any view layer variable as an array, effectively hiding all object related data.

More…

One of the goals of Zend Framework is “to provide a lightweight, loosely-coupled component library simplified to provide 4/5s of the functionality everyone needs and that lets you customize the other 20% to meet your specific business needs.”

When I began using ZF, I thought having 4/5ths of the functionality done from the get go would mean I would do 1/5th the work for 5/5ths the credit.  Sounds perfect.

Fortunately for my customers, it didn’t quite happen that way.  Cutting out 4/5s of the low-level grunt work coding let me focus on the interesting problems, the usability of the interface, the missing pieces.  It let me focus on the business side of code.

Sure, many developers love to design a really sweet algorithm for hashing files, or sorting associative arrays, or even sending emails.  Developers can easily wrap their heads around these intrictate technical problems and provide elegant solutions.  But what does that do for the business?  If business problems are not solved just as elegantly; nothing.

It is the job of developers to create elegant business solutions, also.  But, It is often hard to find time for both.  We fall into the comfort of technical problems and pass off responsiblity for business solutions to other (think PMs, customers, business analysts, QA).

Instead of eliminating 4/5ths of my work, using a Framework freed me up to spend that time on business solutions.  It led to a far better understanding of business problems and therefore more sound business (and technical) solutions.

The fractions here are simple, but implementing a technical framework so your developers can focus on business solutions can be challenging.  I have found success by identifying the 4/5ths of code that are core to my business, Facebook Development.  I have created a framework to support that core, leaving only the business details of each application.

You can be successfuly by spending time up front to identify the core objectives of your business and matching your framework to those objectives.  Doing so will allow you to spend 4/5ths of the time solving 6/5ths of the original problem.

And, if you’re good, you’ll get 7/5ths of the credit.

Design patterns are great, and ActiveRecord is one of the most useful when development cycles are short.  That being said, database abstraction might be one of the dullest programming problems.  And it has been done by many people, both smarter and more experienced than you and me.

Zend_Db has grown into a mature abstraction of another abstraction, PDO.  The obvious benefits are the great documentation, common API with the rest of Zend Framework, and the ability to extend and implement other abstractions besides PDO.

More…