Friday, March 17, 2017

There Is No Such Thing As A Short Term Hack

One day during a review of some changes, a new user interaction was introduced that was basically making use of a toggle in the place of a checkbox. This gave rise to the desire to make other parts of the system have one user control for this behavior. It was said that the change in one spot to use a toggle, with other spots still using the old antiquated checkbox, would confuse users. We should instead take time to understand how far the change would need to extend.

Fast forward a couple of months, one early morning I suggested to a colleague that we create an email group for our team. He said "yeah, but then you have to keep up with it when people come and go, and it becomes a big pain and get's out of date and kind of a hassle" to which I replied something to the effect of "welcome to my world and what it's like to maintain software".

A parallel to both of these is when we collectively as a team say, "Yeah, let's go with the hack for now so we can release...and then later we'll come back and clean it up." What's the commonality? Where is the parallel? All three are a point in time where a decision has to be made about maintenance in one form or another.

What does a hack look like? It comes in many forms. Oddly placed "if(...)" checks sprinkled around. Ever growing indentation levels in a method, indicating harder and harder to understand logic to get you down into those inner most levels. Duplicated identical switch statements hiding classes that are waiting to be born. Code smells sprinkled here and there, and... and... and everywhere.

This business decision of a "short term hack" leaves a bunch of garbage laying around in the code. As a team, we may have great intentions of "coming back to clean it up". But the reality is, that rarely happens... and when it does, it can be the exceptional case. Look, I get it. There is often not any perceived value of coming back to take care of it. But I as a user of that code, have to deal with that. And so do the poor schlubs that I work with that bump into that hack and are left scratching their heads.

It's confusing on several orders of magnitude larger than someone having to handle grocking a checkbox vs. a toggle, or to maintain an email list. Over time, more and more of these "compromises" cause the code to become more and more brittle. It becomes harder and harder to change. Harder and harder to understand. To reason about. The compromise is on the side of the code. The health of the artifact that should be an enabler of speed... of our ability to pivot late in the release cycle... rather than a drag on our speed, becomes more and more un-healthy.

When things begin to take longer and longer to deliver, do we ever look at one another as a team and say "well, this is because we have made some "compromising" decisions along the way that have affected the code adversely and now we're feeling it". I think that's often not the case. Sometimes it is, don't get me wrong. Sometimes we do recall those compromises. And sometimes we take the time to inject some health back into our code artifact.

But, more often is the case that we have lost all context from those far off historical decisions, and now we just feel the pain. Whether it be from too much time passing, or because people that came to the initial "compromise for a short term hack" are no longer around working on the code / on the project / with the company. Or maybe they are still around, but they are not the one staring that compromise in the face at the moment, you're the poor schlub I mentioned above. And there is no way for you to recapture that intimate moment of the past where yes we were able to deliver back then... but now... now you have a story on your Kanban board that's taking forever to make it out of the "Developing" column. So the "compromise" has come back and is staring the larger company straight in the face, specifically you... your product owner... your team. And there you stand as a developer with a cracked egg all over your face. Given enough complaining room and frustration and you might just start to sound like a crotchety wind bag full of hot air about how difficult the code base is. Product owners don't care to hear about the difficulties of the code... they would much rather hear that your story is complete and your ready to take on more work.

Being honest about what it takes to keep a code base healthy is not an easy thing. It's soo necessary though. Be a professional. Do the right thing by the code, and keep lines of communication open between you and your team about what your doing and how it's coming. No, you can't fix the whole system in the course of one story. But yes, you can chew on a mouthful of it. Always making small improvements, and biting off some larger ones along the way can breath new life back into the code asset as well as your team.

Fight like hell to keep them out. Don't offer them up as an option. But (and I do mean but), if you do have add in a "short term hack" in order to deliver (let's all be honest here... it happens... delivery has to happen, it's what keeps the lights on), insist at the very least that a story is created to come back and address the hack. Leave some artifact as a conversation piece to come back to. And make sure that story has plenty of detail around it, capturing as much of the moment as possible to get you back into the context of when the "compromise for the hack" was made. And then fight like hell to play that story as soon as possible.

