Malcolm's Musings @malnewsome - Tumblr Blog

Pairing Tour - Day 10: Touching Base

As a reminder, the final two weeks of the graduation process involves completing two challenges and preparing a talk. We are not informed of what the challenges are until after the pairing tour is over. So, I felt like a kid on Christmas morning as I was heading into the office today—excited to unwrap the gift of these challenges and see what shiny new problems lie beneath. I walked into the office—excited—and prepared to get started on my challenges.

But, that’s not how it happened.

I approached my mentor to tell him I was ready for my challenges. Then, with his familiar “I have a surprise for you” grin, he informed me that I still had a day of pairing left and that I would get my challenges at the end of the day! Aye aye aye!

So, we paired together again.

Of course pairing with Dave is always an enlightening experience. So, I was glad to have another chance to pair with him again before my apprenticeship comes to an end.

We spent the morning digging into a couple of problems that creeped up for one of our clients. What made this different is that Dave was doing this for a fellow Craftsman that is off on vacation. Soon, we found ourselves doing quite a bit of yak shaving. We were searching through and learning new things about the system, but still felt like we weren’t really getting anywhere. Here, I learned how Dave handles these types of situations— and I liked it a lot. Basically, at one point we got so deep down a path that we had to take a step back and discuss where we were going to focus our efforts. It sounds so simple. But, it’s something that I’ve never really made myself do. Then, he went a bit further and explained that this would be one of the most important skills for me when I start client work. I will certainly find myself looking at code and needing to trace my way through it. So, this will be immensely valuable.

At the end of the morning, we still had not discovered the cause of the bug that we were trying to hunt down. It was at this point that I realized one of the reasons why Dave is so awesome at managing client projects. He took it upon himself to email the client and to inform them that he did some looking around for one of our colleagues and gave a short report of our findings. No one asked Dave to email the client. Yet, he did anyway. Then, he shared his simple philosophy for touching base with clients:

Don’t worry as much about missed deadlines. Worry more about missed expectations.

Boom!

In the software industry, sometimes deadlines will be missed. It’s an unfortunate reality. But, often missing those deadlines aren’t as bad when the customer knows well in advance that there’s a likelihood that the deadline will be missed. Expectations are founded upon open, honest communication—or the lack thereof. When open, honest communication occurs frequently, the client will know what to expect based on what’s communicated. Conversely, when open, honest communication doesn’t occur, the client’s expectations will be based on any previous commitment. If that commitment is broken, disappointment is inevitable.

So, it all boils down to something very simple. By touching base regularly—and by being open and honest when you do—you can avoid grave disappointment.

Then life will be sweet.

PS:

The titles of my blog posts from Pairing Tour 6 onward can be formed into a acronym. Send me a tweet @malcolm_newsome if you know what it is.

#Pairing Tour

Pairing Tour - Day 9: Fearless

The transition from apprentice to Craftsman can seem quite daunting. Why? Because, it is akin to stepping outside of the inner sanctum and into the real world. In the real world there is a different level of pressure that is on. In the real world, the mistakes matter. In the real world, the stakes are higher.

This breeds fear.

Well, that is, for some it does. Not for Phil.

Phil is amongst one of the most recent 8th Lighters to graduate his apprenticeship and become a Craftsman. However, you wouldn’t be able to tell if I hadn’t told you. I think this is largely because Phil did not display any signs of fear when I paired with him today.

As the day began, Phil explained that the first task of the day would be to QA a story that another member of the team had completed. At this particular client site, the devs take on the role of QA within the team instead of sending completed work off to a designated QA team.

As we read through the description of the story and acceptance criteria, Phil quickly realized that he wasn’t sure of how he would would go about verifying that the code did, in fact, meet the acceptance criteria. Since, Phil is a new addition at this particular site, and the system is massive, he wasted no time getting another member of the team involved. When the other team member began explaining, Phil was very clear about what he understood—as well as what he didn’t understand. It’s the being clear about what one doesn’t understand that makes all the difference.

He could have easily nodded and said “Ok, sounds good,” and went back to his computer and continued to struggle. But, instead, he was upfront and transparent about what he didn’t understand. Thus, he was able to get the help he needed right away.

As it turns out, even one of the most senior members of the team was at a loss for quite a while. So, something that we thought would be fairly quick ended up taking us most of the day to complete.

Fearlessness is a critical trait for a craftsman. We owe it to our clients and each other to be open and transparent with them at all times. In fact, it is one of 8th Light’s guiding principles.

So, when all is said and done, I got to witness one of our newest Craftsmen holding true to the 8th Light values and vision. That will be me in a couple of weeks. And, I cant’t think of a better way to have concluded my pairing tour.

#Pairing Tour

Pairing Tour - Day 8: Abundance in the Small Things

In a perfect world, all of the code that’s ever written will be clean and easily maintainable. The code would be easy to set up and easy to execute, especially for someone who has no frame of reference for what the application will do.

But, we don’t live in a perfect world.

I paired with Mike Ebert today. It was an eye opening experience, and one that I know I’ll continue to appreciate as time goes on.

