MySQL or Microsoft SQL Server? Should we use Factories in our code? What about static methods? What are the right answers?

As software developers, our goal is to produce working code that contributes to a software system or application. How we get to that working system could take many different paths. There is an infinite number of routes to that working software, and any number of decisions along the way could have gone the other way and you could still end up with working code. So how is it, that we can say that there is a right way and a wrong way to write some method, or there is a right and a wrong framework, or even a right and a wrong language for any task?

The answer is that there is no right or wrong way to do most any thing in software development. There is, however, a better way and a worse way. That is to say, there are some decisions that you make along the way that will make your software better, and some decisions that will make it worse?

Better how and worse in what way?

Better and worse are subjective terms, but generally “better” software is easier to maintain, preforms better, is easier to read and understand, more reliable, and improves upon all of the other software development goals. (By the way, cyclic dependencies hurt a software system’s goals read more…)

So whats the point? The next time you’re faced with making a decision, or learn of a decision that someone else has made, don’t judge the decision as right or wrong. Understand that both options, or many different options are all good solutions, but that some are better and some are worse fits for the software that is under discussion.

What does this mean for us at 72 Miles? Once we grasp this simple concept, we’re able to produce code faster, by not agonizing over every decision. No matter what decision is made, we are one step closer to a product that users can get their hands on, and after all, thats why we write the code. In the web applications that we write, most any aspect of any of our software can be refactored, removed, or replaced in the future, once an alternative is discovered.  I think this is referred to as being agile.

So the question is, should we use factories in our code?

Released architecture-rules-2.0.3 last month.

Changes

• issue-23 determine which dependencies are optional usability
• issue-24 slashes in unix and windows are different, paths can not be read usability
• issue-25 cycles test not run with XML configuration usability
• release notes

We have already fixed a couple of issue for the next release, and completed a handful of tasks that have made improvements to the library. We have been getting a lot of help from mykola.nickishov. Since he was submitting so many quality patches, we invited him to join the project as a committer. He he accepted. Thanks Mykola.

We’ll make a release soon which will describe how to setup your pom.xml to pull down Architecture-Rules automatically, and enhance the CyclicReduendencyException message to point out the exact classes that are involved in the cycles, rather that just reporting on the package. If you can’t wait until the next release for these features, the subversion trunk has historically been stable, so you can checkout the project from source.

Architecture-Rules

At 72 Miles, we not only heavily rely on open source software, but we also partake in open source software development. We created the project Architecture Rules in response to a tutorial on using JDepend to “assert architectural soundness”.

Architecture Rules can be described as

Assert Your Architecture! with this open source java library. Architecture Rules leverages an xml configuration file and optional programmatic configuration to assert your code’s architecture via unit tests or ant tasks. This test is able to assert that specific packages do not depend on others and is able to check for and report on cyclic dependencies among your project’s packages and classes. This project wraps a industry accepted JDepend to simplify the process of maintaining a solid software architecture.

So far we have made a half dozen releases and have had a few of them submit patches and report some minor issues. We expect this project to eventually become a common tool under most developer’s toolbelts.

Check it out at http://architecturerules.googlecode.com/svn/docs/index.html