Introducing Siege

The Siege Project


A few months ago I wrote a post about what I consider to be good software design practices. I have thought a lot about the topic of what makes a design “good” for many months as I’ve worked on challenging systems both in my professional life and personal life. High coupling, massive frameworks, portability and testability problems and a plethora of other issues have helped to shape and change how I view software development. During that time, I began to work on several software projects to help me reduce coupling issues, increase reuse and testability.

Collectively, I call these this initiative Siege. This name is a wink-and-nudge towards some challenging frameworks I’ve used and the feeling that I’ve had at times of being under siege from the codebases I’ve had to work on. 

What is Siege?

Siege represents my philosophy on software design as much as it represents a set of frameworks that I’ve been working on. At every design decision point, I’ve tried to build against my list of design values. I’ve reviewed the work constantly, making revisions and updates to hold the designs in line with those values as much as to ensure the code itself is functional. I will be writing blogs specifically about each component in the framework (there are a few, and will be released over time). This blog, as an introduction, serves to explain my design values and principles, why I hold them, and why they driven me to work on this project. 

What are the design principles and values that Siege adheres to?

I have a small list of values that I use as guideposts for Siege. They are:

  • It must be easily understood
  • It must be easily consumed
  • It must be easily extended
  • It must be easy to maintain
  • It must be easy to test

That’s it. Those are very broad goals, and very subjective. I’ve learned a lot by looking at and using other frameworks, such as Windsor, StructureMap, Ninject, NHibernate, Active Record, Rhino Commons as well as more than a few others and have come to certain conclusions about things I like about these frameworks, and things I do not. Therefore, I have developed Siege along the following convictions.

  • I don’t like massive frameworks that over time have become monoliths. I don’t like frameworks that try to solve all areas of a problem domain in one tool. I prefer frameworks that are specialized to a specific problem and address that problem. Therefore, Siege will be a component framework that will involve multiple components that work in tandem to create specific and highly-targetted solutions.
  • I don’t like frameworks that only work with itself, or that in the process of making it easy to work with its other individual components it makes it harder to integrate other frameworks. I don’t like to have a laundry list of things I must use in order for a solution to work. Therefore, Siege will be designed to integrate with other frameworks through light-weight and well-defined interfaces. Siege does not intend to reinvent the wheel, and while there may be occassional overlap of functionality, Siege will integrate as easily as possible with other frameworks to provide functionality to a consumer.
  • I don’t like high levels of complexity in configuration and consumption of frameworks. Therefore, Siege will provide simple and straight-forward syntax to accomplish 80% of use cases while not preventing the fulfillment of the other 20%. In other words, Siege should be able to fulfill most of your normal needs, but in cases where you need a specialized component to integrate, Siege will not hinder your ability to integrate with those solutions.
  • I don’t like rubbing up against the limitations of a framework without a way to extend it to cover my needs. Therefore, Siege will be built with extensibility in mind. You should not have to modify the framework to introduce new functionality, but rather, extend what is already there. This is a long-term goal and will require diligence to accomplish.
  • I do not agree with the idea of things magically working with the developer not knowing why. I don’t agree with the idea of programming against a number of conventions so large that it becomes almost an exercise in learning a whole new programming language to use a tool. I do not feel that these philosophies enable a consumer to understand what is happening in their system. Therefore, Siege will not by default provide a lot of “automagical” functionality. Everything should and will be easy to trace and understand. While Siege will not behave “automagically”, there will be functionality available to provide for easy of consumption while still adhering to a philosophy of “be explicit”.
  • I do not like coupling directly to frameworks or building applications directly on them. Siege is designed to be as light-weight and non-intrusive as possible and provides abstraction mechanisms between itself and other frameworks as a result.

The bottom line is that Siege’s design philosophy is to be extensible by the consumers, to provide a simple set of interfaces that developers can understand and use, and to conform to a problem and solution … not force the problem or solution to fit to Siege.

“Talk is cheap… Show me the code.” 

You can access the source code to the first component I am releasing here or get the binaries here. My next posts will go over what it is (and isn’t), how to use it and how to extend it. As more components are released, I will put up blog posts for those as well. There are several in the pipeline, but many of them still have a few revisions to go through to ensure that I have been as diligent as possible to not only adhere to my philosophy but also to ensure that I have as high level of code coverage as I can. I practice Test-Driven Development, but it is fair to say that many times I miss cases and have to go back and cover them. Additionally, I find in review that some functionality needs to be reworked, removed, or in some cases, new functionality needs to be added. 

Happy coding!

Related Articles:

    Post Footer automatically generated by Add Post Footer Plugin for wordpress.

    This entry was posted in Siege, Software Design. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
    • John Sonmez

      Looks like an interesting idea. I definitely agree with you about the high levels of complexity in configuration and consumption.

    • Grant Palin

      Love the name, it is very fitting. I can relate to the feeling of being under siege by all the various tools that are available.

      Sounds like the framework will be quite useful, if only to provide a little abstraction from the complexities of the tools.