As apprentices, we are taught much about how to write clean code. It is, in essence, one of the main things that will set us apart as we become Craftsmen. But, what happens when you find yourself in the middle of a massive codebase that is not treated with the same love and care that the model craftsman would give it? How should…and would…you respond?

Well, I can tell you that I was pretty pleased with how Mike responded today.

Today we started on a new story—one that would end up leading us down an interesting path. The story required us to integrate two applications. Mike has a great familiarity with one of the applications, since he’s been working with it for quite some time now. But, the application that we had to integrate with was one that hasn’t been touched in three years. On top of that, the code in that application was not unit tested nor was it well documented. Oh, I should also add that there was no one with an intimate understanding of it—nor an understanding of how we could even set it up. As a result, we spent the better half of the day trying to figure out why we kept getting errors when trying to do simple operations—and, the setup wasn’t even complete by the end of the day.

The code was chalked full of seemingly meaningless comments. i just wanted to delete them all. Mike practiced restraint—and he did so with good reason. He made the very wise point that he’s careful about making changes like that because he wants to ensure that the changes he makes are aligned with the stories that he works on. This way he’s certain that he’s not negatively impacting something that he’s not familiar with.

When all was said and done, the thing that I liked the most about how Mike handled the nasty code situation was that he was a true professional. There were several times that he asked questions of the staff only to get redirected to someone else. Instead of whining and complaining, he simply extracted the knowledge he needed from those conversations and then made small changes to the application each time he learned something new. I realized later that he was creating a trail of improvements that would allow someone to have a much easier time than he did.

That is the mark of a Craftsman.

What makes it even better is that I’m not even sure he fully realized that he was having as big an impact as he was. I say this because he was trying to figure out how he could have a greater impact for the client. He demonstrated a disciplined adherence to his discipline—and he did it subconsciously. That’s just awesome.

The reality is that I’m certain that I will find myself in situations like this again. I know that the code that I encounter won’t always be pristine and easy to navigate. This day will help me to keep in mind that there’s abundance in the small things. There will be opportunities to do the big, grand things. But, until those opportunities present themselves, it’s critical that I remain disciplined and principled every step of the way.

Then, I too, will be making my mark as a Craftsman.

#Pairing Tour

Pairing Tour - Day 7: Reinventing the Wheel

What happens when you pair with someone who’s a bona fide genius? You learn how to construct your own programming language, of course!

That’s right, I said it! And, I’ll say it again…You learn how to construct your very own programming language.

The day started off like many others:

—> Arrive in the morning.

—> Go over the stories and tasks for the day.

—> Work on said stories and tasks.

—> Break for lunch.

—> Continue working on stories and tasks until they are complete.

If I stopped there, I would have considered it a pretty typical day. Fortunately, programming is awesome and—the people I work with are even better—so, that means typical days are awesome, too.

But it wasn’t…It was better than that.

While working with Mark today, we were able to complete the work that we had set out to do. Then, we hit a point, towards the end of the day, where we were in a bit of a holding pattern while waiting for some additional information from the client. We also didn’t really have anything new to start. So, we tossed around some ideas of what we could build. The first idea that stuck was building a console version of the new, popular game, 2048. Mark likes Haskell, and I’ve never used Haskell, so that’s what we decided to write it in.

A few minutes into it, Mark stopped, looked at me, and asked “Would you rather create a programming language instead?”

“Yup! You’d better believe I would!”

I’ve often wondered how programming languages were constructed and what transpired next gave me a remarkable understanding for what’s involved. Additionally, Haskell proved to be a really nice choice. Using this language, we were able to pretty easily define the types that we wanted to include ( we chose Numbers, Variables, Functions, and Lists).

Once we had that set, we moved on to writing out how those types would be evaluated once they were run in the REPL. This required us to write an eval for those types. At this point, you might recall that I just wrote about REPLs and eval. As it turns out, I’d just learned about them from my awesome mentor this past Friday. Timing couldn’t have been any better! That knowledge really came in handy today.

Finally, we had to define an environment. This was needed in order to specify the operations that could occur when the code was evaluated. This is an important step because it ensures that the types will only do and return what you have specified. Surprises aren’t a good thing when it comes to programming languages (Sorry Ruby).

Obviously, this is a very simplified overview of how it went. But, suffice it to say that I was grinning from ear to ear when I left the office.

People often say not to reinvent the wheel. In this case, though, I found it to be pretty awesome.

This pairing tour is turning out to be a super awesome thing! I'm eager to discover what will happen on my next, and final, two days.

#Pairing Tour

Pairing Tour - Day 6: The Currency Cycle

It’s interesting how you never know how things that you learn in the past will come in handy at some point later in your life. Such was the case with me today when I paired with Ben Trevor.

We have a client that deals with processing a lot of financial transactions. It just so happens that, after college, I spent several years as a bank manager and a small business commercial lender. So, in a way, I felt a little at home today.

