… the boy who cried wolf, the emperor’s new clothes, or the honest woodman - what do all of these have in common? They all deal with the axiom of honesty, perception, and misdirection.

When thinking about the business side of software I tend to think about the lions without teeth; the things that are claimed as the highest importance from the loudest people.

So as developers how do we distill the true signal in all of the noise? How do we separate the lions with teeth who we should be paying attention to from the ones without the teeth that we should be able to ignore? Have a point. In a scrum shop, this is generally set by the product owner, but we as devs are responsible for helping our groups stick to it when the pressure rises.

Impossible you say? You’re thinking, “there is no way we could all stand behind one point, the business would implode.” Really? So does that mean personal budgets don’t work, or that companies like 37signals really don’t function?

When lions bite they will do everything not to let go, because they are hungry. They know that letting go = empty belly or in the business mind => my group’s priority = my passion; those are the real lions.

What about the others? That’s where histrionics enters into the equation; where deception takes over and reality steps out. Their business mind => my priority = my passion. Stay clear of them, don’t have anything to do with them - they tend to distort, disillusion, and distract from the “goal.”

run with this: get a point for what you’re doing, write it down where it’s in your face, get behind it, do it, stay away from anyone who want’s to usurp it.

I recently found out I am going to have a little girl. Given the back drop that my four other children are boys, that I was raised with more brothers than sisters and my chosen carrier is dev let’s just say I have trouble “expressing” emotions.

Emotions are for socially accepted people, a notion that many developers seem to struggle with - being socially acceptable, that is. So in any given dev team how do you deal with introverts and the socially challenged, when you as a leader should be, well leading (whatever that actually means to the people you’re leading).

You start by connecting on an emotional level. Try by asking what do they love about their job and what do they hate. If they give you service level answers at first start off by “actually” being real with them and tell them about your love/hate relationship with your job.

The take away: You’ll probably lean something you didn’t know; something you’ll actually be able to do something about.

Would you ever think a hand grenade thrown wouldn’t break, damage or destroy something? I think in software we tend to fight with grenades, blasting our way through things we don’t like.

Have you ever watched a war movie where the troops roll in and they start lobbing grenades, firing rockets, shooting first then asking questions and at the end of it all you see a “relief effort” swoop in and rebuild? No. After the dust has settled all you see is a bunch of broken stuff.

I feel like that matches the pattern of some of our dev-mentality. We go in with the intent of saving the village and all we do is cause a considerable amount of collateral damage then bail assuming there will be some sort of relief effort (QA perhaps).

Why do we sometime fight with hand grenades instead of knives; more like the tank and less like the ninja? It might be the glory of the battle or the sweet taste of victory (at least as far as the fight goes ); who really knows?

All software needs some degree of refactoring and sometimes huge reworks are a sound way to rid yourself of a looming / annoying problem area - but try to start by using a knife not a grenade / iteration not search and replace.

The idea… solving problems should be iterative not mass-blasting with collateral results.

I see this sign on the way to work every day and think: “really!? If the builders of the intersection know it’s dangerous why don’t they change it?” I imagine the response would be something like: ”It’s too expensive” or “you can’t just change a road…”

We deal with “scary” legacy code all the time. The fact is if it was produced by you or someone else that doesn’t matter; it’s that it’s there.

More often than not we generally try to stay away from the code claiming that it is toxic or that by touching we would cause unforeseen consequences - claiming “you can’t just change a road.” When, in reality, it’s just code; bits cast on the grid.

Knowing that there are dangerous intersections, why don’t we as devs do something about it, change it, rework it. We have a choice: we can continue to avoid those bits or choose to make them better.

Take this up as a challenge: count in a given day, week or month how many times you or someone else groans about a section of code, functionality, etc… that has been complained about before. Not that you’ll be surprised by the result but you may realized how complacent you and other devs have become about dangerous code you’re allowing your users to use.

Drop FUD as a tool and pick up something useful in it’s place (such as unit / integration tests or parallel deprecation).

I’ve been wondering… what it would look like if I could close my eyes and pull my physical application platform out of a 2D doc and make it 3D.

What if you could take a game like minecraft and build something like “appcraft” where you could visibly see where the weak points in your architecture are and what hardware / software relationships make up your app.

I’m not talking about some over blown UML but an almost touchable model of your software that you could actually walk through. Why would it be so odd to actually make a game of it as well others could attack your virtual stack and see if they could break it.

What would be wrong with “gaming the system” and doing software modeling inside of minecraft?

{end-of-line}

I was reading the other day when I was visited by a caterpillar. He was probably the size of a 0.7mm pencil lead. Immediately distracted, I was taken away from reading and drawn to his movements.

A caterpillar is made of of a series of segments and devices each with the sole purpose of processing food. I got tuned into that sole focus as he moved across my arm. A few moves then up to have a look around for food, a few moves then up looking for food again and so on…

