Atlanta Code Camp 2014 Slides

Thanks, everyone for attending my session today. We had a great discussion, and I hope you found it helpful.

Here are the slides.

Advertisements

I thought I was wrong once, but I was mistaken.

When’s the last time you admitted to being wrong? That’s the last time you learned something. And it was probably an important lesson.

Much of what we stuff into our memories throughout our life is assumption. Other stuff applies at one time, but likely doesn’t apply now. Insisting we “know” something is usually just clinging to our assumptions. And as my father told me: you know what happens when you assume, right? Other times, insisting we are right is also pretty much acting like the world stopped turning when we learned that one thing. Oh sure, the universe ceased to change at just the moment you became aware of this fact you’re clinging to.

Sure, you learn new techniques, new recipes, new routes to work all the time. But what I am referring to here is a real change of perspective, something that actually makes you better, and lets you do something you didn’t know you could do. By trying to avoid being wrong, we are denying ourselves an opportunity to learn, to be informed, to grow.

Do you ever wonder why it’s so much easier for kids to learn new things than for adults? What if the reason is that adults just think they know everything, whereas small children don’t have an ego or an image to defend by being “right?” Kids know they don’t know – they know they are wrong, and they are OK with it because when they learn the new thing, they will be better off.

I think we are afraid of being wrong for a variety of reasons. First, we get negative feedback for that in many cases: work, school. Being wrong is treated as a failure, so we eventually see it that way. Second, there’s cognitive dissonance when an idea we cling to is challenged. Cognitive dissonance is painful, and we feel better when there is only one idea in our minds, instead of two conflicting ideas. Unfortunately, it’s easier to reconcile our minds by letting what we already “knew” win out, rather than inspecting and changing our minds.

So look for an opportunity to say “I was wrong.” When someone challenges your understanding of something, learn something and you might find that you were, in fact, wrong. But you won’t be wrong anymore, now will you? And you don’t even have to admit to being wrong, in so many words. Instead, you can say “today, I learned…”

So tell me: am I wrong? If so, how? I want to learn from this.

“If You Don’t Transform, You’re Stuck”

How have you transformed to adapt to the changing world?

I had the fortune of hearing Xerox CEO Ursula Burns in an NPR interview this morning: “If You Don’t Transform, You’re Stuck.” Burns saved Xerox from failure and irrelevance by transforming the company. Not only is Xerox surviving, it’s thriving.

Xerox is an example of what applies to every company, ever: “what got you here won’t get you there.” That is to say, the things that brought you (and your company) success until now are not the things that will bring you success in the future. In the case of Xerox, it was paper; now it’s digital logistics services.

What made you successful in the past? Don’t assume that will continue to do so. In fact, I challenge you to question whether it will.

The lesson here is to not rest on the laurels of your success. The momentum that propelled you last year can become an albatross.

Transformation isn’t a one-time thing: you have to keep adapting. How are you transforming now to adapt to the changing world?

Google+ and fear of failure

Aside

I’ve only spent 5 minutes with it, so I can’t speak to how strong of a social networking offering Google+ is. But I can say: what impresses me most is that Google is publicly proving that they are not afraid of failure.

How many attempts has “the Goog” made at social networking? Wave, Buzz and Orkut, at least. And those are the ones that were released publicly. Google Wave came and went pretty recently; they didn’t wait to try again. You also can clearly see where the the lessons and successes that came out of these failed attempts.

Don’t be afraid to try and fail.

You can’t spend your way out of technical debt

cutting loose

There is an axiom of personal finance that states “You cannot spend your way out of debt.”  While seemingly trite at first, it holds a truth that becomes apparent in nuance.  It becomes a mantra for those seeking a quick-fix to major financial problems: there is a more fundamental axiom stating “You didn’t get into debt overnight; nor will you get out of it overnight.”  Germane to these concepts is the idea that a behavior change is needed to go from in-debt to debt-free.

There is this old component – let’s say it’s a charting component.  Tied to this charting component is a significant amout of technical debt.  Adding new features is expensive, and there are some bugs.  After some exploration, the team has decided they must code a replacement –  in parallel and without the debt, this time.

Once they begin working on the replacement, they hit an interesting snag: the old charting tool did a lot of stuff.  Bar graphs, pie charts, smiley faces.  They use it all over the application for many, many things.  It’s stated as a requirement that the replacement must – from the start – look, feel and behave like the the old one… just without the bugs (and debt, presumably).  Now it looks like the replacement is going to be incredibly costly – perhaps prohibitively so.  This isn’t a solid way out of technical debt.

This is where it gets tough: the behavior change.  The same old requirements/delivery patterns that got you into debt won’t get you out of it.  It’s the opportunity cost of paying off technical debt: you can’t buy functionality with the velocity you use to pay off debt.  You have to realize that those things we ‘got for free’ in the past weren’t really free, after all.  There’s no such thing as a free feature.

One thing you could do instead is ‘downshift’ to incremental development: you get the highest-priority, core-value functionality ready to ship, then you iterate.  This is agile 101.  Each iteration gives you an opportunity to re-evaluate what you want this thing to do.  Perhaps you don’t want the same old stuff as before.  Maybe you get some innovation out of your technical debt pay-down.

The behavior change comes in forgetting what you already had, and build it right this time by managing the process correctly.  You wouldn’t design it all up-front, then deliver a monolith of a feature in a green-field situation, don’t do it here, either.