This particular client has a very, very large system. Indeed, I was particularly impressed with Ben’s ability to navigate it extremely well. Because if this, he was able to cover a lot of ground with regards to showing me how various pieces of the application fit together. Combined with his explanation of the system and my previous banking experience, I found that I was able to fairly quickly understand the context in which we were working.

But, a key moment occurred at lunchtime. While we were sitting and talking, I asked Ben for his thoughts on how I could continually add value for the remainder of the day. To this, he replied:

Keep asking questions.

He went on to further explain that being asked good questions helps him to solidify his knowledge more. And, if the question was one that he couldn’t answer, he’d be able to learn more as well. I thought that this was utterly profound and made perfect sense!

Then it occurred to me…questions are their own form of currency. Without them we can go without the immensely valuable knowledge and wisdom that they bring…both to the asker as well as the responder.

So, I am officially dubbing this the Currency Cycle.

The questions that we ask today will provide the wisdom that we need to continue on. And, in so doing, that knowledge will come in handy at some point in the future. As long as we keep asking questions—and learning—the cycle will continue.

In the end, we’ll be glad for asking the questions that we did…and everyone will be much better off for it.

#Pairing Tour

Pairing Tour - Day 5: Teach on, Teacher!

Today I got to pair with my mentor, Dave. Since he’s my mentor, we’ve had several opportunities to pair before. But, as I draw closer to becoming a Craftsman, I thought a lot today about one of the qualities that makes him such a great mentor…and Craftsman:

His remarkable ability to teach.

I’m hard pressed to remember a moment in which Dave didn’t respond with “Let’s grab a whiteboard” in response to an inquiry for help when I needed to understand something. Today was no exception.

At one point, we came across some code that I didn’t quite understand. I didn’t understand it largely because the code was creating a macro. I mentioned that I was not really aware of what macros do. Without hesitation, he got up, said his trademark phrase, grabbed a whiteboard, and enlightened me.

He started with describing what a REPL is and what it does. I know that clojure makes use of a REPL, but I never gave any thought to what REPL might stand for. Well, here it is:

Read - Takes and expression from the user, creates a data structure from that input, and then stores it in memory.

Eval - Evaluates the data structure.

Print - Displays the result of the evaluation to the user.

Loop

You may be wondering…”Why is this important to understanding macros?”

Well, because a macro is evaluated during the Read stage instead of the Eval stage. This is a very important distinction…and one that makes macros really powerful.

To explain, in clojure, we can write a function like this to add two numbers:

(+ 1 1)

Functions are evaluated in the Eval stage. When called, each element in the function is read in and then evaluated. Then, as you’d expect, the output would be “2”.

Well, suppose we wrote a macro called, add-ten that took a math function as an argument:

The macro could look something like this:

Line 4 demonstrates how the macro would be called in the REPL. Then, when we called the macro, the function itself would not be evaluated. Instead, the macro would return a list and then evaluate the list with the + function. In this example, we’d end up with 12.

Obviously, this is a trivial example. The real power of macros lies in their ability to manipulate data structures so that you can create new ones for your program as you see fit to do so.

So, here again, my mentor was, once again, able to help me understand something rather complex in a matter of minutes. It’s a remarkable gift….and one that has made all the difference in my apprenticeship.

#Pairing Tour

Pairing Tour - Day 4: What is “normal” anyway?

Today, my pairing tour took a bit of a twist. The person that I was scheduled to pair with needed to head out of town for some meetings and, therefore, was unavailable. In his stead, I was given the task of adding a feature to my mentor’s open source project, Easy Bake Service.

Easy Bake Service is a library, written in clojure, that aims to do the following:

normalize inputs & outputs (xml & json) - middleware

document endpoints - lein task

validate inputs - middleware

generate a client - lein task

generate a skeleton service - lein task

My task for the day was to make sure that XML was getting normalized.

If you’ve been following my pairing tour, you’ll recall that I don’t really know clojure. So, up front, I knew that today would be a challenge. But, one thing I’ve come to realize over the past several months is that I’m never alone here.

I recently began reading The Clean Coder: A Code of Conduct for Professional Programmers, by Robert C. Martin. On page 73, he has a section entitled Help. Here is a snippet from that section:

Programming is so hard, in fact, that it is beyond the capability of one person to do it well. No matter how killed you are, you will certainly benefit from another programmers’s thoughts and ideas…Because of this, it is the responsibility of programmers to be available to help each other. It is a violation of professional ethics to sequester yourself in a cubicle or office and refuse the queries of others. Your work is not so important that you cannot lend some of your time to help others. Indeed, as a professional you are honor bound to offer that help whenever it is needed.

I’ll put it plainly. I needed a lot of help today. I feel like I was getting stuck over and over again. So, what happened? Did I get that help? You bet I did! A fellow apprentice, Zach Olauson, made himself available to help me for much of the day. In fact, he even moved from where he normally sits and came to sit next to me…without me even asking him to. He just did it out of the kindness of his heart.

If that isn’t awesome enough, you need to know that all of the apprentices routinely behave in this fashion. There have been countless occasions where apprentices have given up significant portions of their time to help me or someone else who’s been stuck. Indeed, as I look around, this attitude and responsiveness is engrained in the culture…all the way up to the CEO.