Short term hacks become long term hacks that harm code agility. Even more, they become longer term problems as you design more and more of your system around them... making additional compromises... predicated on the far off and often forgotten past compromises that the company as a whole made. Keep the code agile, and your company will be too.

Tuesday, May 17, 2016

Eventually Crappy People Show Up, and I'm Flattered

ShopToTrot has been out for a little more than a year now. We've gotten enough users for me to say that there is enough interest to keep going, and that feels really really killer. Like anything that attracts people online, some people that come through can be, well Crappy. There, I said it. By Crappy I mean that they have no intention of using the system as it was intended. They are there just to cause trouble.

Well ShopToTrot has received enough attention that we've gotten our first Crappy user that hung out just to put junk ads into the system. This one did have a sense of humor though. He or She at least mocked us a bit by putting in a photo of their "horse" (seen above) that mirrored our stock photo that we use if you don't put any pictures of your horse in (seen below).

For a moment, I was highly irritated. But that shortly gave way to flattery. Someone cared enough to come into our system and stink it up a bit. My point to all of this is simply, enjoy the Crappy people. They can't help themselves, and truly probably need a hug.

More to the point, they are a signal that you are becoming successful. And... if it weren't for them, you might not harden the system.

Wednesday, April 27, 2016

My Manager Hat vs. My Worker Hat

I mentioned a while back that one of the podcasts that I've been listening to is Simple Programmer, by John Sonmez. He gave some advice to a listener, and I've had it rolling around in my head since I heard it from Episode 120: Do I Have To Be An Entrepreneur To Be Successful. Just recently I've started to walk in that piece of advice.

I may get some of the particulars incorrect, but the overall gist will be in the spirit of the exchange.

John told the guy that to make progress in his extra goals, he needed to have the ability to wear two hats.  As I remember them, they were:
  1. A Manager Hat 
  2. A Worker Hat (I lovingly call this one the Doer or Executor Hat so if you see me use those alternate forms you’ll know to what personality I’m referring to). 

The Manager Hat:

This is the hat that you wear when you're deciding what should be accomplished by your Worker. So effectively, what he was saying is that you need to take some time to plan out your week. Be deliberate about setting goals for what would get accomplished during that week so you can keep sight of them. I've chosen Sunday night at 9:30 for this hat to adorn my head.

The Worker Hat:

The other hat he mentioned you needed to pick up is a Worker Hat (or a Doer Hat). This is the hat you put on once the Manager Hat comes off. You wear this hat for the rest of the week. Once this hat comes on you simply execute the plan unquestioningly. You don’t deviate from it, you just simply do what your Manager has planned for your Doer.

Once you get through the week, wash, rinse, and repeat for the following week.

In Practice (as I have experienced it thus far):

As I have tried to operate in this, I’ve discovered that my Manager always has unrealistic expectations of what my Worker can accomplish. Big surprise right? That’s often the case in the real world, outside of this little dual personality experiment that I’m doing. So what does that really mean you may ask. Well, for me it’s meant that what my Manager has scheduled for a particular day might not be what my Worker has been able to accomplish for that day. And there isn’t anything scheduled for this thing that my Worker hasn’t finished on the next day coming up.

Sooooo, my Worker had to negotiate with my Manager. The Worker had to tell the Manager, “Hey dude, I’m not done. I haven’t been slacking, it’s just that it’s taking me longer… or life has happened and inserted itself in the middle of your pre-scheduled routine, thus disrupting the schedule."  If you’re anything like me, you’re trying to accomplish these things in the midst of working at your day job, raising a family, and potentially working on these things with other people. Any one of those three things tend to try and get in the middle of your Worker accomplishing what your Manager has laid out. It happens, we’re human, and plans may need to change.