(This is where I am not going to draw a parallel to a caterpillars focus and some software or language idiom. )

Here is what I saw…

When the caterpillar approached something natural, such as my arm, a leaf, some grass - it move like silk, without interruption. When it approached something unnatural, such as my watch, it struggled with navigation and movement.

Much like the software we write and design we loose traction when something ”unnatural” enters our systems. Being cautious of aberrant things being introduced into our ecosystem is a fundamental desire of an architect. Without this awareness our systems begin to slow and stop functioning.

Consider the caterpillar - if you run into something that slows you or your system remove / re-factor.

{end-of-line}

I’ve dealt with many communication failures in the places where I have worked. It seems that the talking really isn’t the problem or that TO:, CC: and BCC: really don’t play a role in the outcome of the purpose of the communication.

It comes down to ownership. Who owns the thing that you’re communicating about, are they informed and is that ownership respected. Often times people become impatient, want to “help,” want to get credit for or just want to do it their way. Which, in turn, massively distills the effectiveness of communication. If I am the solutions architect, for instance, and there is a fundamental change to “architecture” then I had better be involved and own up to the outcome.

I’m not talking about the RACI mess, to me that’s a lot of work and works just to say I’ve got it. Most things can be absolutely inferred as to who owns them. I’m not talking about the ambiguous lines like an organizational decision such as making core hours for the teams; more like the decision to change systems or software patterns.

Consider how these things pan out in life…

I own the budget in my household because i am better at numbers and cash; no “formal” decision was ever made to make me the budget czar. If you “own” something, make sure you do just that. Otherwise there will be a lot more mud in your waters that you need to inherit.

{end of line}

I recently saw something seemingly ridiculous: someone holding a coffee cup with the handle out. Initially I thought how could he go against the very fabric of social coffee drinkers but then I thought… “who knew?” The guy who built the handled cup obviously created it to be used a “certain” way. Reflecting on software, we build our apps with opinions - rightfully so, you should have opinions built in otherwise developers are forced to roll big ball of mud just to support business requirements. So if you look at the software you create as a coffee cup:

• Your app: using the handle
• The API to your app: breaking the handle off, Burger King style

{get to know more about that strapping young coffee cup crusader =>}

Build for what is, not what if. We are not building buildings (the seeming immutable and hard to change), we’re building software.

It seems to me that more often than not we end up having technical debt; not because of crappy code or inattention to detail (though those do contribute) but because we spend too much time on the fringe. Have you ever known a successful golfer that spent an obsessive amount of time “figuring out” the fringe - no, they pay attention to the fairway, the green, and the traps to avoid - not “how do I play the fringe?”

As ridiculous as it may seem architects spend an inordinate amount of time talking about the “what if,” instead of doing the “what is.” We get hung up on some random business requirement and tout that the solution will fail every time because that requirement cannot be met.

Rather than building roadblocks, we seek to improve our ecosystems through refactoring and iteration - peeling away technical debt, right? So why should new functionality be any different? Instead of eating the elephant by running at it with your mouth open, brake it up, deliver reality, check out the results, then re-factor or add to it.

Rinse and repeat. It’s not difficult, but it can be perceived as boring or mundane. To that perception I say pfffft! I seek opportunities where people tell me “it can’t” or “it won’t.” Really!? I don’t buy it. If you’re sticking to a real need based on real things then why can’t it be better than it was before, and why can’t achieving that be exciting.

If you’re thinking leave refactoring for someone else to do, I’ve got future stuff to do, architect guy stuff - stop right there and get real with yourself:

When was the last time you blueprinted something that: 1. Made it to prod, into the customers hands, 2. Never had to be re-factored

Much of what we do is make mistakes, not always but some times more often than not - so why not approach the problem with that in mind; making the static “x” really good. Then go stomp around the what if (variable “y”) and if something shakes out then at least you have something solid to try it against.

I’m definitely not suggesting we ignore the “what if,” just don’t use it as a crutch to stop you from doing the “what is.”

{end-of-line}

Being an architect does not mean being separated from the team. Ivory tower architects should be left in fantasy movies and books keeping common company with trolls. It doesn’t work. Not at all. To think that a person who is responsible for the entire ecosystem of applications in a given platform would not sit with, code with, win and fail with the team is to not think at all.

Do you know what code just got checked in? Did you know that the quiet dev in the corner just slammed out an awesome bit of code that could change the face of your platform? Did you challenge anyone today; did they challenge you? Did you know if you asked the team their opinion on a blueprint you created it could’ve saved the company millions? Did you know that many devs don’t understand why they should be test first developing? Know your team, and use them as an instrument of architecture.

Spending time connecting and coding with your team is what makes really great apps. Leave the magic bag of architecture terms, methodologies, notions, assumptions, and pride in the fairy tail - build, plan, and do.

{end-of-line}