So, this goes out to all of the apprentices that I’ve had the pleasure of working together with day in and day out. They are setting the bar high with regards to the professionalism that they are already demonstrating. They are a HUGE part of why our normal == AWESOME.

You'd benefit greatly from checking out the current apprentices to just how awesome they are:

Meagan Waller

Taryn Sauer

Tom Kowal

Nelsol Batalla

Elizabeth Engelman

Zachary Davy

Zach Olauson

LaToya Allen

Alex Hill

Kyle Sparks

To each of you, I want to thank you for helping to make my experience as an apprentice so rich and fulfilling.

This is how we define normal at 8th Light.

#Pairing Tour

Pairing Tour - Day 3: BUSTED!!

Today, I paired with Doug—one of 8th Light’s first Craftsmen….on Clojure…again…and iOS…for the first time ever.

First, though, I must mention that Doug is a great guy. In fact, he’s so great that he did this for me partway through the morning:

Yikes! BUSTED!!

He noticed pretty much right away that my typing skills are…well, not really skills yet. So, he challenged me by putting this lovely canary post-it over my arrow keys so that I wouldn’t cheat and use them for the rest of the day. As a craftsman, being able to type well matters. I had already realized this, but I appreciated his simple explanation. He simply said, “You don’t have to be the fastest typer, but you don’t want your typing to be a hinderance either.” Since I started here, I’ve been so concerned about being a fast typer. But, my focus should be more on being an efficient typer.

Polyglots “R” Us

In case you want a definition, a polyglot is defined as a person who knows and is able to use several languages.

When my apprenticeship first began, my mentor provided me with a list of expectations. One of the items on that list: Polyglot. This is one of the things that excited me the most about becoming a Craftsman at 8th Light — and I definitely got a taste of that today.

During the morning, we worked on a project that involved updating an API for an application. That application is written in Clojure--so it was nice to get some additional exposure and experience using it. When Doug first slid the keyboard over to me in order for me to to write some code, I realized that I wasn’t as nervous as I initially thought I’d be. This was a cool realization because I noticed that my comfort level with Clojure is growing. I must point out, however, that the application is very well written and that he did a great job of verbally communicating his understanding of what was happening in the code. Because of these things, I found that it was pretty easy to follow along with what was going on.

We were able to finish up the changes to the API in the morning, and this meant that we were able to move on to exploring how to consume that API in the project's iOS app. This was the first time I’ve looked at any Objective-C code, nevertheless, I was pretty excited and, again, realized that I wasn’t nervous to jump into it. We spent some time exploring the codebase and, by the end of the day, had developed some comfort with how things were working and began to add in the View that we would need.

All in all, my biggest takeaway from today is that I feel like I have definitely reached a point where I’m confident in the foundation that I now have when it comes to investigating and writing code. Of course this doesn’t mean that I feel like I know it all. But, what it does signify is that I’m no longer afraid to dive into a situation that is foreign to me.

So, not only did I get busted for using the arrow keys too much, but I also busted through a previous fear.

...and, that’s pretty awesome.

Oh, and by the way, I’ll be keeping the post-it as a memento.

#Pairing Tour

Pairing Tour - Day 2: Surprise!

Yup, the title says it all. Today turned out to be a bit of a surprise for me.

I went into today knowing that I’d be pairing with Andrew Kelly. I also went in to today knowing that I’d have the opportunity to work with C#, a language that I have a good deal of comfort with since that was one the of the languages that I used primarily at my last job. What I didn’t know is that I’d be wrong.

When I arrived and went over the plan for the day with Andrew, I learned right away that he’d switched to a new project yesterday. So, this meant that we would be using a language that is still pretty foreign to me: Clojure.

Clojure is a departure from the object oriented land that I’ve been living in since I began programming—it is a functional language. As such, the way you have to go about solving problems using a functional paradigm is often times quite different from how you would approach them when using an object oriented paradigm.

So, this got me thinking…

How do I contribute when I have no ability to code in the language that’s being used?

When I got to the end of the day, I realized that there were a couple things that helped me answer this.

1. Get an understanding of the context that you will need in order to make decisions.

I am extremely fortunate that Andrew took some time out at the start of the day to explain the application to me and make sure I had a solid understanding of the application as a whole. He was thorough where he needed to be and and very descriptive overall. I realized later that he had done such a great job explaining when I was able to confidently describe the high level functionality and purpose of the application to another apprentice at lunch. This made all of the difference in my day because it helped to put me at ease right away. Once I understood what the application was doing and what we needed to do, my focus shifted. I became less concerned with how to use the language and more concerned with the process by which we would solve the problem at hand.

2. Be willing to ask for help sooner rather than later.

As it turns out, Andrew hadn’t used Clojure in quite a while either. So, we decided early on that we would not beat our heads against a wall all day. This was as valuable lesson that Andrew learned when he was a new Craftsman and made sure to pass it on to me as important advice. This was really good for me to see because I have often made the mistake of waiting longer than I should have before asking a question. But, the sooner you get the help you need, the sooner you free yourself up to move on to the next step. In addition, he pointed out that’s it’s always important to remember that the client is paying us for the time we spend working on their applications—and it is irresponsible in order to waste their time and money because of fear of speaking up and asking a question.