So how have my Manager and Worker adjusted expectations of what will get accomplished. Well, the Worker starts out the week working diligently on those things scheduled by the Manager. And if the Worker isn’t able to complete a day's tasks, then the unfinished task/s get pushed to the next day by the Worker, and the things that were scheduled for the next day get pushed accordingly through the week. The Manager has placed a bucket at the end of the week to catch anything that gets pushed completely out of the week, and things are pulled from that bucket for scheduling the next week.

This way, the Worker has some sense of continuity and doesn’t get disgruntled with not having completed anything at the end of the week, but has spent it thrashing about trying to accomplish everything (when that might not be possible). It’s important for progress and the Worker’s feelings and sense of accomplishment to complete things and get them behind him. If the schedule needs to be adjusted then so be it, the Manager needs to compromise.

This has made the things that I've been trying to accomplish more concrete. And by "more concrete" I mean that there are very real time slots for work to slip into, and expectations on myself that those things scheduled (and only those things scheduled) should be completed.

Life is going to happen. Your plans will get disrupted. You need to be able to adjust, and in the adjustment not loose focus on what your goals are.

In the closing, figuring out the balance between your Manager Hat and your Worker Hat can be Detective work for a while. But in the end you can find some happy medium and hopefully some cadence as to how much you’ll be able to accomplish in your upcoming week.

Monday, February 29, 2016

Lunchtime at The Movies

Well, not exactly at the movies (although that would be nice). I've started doing something at work to try and socialize and spark discussion on either technical things or the process of building software types of things. It's a divergence from the occasional post stand-up video showing off some insane accomplishment someone does in a car, or on a motorcycle, or skateboard, or bicycle. It's a bit more serious than that, and for good reason.

One of the great things about working with a team of good people (and by good I mean you care about producing useful stuff and helping out your fellow humanzies) is that everyone has been exposed to different things, have differing bases [bey-seez] of knowledge, and hold their own ideas about technology and the world. You may find out about them either through pairing with folks, coming together as a larger team to solve a problem, over coffee, or on a team outing.

Another avenue is over lunch while watching a video. We live in a time where content is being put out at an unheard of pace. Conferences will often put out either some or all of their material after the conference for absolutely free (truly a service to fellow humanzies at large, looking at you StrangeLoop... thank you). This gives us commoners a chance to gain access to well thought out technical discussions about all kinds of things that we normally would never have access to unless we work for employers that find value in sending us to some conferences (and most employers unfortunately do not do so), or we take the initiative and foot the load ourselves.

Having an area to watch things like this is extremely helpful, and I don't mean everyone crowding into one of your fellow colleagues cubicles and squinting to watch it on their tiny laptop monitor. I mean a proper spot with a nice large screen and comfortable seating to relax, eat lunch, enjoy one another's company, and learn.

Lunchtime at the movies, for me, aids in spreading some of the thoughts and things that I may be interested in out to my larger team. I've pulled together some of the places that I look to for snagging a video from below. If you tend to watch vids of stuff from the chatterboxes in our industry, where do you cull them from? I'm not looking for Pluralsight or Udemy types of courses, but more conference or meetup/usergroup types of things.

Sunday, February 21, 2016

What are your favorite podcasts?

Being a husband to my wonderful wife, father of 2 amazing kids, employee of an awesome company, creator of things (like ShopToTrot), someone who is trying to blog more, create more, do more, yada... yada... yada, time can be scarce. One of the tools that I use to keep in touch with what's what in technology land is podcasts.

I usually sneak in a listen on my way into work after I've dropped off my little munchkins at school, which typically amounts to 15 to 20 minutes of geekery. While I typically don't make it through an entire podcast in one sitting, as most run about an hour, I get enough of a fix on my morning drive to keep tuning in the next day. It's just enough to give me something to think about either actively or on one of my many background threads that like to solve things subconsciously for me.

Is there always a direct benefit to my daily grind... no. But it does keep me abreast of techno land in a way that nothing else can. I don't always have time to sit down and read deeply about a subject, and this helps to gain a deeper than surface level understanding on some topics.

