TechHui

Hawaiʻi's Technology Community

I often find myself responsible for designing system architectures. This isn't an accident. I like figuring out the big picture that causes all the pieces of a system to fall into place. The better the architecture is, the more the answers to follow-on decisions (e..g, system boundaries, class hierarchies, internals APIs) seem self-evident. With a solid architecture, first-order features have elegant solutions that automatically extend to second-order features and system extensions.

The primary job of a system architect is to create the design, but a close second is to communicate it and facilitate its understanding and implementation. I think the primary key to successfully describing an architecture, whether for a solo effort or to a team, seems to be the succinctness of its description.

At their core, software development technologies seem to have followed a pretty straightforward trajectory. Each iteration provides a denser vocabulary that results in simpler system descriptions. By software development technologies, I mean the tools we use to express ideas. So, machine code gave way to assembly and then high-level languages. A high-level language lets us specify dozens of assembly instructions (hundreds of bits) in a single line. Modern languages reduce the number of tokens or lines of code we have to enter. C++ supports optional parameters and templatized functions and types. More modern languages allow syntactic and semantic elements to be optional--parentheses can be left off, type names inferred.

The trend seems to be continuing with things like C# incorporating data access as first order language constructs (i.e., LINQ), and platforms like Rails and Grails that rely on convention over specification. Each of these reduces the number of languages or the amount of code to be written.

In purely conceptual descriptions, above the language level, we have abstract data types and object-oriented methodologies, which allow us to describe domain models in terms of type names and operations, but even more importantly, they let us imply responsibilities and relationships between types. Describing something as a 'stack' or a 'queue' is sufficient to imply its operations as well as a large number of constraints on its behavior. Similarly, a well named element in a type hierarchy can imply all the richness of the domain object it models as well as the relationships the type has to other types. In a well-defined type system, simply the names of the types along with single sentence descriptions should be sufficient to communicate the bulk of the architecture. Design patterns jump us up another level, and let us refer to whole systems of types with short names (e.g., factory, composite) that are hugely dense in the information the communicate.

All cool, yeah, but why is any of this important? Because coding in the large is hard. The main challenge of writing a big system is to keep the large-scale design--it's principles, and patterns--in mind while simultaneously organizing class hierarchies and implementing well-formed loops. The denser the vocabulary for describing the high-level, the more room is left over in my head for other things. And there are always plenty of other things.

Views: 204

Comment

You need to be a member of TechHui to add comments!

Join TechHui

Comment by Nathan Dwyer on April 4, 2012 at 7:44pm

Probably, the piece I left out of the above post was that I've found terse, clear definitions to be fundamental to good code but even more vital to good communication.

The best designs I've worked with succeeded because the developers could talk in shorthand, and in very few words outline an idea and imply all the correct ramifications. Long technical specs generally are only realized on paper and never become the living language of the team discussion.

Simultaneously, if I can check my own work against a one or two sentence specification, I can remain much clearer about what it is I'm doing and whether I should be doing it at all.

Comment by Daniel Leuck on April 4, 2012 at 5:51pm

Great post. Being a software engineer is a lot more fun than it was ten years ago. I love how languages like C# and Groovy allow you to express functionality with such terseness and clarity. LINQ is a thing of beauty, and Groovy's elegance is apparent in GORM's domain classes. It took many years and a lot of false starts to get ORM right, but we finally have excellent ORM framworks in all major languages.

Even non-Rubyists should thank Rails for slaying the XML configuration dragon. Its forced frameworks in other languages to step up in terms of efficiency of expression and simplicity of configuration. Framework designers: Don't make me think about your framework. If I'm spending more time thinking about your framework than I am the task I need to accomplish then you have failed.

The essence of good software design is summed up in Einstein's quote, "Everything should be as simple as it can be, but not simpler." The software engineers who get you in the most trouble are those who find complexity in simple problems.

Comment by Anže Žnidaršič on March 21, 2012 at 1:41pm

I'm currently learning Ruby on Rails. I've been using PHP for 10 years with Zend Framework (MVC fw) for past 2 years. When switching to RoR I at first didn't like the strict naming conventions, but I soon saw the benefits of focusing only on my business logic and not have to deal with small things like creating db migration files. It is scary at first though, since many things are done behind the scenes. I feel better when I look into the source of the framework to truly understand it.

Well it kind of made me search for PHP alternatives for the same things and of course they exist. Even mixins were introduced with PHP 5.4.

p.s.

I recommend iReader google chrome extension for reading blog posts on TechHui, it's really friendly to the eyes.

Comment by Chris Sass on March 19, 2012 at 1:42pm

Very insightful!  I couldn't agree more.

Sponsors

web design, web development, localization

© 2024   Created by Daniel Leuck.   Powered by

Badges  |  Report an Issue  |  Terms of Service