3. Remember that you have previous knowledge and skills that can be of value.

There are skills and knowledge that we carry with us even though the problem at hand may be a little foreign on the surface. Our main task for the day was to figure out how to create a .csv, populate it with data, and then email it as an attachment. Even though I didn’t really know the language, there was some comfort in the fact that we were working on a problem that I’d experienced before. So, at various times during the day, I was still able to help out by finding information that we could potentially use—or, I was also able to contribute to ongoing conversation throughout the day and ask pertinent questions while we were working. This was all due to the fact that I had some idea of what to expect in the end.

Keeping these in mind, I should be ready for future surprises. And, I have a hunch that there will be some…

#Pairing Tour

Pairing Tour - Day 1: Delivering Happiness

The Pairing Tour Explained

8th Light’s Software Apprenticeship concludes with a 4 week process that leads up to a final review in front of a board that is comprised of at least 8 Craftsmen. The first two weeks is known as the pairing tour. During the pairing tour, I will be pair programming with a different member of my review board each day. So, I’ll be writing each day about my experience on my pairing tour.

Day 1

Today I paired with Rick. It was really nice to have this opportunity because I haven’t previously had much time to get to know him since I have only really seen him on Fridays. It was an enlightening experience both technically as well as non-technically. Allow me to explain.

Rick, is a really great Craftsman. This is not only evident in his ability to code, but also in his ability to reason about his judgement and then distill that knowledge and present it in a simple, humble and profound way. Among some of the things he showed me were how he’d implemented the Command Pattern in several places and how he and the team there was going to go about resolving a cyclic dependency that existed. Additionally, we had a nice discussion about how the State pattern would come into play based on the problem that they currently need to solve. Due to the timing of my visit, there wasn’t much work on new features, but we did get chance to go through the codebase in pursuit of squashing some bugs. Doing that, we were able to complete a few stories.

If that doesn’t sound awesome enough, I learned first-hand what is at the core of Rick’s success as a Craftsman: the degree to which he has built a tremendously solid relationship with the client.

While he and I were at lunch, the Director of Technology asked to join us. This led to a very interesting, and eye-opening discussion where I got to hear first-hand from one of our clients what he thinks that a software craftsman should be able to do. This is obviously critical because our company can only continue to grow and thrive based on the value—both real and perceived—that we bring our clients as consultants. And, as a Craftsman, I need to be consistently dialed in to how I am creating value for the clients that I serve.

Among the things that the client said were important to him are:

A true, intimate understanding of the SOLID principles and how to reason about them.

A commitment to continual growth and enhancing the craft of writing software—especially outside of what is learned at the workplace.

A passion for software and technology.

An ability to deliver features on time consistently.

Then, he said something that really resonated with all of us…in a way that perhaps he hadn’t thought of before. He said,

“If a craftsman can be these things and deliver, I’ll be happy when I go home at night. A craftsman can deliver happiness. I want a craftsman that can deliver happiness.”

This is a pretty awesome thought.

As a Craftsman, I have the ability to affect many lives. I will have a direct impact on the lives of those that I work with and do work for. But, not only that. I will also have a an indirect impact on the customers that my clients serve. As a Craftsman, I will be in a unique position to deliver happiness…and that makes me smile.

#Pairing Tour

When you speak publicly...

You may recall my blog post on Deleting Everything and Starting Over. Well, I gave a Smalltalk at 8th Light on that very topic a couple weeks ago. After that talk, Dave, my mentor told me to contact some developer groups that were not affiliated with 8th Light and propose to give my talk there.

The first group I contacted was ChiPy (the Chicago Python User Group). Fortunately, they were willing and able to let me present--and tonight was the night.

I won’t go into a lot of specifics on the talk because a lot of the content is similar to what I wrote in my blog. Instead, I want to focus on another important aspect…

First off, you should know that ChiPy was the first developer group that I attended when I began learning to code about three years ago. In fact, for a while, it was the only group that I attended with any consistency. This is important to mention because my earliest memories of the group have to do with me sitting in the audience and listening to speakers present on topics that were pretty foreign to me. I’d intentionally subjected myself to this because I knew that it was going to be critical for me to learn things that I wouldn’t have otherwise been exposed to. Even better was the fact that there were always people there that were willing to answer my questions and help me along when needed.

So, tonight I found myself at the front of the room of this same group. Then, afterwards, it occurred to me: I gave my first public technical talk at the group that gave its first technical talk to me.

To add to my exciting revelation, after speaking I was approached by a couple of newer developers. They remarked at how much they enjoyed the talk and how much it helped them. One had even lost a job and was recently hired into his first developer role. So, he was actually dealing with the “stating over” aspect in a similar way that I had nearly two years ago when I was hired into my first developer role. It’s pretty awesome to think that the story I shared could be of value to someone else who finds that they are in a similar situation that what I was in.