Here's what I've been listening to lately:

SE-Radio - This is one that I hit for what I call bigger fish I guess. It's where I'm more likely to run across someone like Linda Rising, someone chatting about CAP theorem, or a good hearted discussion about the GOF 20 years after the initial publication of their book.

The Changelog - This is where I go to get my open source fix and things that might be more on "the edge".

Simple Programmer - This is where I hit for good advice on moving my career forward and personal development (and in all honesty I relate to the guy).

I did a search for "github podcast" and this awesome list turned up from Guilherme Dutra (thanks dude, it's a part of the awesome list of lists). It contains quite a bit and perhaps you can discover something new there.

I've recently started using Overcast to manage and listen to my podcasts, I recommend it. One of the reasons I made the hop was I wanted something that helped in controlling what podcasts actually got pulled down to my phone vs. allow me to stream. Overcast will let you set how long to hold onto a podcast before deleting it... you can always go back and grab it again if you need it. If you decide to use it, be kind and drop the folks that make it a few bucks... nothing in life is free.

This isn't necessarily my complete list or my historical list, but it is the list that's comprised my last 6 months or so. I'm interested to know, if you listen to podcasts, regardless of if they are technology related or not, what are they? Everything I listen to isn't necessarily technology related (although lately they have been), and I would love to know what your tuning in to and why you are tuning in.

Sunday, February 14, 2016

One Class Per File

I've been using C# as one of my primary languages for the past 6 years where I currently work. Prior to that I was working with Java. One of the immediate differences that I noticed was that it was not uncommon to have multiple public classes in a source file. C# allows it, so why not.

Coming from a Java background I was used to one public class per file, where the filename needed to match the public classname in the file, and for me... I preferred it that way. I felt that it helped to organize the code. Some may say, having multiple classes in a file can aid in readability/discoverability/understandability/insert-an-ability. All true, they can. It can also be harmful in each of those respects as well... all depends. 

This week I've discovered a new reason why I prefer one class per file. Changes to classes are more traceable if a class has it's own file. Huhhh?

The reasoning goes like this. If I start out and have a couple of small public classes in a file, then tracking changes doesn't seem too difficult. The problem comes in when the classes grow. Your file will becomes larger and larger, and when you look at the file, there might all of a sudden be too many concepts in the file for you to keep track of. This can especially be the case where you can have a file named a name that has nothing to do with any of the classes inside of it (poor form imo, but to each his own). Some of the classes in the file may be related to the filename, but if sloppiness has crept in (not unheard of) then other classes may not be as closely related to that filename. Different concepts and abstractions may have crept into the file, and you may not realize it for a while. Yuck.

Then one day your in the file and your like, ZOMG, this file is too large and has too many concepts in it, I have to tease it apart. And so you do. You become the boy scout and you tease classes out of it, putting them in their respective files with the respective filenames and namespaces. And when you do this, your original file can in the worst case be empty (remember, the filename doesn't have to match any of the classes, and you just teased all of the classes out). And so you delete it. No problemo dude. And then you commit it and push it up to the remote (because your working in git).

And now, well now all of the history that you had in commit messages is gone for every class that was in the original file. It's not like renaming a file in git. You can always use the `--follow` flag on the current file you have to retrieve the full commit history for that file.

git log --follow path/to/filename 

Unless your a good tracker, chances are you're not going to re-discover where those commit messages went for the deleted file. Perhaps you'll never need to. I hope so.

Commit messages are a blessing for both me and my fellow developers because they are in some part a diary of what we were thinking about when we made changes. I've been getting more and more accustomed to making rather large commit messages lately. I'm recording more of the thoughts that I had around the design choices I've used, and perhaps even recording patterns I used in the commit.

The history of changes to a class is important to me. Maybe I've found some religion on this issue, and most probably, I'm going to be more prudent on keeping... one public class per file come Monday.

Brad Abrams - Design Guidelines, Managed code and the .NET Framework
- Source files should contain only one public type, although multiple internal classes are allowed