Today, I'm dropping about a dozen tables from our database. The tables are holdovers from a legacy bit of the previous system that were needed as scaffolding to get the new system in place, but are no longer necessary. They are not used for anything, and the data are not useful in any way or needed for audit. Then again, they were not really in the way or costing us anything, right?
And yet I feel a great deal of joy getting rid of them.
Thing is, all team members knew that we needed to do this maintenance, and no one disagreed that these appendix-like structures were no longer needed, but getting priority to clean them up was difficult. The general feeling was that the unused code, data structures, etc. weren't really hurting anything.
There's been a good deal of study around clutter and anxiety, and the internet is awash in articles that link the two. A system that has a lot of old code and data structures is akin to a hoarder's house full of clutter. It causes anxiety. And there are very serious parallels between code clutter and home clutter.
So let me be clear: cleaning up your messes is a priority. You don't generally think about it, but every time you want to go look something up in the database, your eye has to scan over those legacy entities. There's friction there. Do a code search for a class? You find more entries than you need to. There's visual clutter there that takes time to scan.
Yes, you may not use those classes anymore, but they have references to your framework and other classes, right? If you make a change, there are more changes you have to make to get things to compile, more places you have to make sure you don't make a mistake.
Having all these extra classes and structures lying around creates a death by 1,000 tiny little cuts. Deal with this infinitesimal time waste enough times a day, and it adds up to real time wasted and real productivity impacts.
So clean up your codebase. Make it a priority to remove outdated structures that are either legacy or the result of overengineering (which I define as ignoring YAGNI). Minimizing the number of tables, objects, views, whatever in your system makes the system leaner and more easy to deal with. It minimizes cruft and code clutter and makes future coding easier by reducing friction.
Better still, removing old untested code increases your test coverage metrics for free!
So please take some time and load some of these stories into your backlog today.
Tuesday, September 16, 2014
Tuesday, September 9, 2014
Monday Morning Motivation
Monday mornings are kind of a drag, right? Garfield hates Mondays. "Looks like someone's got a case of the Mondays." You've just come off enjoying your weekend of relaxation, sleeping in, home repair, family togetherness, or whatever else makes you happy, and now that's over.
If you have trouble with Mondays, it could be that you're not happy with your job. Having a job that you're excited to go to is a good way to get motivated and not actually dread the end of the weekend. If you aren't that happy with your current gig, you should quit your job.
If you do love your job, but still the idea of waking up early and getting all duded up to commute to your place of work has you dragging a bit, here's one tip to make that Monday morning a little easier.
When you're finishing up your work on Friday afternoon, figure out what you want to work on early Monday morning and leave yourself a breadcrumb to it. In the development world, my favorite mechanism for this is to pick the next story off the board and write a unit test for it.
Write a failing unit test. Leave it failing locally. Monday morning, you'll come in and see your little NCrunch indicator telling you that you have a failing test, and you'll know exactly what you need to start with. Get that test to pass.
This is also pretty good for keeping yourself focused, too. Instead of diving into email in the morning, start out by getting that story done. You'll feel great about having something accomplished under your belt, and it sets a great vibe for the week.
If you have trouble with Mondays, it could be that you're not happy with your job. Having a job that you're excited to go to is a good way to get motivated and not actually dread the end of the weekend. If you aren't that happy with your current gig, you should quit your job.
If you do love your job, but still the idea of waking up early and getting all duded up to commute to your place of work has you dragging a bit, here's one tip to make that Monday morning a little easier.
When you're finishing up your work on Friday afternoon, figure out what you want to work on early Monday morning and leave yourself a breadcrumb to it. In the development world, my favorite mechanism for this is to pick the next story off the board and write a unit test for it.
Write a failing unit test. Leave it failing locally. Monday morning, you'll come in and see your little NCrunch indicator telling you that you have a failing test, and you'll know exactly what you need to start with. Get that test to pass.
This is also pretty good for keeping yourself focused, too. Instead of diving into email in the morning, start out by getting that story done. You'll feel great about having something accomplished under your belt, and it sets a great vibe for the week.
Sunday, September 7, 2014
Creating an Ego-Free Environment
For years I've been talking to my teams about "ego-less development". I don't remember where or when I heard about the concept, but I thought I'd take a couple minutes to talk about what that means to me.
For me, ego-less development starts with the recognition that not everything is about me. All of this code we write daily is code written by us on behalf of and for the organization that employs us, and for which we are paid a (hopefully) fair wage. When we are done writing it, we do not own it. It is not who we are. The idea behind an ego-free environment is that you check your ego at the door, and do your best to produce the best software for the company the best way you know how.
You can think of software as commissioned art. Not every piece is perfect, but when the project is over, the piece sits in the living room of the commissioning person to be enjoyed by that person, not taken home.
When you take the perspective that the code that you write is not yours, it becomes a lot easier to decouple yourself from the code you write. Many people take criticism of their code as a criticism of their own person. While criticism on your code can include a criticism of your skill set, it's should not be intended to suggest anything wrong with you as a person, even though your mind might translate the criticism.
The translation works like this: What's said is "Well, I see something wrong in this code here." What is heard is "You wrote this code. Something is wrong with it. So something is wrong with YOU! STUPID!"
If you're a team lead, you need to make sure that the culture changes so the message comes across correctly. Here's a couple things I've found really helpful in cultures I've been part of:
Freely admit your own mistakes: Everyone makes them. It's no fun to make them, and worse to have things blow up because of something you did. When things do explode, fess up. No excuses. "I did that. I'm really sorry." You're looking to demonstrate the correct approach that you're looking for. Lead by example.
Let people know it's okay to screw up: While habitual bad performance has to be addressed, not every little failure is something team members should feel like they have to fret over. Be honest. Don't gloss over it by saying it's okay. "Yes, you screwed up. We've all been there. We'll do what we need to fix it."
Don't map ownership of specific code to people: If there's a bug found in the system, there's a tendency to say something like, "Oh, looks like a bug in your code. Guess you better get in there and fix it." Once the code is integrated, it's company code. You don't own that code. Anyone can go fix it. Throw the bug in the backlog and let the next available dev snag it.
Use positive language, even when disagreeing: Yes, this is software, and at some point you've got to ship. Sometimes there are differences of opinion, but you lose the instant you say something like "Well, the smart thing to do is..." That's another way of calling someone stupid, if they legitimately disagree with you. Language and communication sets the tone. Make sure that you phrase the argument in terms of risks, rewards, costs, or benefits. "The problem I see with approach A is that X, whereas this other approach [note: not "my approach"] avoids that problem."
Let's say you even get to Nerdvana and have an ego-free environment. Never forget that there are scores of cognitive biases out there and that at any point, you may be falling prey to them. Keep an eye on your own communication to ensure that you're truly communicating the way you would like. Even in an ego-free environment, people still can be defensive.
Not many environments work as one-person bands. Great work takes great teams. Great teams are formed by trust. Check your egos at the door, and build that trust in your environment today!
For me, ego-less development starts with the recognition that not everything is about me. All of this code we write daily is code written by us on behalf of and for the organization that employs us, and for which we are paid a (hopefully) fair wage. When we are done writing it, we do not own it. It is not who we are. The idea behind an ego-free environment is that you check your ego at the door, and do your best to produce the best software for the company the best way you know how.
You can think of software as commissioned art. Not every piece is perfect, but when the project is over, the piece sits in the living room of the commissioning person to be enjoyed by that person, not taken home.
When you take the perspective that the code that you write is not yours, it becomes a lot easier to decouple yourself from the code you write. Many people take criticism of their code as a criticism of their own person. While criticism on your code can include a criticism of your skill set, it's should not be intended to suggest anything wrong with you as a person, even though your mind might translate the criticism.
The translation works like this: What's said is "Well, I see something wrong in this code here." What is heard is "You wrote this code. Something is wrong with it. So something is wrong with YOU! STUPID!"
If you're a team lead, you need to make sure that the culture changes so the message comes across correctly. Here's a couple things I've found really helpful in cultures I've been part of:
Freely admit your own mistakes: Everyone makes them. It's no fun to make them, and worse to have things blow up because of something you did. When things do explode, fess up. No excuses. "I did that. I'm really sorry." You're looking to demonstrate the correct approach that you're looking for. Lead by example.
Let people know it's okay to screw up: While habitual bad performance has to be addressed, not every little failure is something team members should feel like they have to fret over. Be honest. Don't gloss over it by saying it's okay. "Yes, you screwed up. We've all been there. We'll do what we need to fix it."
Don't map ownership of specific code to people: If there's a bug found in the system, there's a tendency to say something like, "Oh, looks like a bug in your code. Guess you better get in there and fix it." Once the code is integrated, it's company code. You don't own that code. Anyone can go fix it. Throw the bug in the backlog and let the next available dev snag it.
Use positive language, even when disagreeing: Yes, this is software, and at some point you've got to ship. Sometimes there are differences of opinion, but you lose the instant you say something like "Well, the smart thing to do is..." That's another way of calling someone stupid, if they legitimately disagree with you. Language and communication sets the tone. Make sure that you phrase the argument in terms of risks, rewards, costs, or benefits. "The problem I see with approach A is that X, whereas this other approach [note: not "my approach"] avoids that problem."
Let's say you even get to Nerdvana and have an ego-free environment. Never forget that there are scores of cognitive biases out there and that at any point, you may be falling prey to them. Keep an eye on your own communication to ensure that you're truly communicating the way you would like. Even in an ego-free environment, people still can be defensive.
Not many environments work as one-person bands. Great work takes great teams. Great teams are formed by trust. Check your egos at the door, and build that trust in your environment today!
Subscribe to:
Posts (Atom)