The other gentleman expressed how excited he was to hear about software craftsmanship and how he would be striving for that from now on. A hallmark trait of software craftsmen is that they don’t hoard knowledge…and now I can clearly see why. The more we have people who are dedicated to being craftsmen, the more our world stands to benefit from the awesome things that they create. When you’re willing to speak publicly and share your knowledge with others, you open up the possibility that others will be inspired to—and able to—create those awesome things.

The Template Method

Generic algorithms can sometimes become a source of creating dependencies within an application. On top of that, duplication can often occur when that algorithm needs to be implemented in various ways.

The Template Method solves this issue.

The Template Method Explained

At its core, the Template Method uses inheritance to separate the structure of and repetition that occurs in a generic algorithm from the variances that exist when the algorithm is implemented in different forms. The structure of the algorithm is placed into an abstract base class. Then, the derivatives of that class will add the specifics as appropriate.

Here’s an example:

In this example, BubbleSorter is the base class. It is serves as the template --or blueprint-- for how its derivatives will function. The doSort() method is the heart and soul of this algorithm and, thus, will remain the same for any derivatives of this class. Therefore, it makes sense to have this logic here in one place.

Now that we have the structure, we can create as many derivatives as we’d like. Here are examples to two such derivatives:

In these derivates, the only thing we changed was the type of the array that was being sorted. If we needed to sort longs, strings or any other type, we could do so easily by creating a new class that derived from BubbleSorter.

Why would we ever use this?

The template method is a valuable pattern when you know that there will be algorithmic tasks that are repeated throughout your application. If the same algorithm is implemented multiple times throughout an application, that creates duplication. Duplication is the enemy of clean code because it makes it harder to change your application in the future.

Let’s say, for example, that we discovered that there was a flaw in the way our algorithm was designed and we needed to change a calculation. When we only need to make a change in one place, that change becomes trivial. However, if we had to make that change in several places, we open ourselves up potential disaster because someone could end up overlooking one of the spots where the change needed to be made. This could result in bugs that are extremely hard to track down.

Drawbacks

When using the Template Method, it’s important to keep in mind that this adds complexity to the application. If the application is small and not likely to need different types of bubble sorters, we could end up with a smell of Needless Complexity. In this instance, the complexity would be added because we would have created two classes when one would have been totally sufficient. Because of this, it would be prudent to delay the usage of this pattern until it becomes a necessity.

Additionally, one must carefully consider the structure that has been created within the abstract base class. Adhering to this structure implies that there will be no variance in the derived classes. So, care must be taken so that the derived classes would, in fact, align with the structure.

All in all, the Template Method is one that does a good job of keeping code clean and organized when it comes to generic algorithms.

My First IPM: A Success Story!

The Iteration Planning Meeting (IPM) is pretty much the heart and soul when it comes to how the Software Craftsmen at 8th Light work with clients. The IPM is a weekly meeting that our Craftsmen have with clients to demo work that was completed for the iteration and ensure that it is aligned with what the client expected. Then, the client decides which features are added next and requirements to complete that work are gathered by the Craftsmen.

The approach to how these meetings are handled is what sets 8th Light apart from the scores of other countless software consultancies both near and far. So, it stands to reason why this is such an important part of the apprenticeship.

“Get Ready To Fail”

I will never forget these words—spoken by my mentor when I first interviewed with him. I mean, who says that in an interview?! Yet, he was totally serious…as he was well aware of the challenges that he would soon have me face. And face them, I did because…

I BOMBED my first official product demo.

No, it wasn’t the bomb! I bombed!

When I was given my http server challenge, it came complete with a two week deadline. On top of that, I was also responsible for reading a chapter from an assigned book and writing a blog each day. To no great surprise, this proved to be an impossible feat. The server was very challenging and kept my mind completely occupied. So, as one would expect, my assigned reading and blog writing took a complete nose dive.

Then, came the demo.

The demo of my server was completely doomed from the start. After two weeks, it still wasn’t completely working as it should have been. To top it off, I did not prepare for the demo beforehand. So, at the most critical moment, when I went to start the server for the first time, I realized that I had not even updated the jar file that would need to be used in order to run it! I had been testing the server functionality from my IDE, which, of course, a customer would not have access to. And, adding to the pile of rubbish that my demo was now becoming, when I hit these snags, I pretty much froze and did not verbally communicate what the issues were. It was a total train wreck.

My mentor took me aside and talked to me about the importance of the product demo and revealed to me that he had been testing me with regards to giving me way more work than he knew I could complete in that timeframe. I learned a valuable lesson that day. I was so caught up in wanting to be Super Apprentice, that I didn’t want to say no and offer alternatives when I was confronted with too much work. This is a huge “NO NO” because, as a Craftsman, I’m certain to be in situations where a client may want a feature or other deliverable that may be impossible to deliver within the timeframe that they want. It’s at this moment that I will need to be transparent and straightforward. Not only that, but our clients are counting on us to deliver what we said we would, when we said we would deliver it—and it should be free from preventable bugs and defects.

So, I took this to heart and distilled this lesson down to a few essential points.

