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 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.

Tuesday, June 10, 2014

Women in technology

When I stop and look around at work, I notice something that bothers me. Why is the ratio of women to men so low in technology? I've read quite a few posts from women who have lamented the locker room mentality of many technology shops and having been guilty of similar (often cringeworthy) behavior, I can certainly understand why this could be a significant detractor...but it seems like this can't be the sole reason. Only being intimately familiar with the North American technology workplace, I also wonder if this is true globally. I seem to recall on recent visit to a Chinese shop there being a higher number of women in the workplace.

I recall a conversation with my daughter from last night that immediately revealed my own bias. Her car was having problems with the cooling system and I asked her if she had fixed it yet (my son and I both took a look and just shrugged). After her reply in the affirmative, I asked if she took it to a mechanic...and she stated "No, I fixed it myself". Shame on me for first asking if she asked her boyfriend how to fix it (please, feminists, no bricks through my window) and shame on me again for staring at her slackjawed at her response to the negative. Frankly I was amazed, confused, proud, and also quite a bit troubled by my own response.

As she went on to explain how she texted all her male friends and realized that #1 the ones that knew anything about cars were unresponsive and #2 the rest of them were utterly clueless about repairing vehicles. After this realization, she stated she went out, popped the hood, found the problem (a cooling system hose was leaking), removed it, replaced it, and moved on sans male intervention or assistance. I would have completely expected this from one of my sons, but even now, I'm positively glowing with pride at her self sufficiency. Why?

To give context, the woman in question is 20 and just graduated from a four year institution with her Bachelor's degree last month, so she's smart. The same person held down a job for the almost the entirety of her college career, and at one point actually had two jobs (with a full class load). In high school, she was a middle distance runner and also played in the band, which imposed a brutal schedule that often had her busy from 6am until past 6pm... after which should would then do her homework. She's fastidious, watching her do homework and research was almost painful for me because ... well, I'm not an awesome student and just never really understood how she could do it. Moreover, she just signed up for another class over the summer to get another endorsement for her teaching certificate (her quote "Yay, now I can take college classes for FUN").

All that having been said it seems like I should have been completely nonplussed that she went and fixed what she ultimately stated was an obvious and easy problem with her vehicle. I like to think of myself as an enlightened male of the modern age, but there is a significant sexist bias in my thought that I need to work on. Moreover, I think this bias pervades our culture so much that we're shortchanging ourselves. Having worked with a number of rockstar quality technologists who happened to be female, I wonder how many there might be that are shying away for whatever reason. Having to constantly find new talent and knowing how difficult it is to find quality technologists, I lament the fact that we seem to be underutilizing 50% of the potential talent. Being the father of two daughters transitioning into adulthood, now more than ever I'm going to challenge myself personally to make sure I keep any unconscious bias at bay. Please do the same...