Monday, June 23, 2014

Success, Failure, and Tradition

A quick post about my reality:

Success is attainable through failure, and tradition is a crutch.

I'm amazed at how many people think that they can envision some favorable outcome and attain it on the first try, flawlessly, with no course adjustments. This is as silly as imagining that a child can learn to walk simply by possessing the desire and some careful instruction. From my observation, anything even moderately complex and less automatic than breathing requires trial and error and the most important skill to learn is how to accept failure with open eyes and learn from it.

In fact, I'd suggest that a critical part of learning something new is attaining an understanding what failures led to WHY it's done a certain way and not one of a million other ways. Sometimes the answer is buried in history and in fact, there might not even be a great reason for doing it that way anymore. One warning sign I use as my gauge on when this may have happened is when discussing an issue and someone (perhaps even myself) cannot answer 5 whys. In short, precedents and tradition are convenient ways to avoid failures others have already learned from, but can also lead to the pitfall of "doing it the way we've always done it".

Being afraid of trying something new because it hasn't been done or "everyone knows" it isn't done that way and it "might fail" is not a way to be successful. To truly succeed, abolish fear of failure and replace it with fear of not learning. Additionally, take a look at traditions and understand why they exist and what they are really teaching.

Friday, June 20, 2014

We are not our code

For many people (myself included), creating software is difficult, rewarding, and enjoyable. There is a feeling of pleasure in the act of creating something that is ultimately useful for someone... either for commerce, pleasure, or even the mundane (writing software to keep a deicer working properly...cool... yeah, that's a pun). It's important to keep things in the proper context though, you are not your code, I am not mine, we are not our code, to be effective, we must decouple our ego from our code and embrace Egoless Programming.

Software should not be an extension of ourselves because software is much more transient than even we are, it's supposed to be, that's what makes it cool. Technology changes, the state of the art moves forward, patterns evolve, die, reemerge in a new form. In a way, deconstructing what's been done before and reforming it into something new is where the value of solid software development comes from, not from building the "ultimate answer machine".

The problem is, many people get so intimately involved with their software, their baby, that they cannot decouple their ego from their code, it becomes an extension of themselves. Moreover, they are not able to accept criticism of their baby, their baby isn't ugly!. To be truly effective in technology, you must accept your baby might possibly be ugly and be able to love and embrace that ugliness.

The good news is that really good technologists love ugly and beautiful babies equally. Crappy software is just as difficult to create... heck maybe even MORE difficult, but that doesn't mean it isn't valuable. Moreover, just like people, code will age: it will get wrinkles, warts, it will break, become fragile, and eventually need to be retired to that from which it came. That's OK, it's the way things should be and it's reality. Failing to acknowledge that reality will hamper your progress in creating new things because there will be no more room for new things, you'll be stuck always thinking about the old things and clinging to the prison of "the ultimate answer machine" you think you created 20 years ago.

Take the red pill

Wednesday, June 18, 2014

Through The Looking Glass Architecture Antipattern

An anti-pattern is a commonly recurring software design pattern that is ineffective or counterproductive. One architectural anti-pattern I've seen a number of times is something I'll call the "Through the Looking Glass" pattern. It's named so because APIs and internal representations are often reflected and defined by their consumers.

The core of this pattern is that the software components are split in a manner that couples multiple components in an inappropriate manner. An example is software that is split between a "front end" and a "back end", but they both use the same interfaces and/or value objects to do their work. This causes a situation where almost every back end change requires a front-end change and visa versa. As particularly painful examples, think of using GWT (in general) or trying to use SOAP APIs through javascript.

There are a number of other ways this pattern can show up... most often it can be a team structure problem. Folks will be split by their technical expertise, but then impede progress because the DBA's who are required to make database changes are not aware of what the front end application needs so the front end developers end up spend a large amount of time "remote controlling" the database team. It can also be a situation where there is a desire for a set of web service APIs are exposed for front end applications, but because the back-end service calls are only in existence for the front end application, there end up being a number of chicken and egg situations.

In almost every case, the solution to this problem is to either #1 add a translation layer, #2 #1 simplify the design, or #3 restructure the work such that it can be isolated on a component by component basis. In the web service example above, it's probably more appropriate to use direct integration for the front end and expose web services AFTER the front end work has been done. For the database problem, the DBA probably should be embedded with the front-end developer and "help" with screen design so that they have a more complete understanding of what is going on. An alternate solution to the database problem might be to allow the front end developer to build the initial database (if they have the expertise) and allow the DBA to tune the design afterwords.

I find that it's most often easiest and most economical to add a translation layer between layers than trying to unify the design unless the solution space can be clearly limited in scope and scale. I say this because modern rapid development frameworks ([g]rails, play...) now support this in a very simple manner and there is no great reason to NOT do it...except maybe ignorance.