1. Practice the demo.

It is customary for our Craftsmen to practice their demos at least three times before actually showing a client. When the practice demo succeeds without any issues, it is considered ready to demo to the client.

2. Be willing to say No and offer alternatives if need be.

Often, it’s hard to say no because many of us want to please our clients or others that are expecting something of us. This can easily lead to a catastrophe. The reality is that we will garner the most trust and respect when we hold true to what we know is best for all involved.

3. Deliver.

True enough unforeseen things can happen. However, our Craftsmen are known for delivering on or ahead of time. If there are hiccups, the customer is informed well in advance of the demo so that there are no surprises.

Now I’m working on an internal application. In this phase of my apprenticeship, I am responsible for estimating stories and delivering on them just as I would to with an external client.

I took the above lessons to heart and worked to make sure I didn’t make the same mistakes when it came to my first official IPM. Because of this, the demo went extremely well. It felt like a major win—especially since it was tons better than the demo I did for my server project.

The Command Pattern

It’s always an encouraging, yet interesting, paradox when you learn something new—only to realize that you had already essentially been doing the thing that you just learned about.

Was that confusing?

Well, let me clarify.

I’ve been spending time reading and learning about software design patterns. Software design patterns are hugely beneficial because they constitute proven approaches for solving the most common types of problems. There are several that I’ve read about recently. But, for the sake of this post, I will focus on the Command Pattern.

When utilizing the command pattern, one would simply create an interface with only methods that invoke a command. The defined method would then serve as the command that objects which implement that interface will use in order to to carry out the specified behavior. What makes this pattern nice is that it is extremely simple and appropriate in a wide variety of situations. Further, the command pattern is a terrific way to keep your code decoupled because it prevents the object that requires action from knowing the details of how that action needs to be performed.

To better explain, let’s look at some code from my HTTP Server:

In the code, the generate() method served as my command. Although, I used an abstract class here, the premise remains the same. Placing the generate() method in the Response Generator allowed for me to easily craft and generate different kinds of responses based on the type of request that came in. Here’s an example of one of those responses:

Additionally, this allowed my application to adhere to the Open-Closed Principle. Handling a new response for a different situation would now be as easy as creating another class that extended the ResponseGenerator.

The part that excites me is that I used this solution before actually reading about the command pattern. Granted, I arrived at this solution after talking though it with my mentor. The learning process much more exciting when you discover that you’ve been doing something previous to actually learning about it. The thing that I would do differently next time is that I wouldn’t have any additional non-command methods like getStatusLine().

"You'll Understand One Day"

I have had the good fortune of being blessed with amazing parents.

One example of what I witnessed as a youngster was seeing my father fulfill a childhood dream of becoming a lawyer.

First, I must mention that I am the youngest of three children--my older siblings being 3 and 5 years older than me. That said, it wasn't until I reached 10 years old that my father completed his undergraduate degree. Pretty awesome, right?! This, however, wasn't the most impressive thing.

After obtaining his Bachelor's degree, he proceeded to attending law school--full time--in the evenings. But, let me remind you that there were already two teenagers in the house. As most can probably readily understand, teenagers alone aren't cheap. This meant that my father could not afford to just quit work and focus on law school exclusively. Therefore, he continued working full time in the day while attending classes in the evenings and obtained his law degree when I was 15.

But, that's not all.

Being the children we were, we were all quite active in sports and other activities. Not to mention, school work begins to get a bit tougher for kids as they enter junior high and high school. Interestingly enough, my dad never missed any of our sporting events and was always available when I needed his help for schoolwork.

As I got older, and started a family of my own, I recall asking my Dad on several occasions: "How did you work full time, attend law school full time, and still be there for us consistently?

He would simply reply: "You'll understand one day."

UGH!

I now find myself in a somewhat similar situation. Similarly, I find that I am also pursuing a childhood dream. Though, I am not working and attending school, in many ways I feel like this apprenticeship has been every bit as intense and demanding on my schedule. That is to say, in many ways it feels like I'm working a full time job and obtaining a higher level education.

This past week was my first official week where I was responsible for estimating and completing stories (features) by a given deadline. The application is called Artisan and it is an internal application that we use to plan out our iterations and document the customer's acceptance criteria for work that we perform. In true 8th Light style, I was assigned to a project whereby I had no previous experience with the languages and frameworks that I would be required to use. Therefore, I found myself struggling most of the week.

In order to make my Friday deadline, I pulled a near all-nighter on Thursday night--leaving enough time for about an hour and a half of sleep.

Then, something wonderful happened.

On my train ride into work Friday morning, in between a series of short naps, I ended up saying to myself, "This must be how my father must have felt all those days."

Then, it occurred to me. I now understand.

Thank you 8th Light for helping me to understand first hand what it takes to be fulfilling a dream.

Understanding Policy in a New Way

During my apprenticeship, I’ve heard the term “policy” used several times in reference to SOLID Principles and design patterns. While, I felt I understood what it meant, the real world application of it didn’t quite sink in until I read about the Facade Pattern.

The Facade Pattern Explained

According to Wikipedia, facade comes from the French word façade which means “frontage” or “face.”

In software, when thinking about the Facade Pattern, the main thing to remember is that the chief goal is to make a class or package that has a complex and general interface easier to work with. This is done by creating a separate class or interface that provides simple and specific access to that complex class or package.

So, putting these together, a class that is general and complex will get a new face.

Facade in Action

The java.sql package is a great example of a very general and complex package:

The java.sql package has:

22 Interfaces

7 Classes

3 Enums

17 Exceptions

Additionally, each of these have a host of methods that can be called on them. What’s more is that any given application will only need to use a fraction of the java.sql package. So, in order to keep the application clean and easier for developers to use, we could create a DatabaseHandler class that becomes the facade. In the DatabaseHandler, we’d specify specific methods that our application needs with regards to accessing data.

Examples of such methods could be:

save(studentID);

getStudentData(studentID);

Then, the DatabaseHandler would implement the appropriate methods that it needs from the java.sql package in order to perform the transaction.

This Is Where Policy Comes In

The act of creating the Facade (DatabaseHandler) has now created a policy for our application. The policy is that all data retrieval and manipulation should be done through the DatabaseHandler instead of by referencing java.sql directly. Any direct access to java.sql would equate to a direct violation of the policy set forth with regards to how data should be accessed in this application. Further, whenever policy is violated, we invite the potential for disaster into our application because debugging becomes much more difficult.

A clean and well architected application creates policies that are appropriate to the system as a whole. This is critical because the policies help to dictate how new code will be structured. A system with good management of, articulation of and adherence to policies helps it to stay clean and healthy throughout its existence.

“Delete Everything and Start Over”

When I began my software apprenticeship this past December, I had not predicted that those five words would end up having such a profound impact on me as an aspiring Software Craftsman.

At the onset of my apprenticeship, I was thrust into many new things all at once. To start, I had to get used to a new operating system (OSX) and new tools that I had not previously used. I had to learn a new language to complete my first challenge from my mentor. On top of that, I had to begin utilizing new programming practices and patterns in order to satisfy the requirements for this challenge.

During my first code review, my mentor assessed how well I’d done with implementing some of the new methodologies and techniques that I’d been reading about. My code wasn’t up to par. It was at this moment that he instructed me to do something that I’d never done—or ever wanted to do. After giving me some feedback on how to make my code better, he instructed me to “delete everything and start over.”

I accepted the challenge with grace and style, but I’m sure he could tell that I was a tad bit nervous and a little more than a tad bit shocked.

The Outcome

Within two days I was back to the point that I’d been at when I’d had that initial code review. Two things surprised me and left me with a brand new impression of how effective it can be to delete code and start over:

It only took me two days to complete what had previously taken me about two weeks.

My code was now immeasurably cleaner.

Even though I noticed the benefit that I’d gained from deleting my code and starting over, I still felt like it might be a fluke. That is, until I got stuck again. I was struggling to get the Minimax portion of my application working and had hit a wall. After spending a few days struggling to understand it and get it working, I decided, on my train ride one morning, to just delete that portion of code and start it over. The result — I had it mostly working by the time my train ride was over (in about an hour).

It was at this point that a real revelation occurred:

The code that I was writing was controlling me.

That is, I would regularly yield to what I had already written instead of exercising control and making adjustments where they needed to be made.

What you need to know about deleting code and starting over.

The five words freed me from the grasp that my code had on me. It opened up a whole new world in my realm of understanding. This is what I learned:

1. Starting over from scratch is a myth

When deciding whether or not to start over, always remember that you’re not truly starting over with nothing. In the case of software, once you have made it to a certain point--whether you’ve completed your story or not--you possess the knowledge of what it takes in order to get back to that point. Going through the process once will undoubtedly give you a certain level of knowledge and understanding. Once you truly understand something, you’ll realize that you can recall that knowledge at the time of need. The slate is never truly blank.

2. Each time you start anew, your confidence grows

Knowing that you can delete code that you’ve written and rewrite it even better is a huge confidence booster. For one, it’s awesome when you realize that the time to rewrite something is often dramatically reduced while the quality of the code has increased. Secondly, you also end up realizing that you knew more about how to solve the problem at hand than you may have given yourself credit for. Needless to say, when your confidence grows, you become more willing and able to tackle bigger and better problems.

3, You remain in control.

I truly believe that every developer has been in a position where they’ve struggled to get something working because the surrounding code would not yield to their demands. When you can confidently remove code, you gain control. Thus, you become a bit more free to implement your solution in a way that feels right to you. Sure, there may still be some constraints, but the fact remains that you have shifted the balance of power.

Onward

We ought not to treat the code that we write as though it is inscribed in stone. If we do, we’re missing out on the true essence of what writing great software is all about. Great software ought to change and grow over time. This cannot occur successfully if the previous keys are not taken into consideration. Consider deleting some portion of your code. When you do, you will be pleasantly surprised at what the outcome will be.

Trending Blogs

Recently Viewed Blogs

Malcolm's Musings