Brendan Enrick

Daily Software Development

The Joy of Removing Code

Removing code is one of my favorite activities. Isn’t it one of yours? As a software developer I strive to write less code. Sounds kind of funny, but what I mean is that I want the code that I write to be reused as effectively as possible. Having less code means that maintenance is easier. I can fix things faster, change things faster, find things faster, and figure things out faster.

This is a very good case of “less is more”, which is one reason why I love removing code. I really enjoy getting more or even equivalent work done with less code.

I just finished eliminating a constructor. Why? Well, it really was not needed. As it turns out there was a more appropriate constructor to use for the class. Not sure when or why the constructor was created, but it doesn’t really matter. I am fairly certain that nothing is using it after my removing it. Code still compiles. Tests still pass.

This does a lot of good things. It makes the class less intimidating by dropping the line count. It makes clearer which constructor to use when there are fewer of them. If I need to make a change to the constructor by either adding or removing a parameter for example there is only one place to do this now. Before there were two places.

I love writing code, but I also enjoy removing excess code. It just makes things simpler, which is exactly how I like things. I want my code to be just complex enough to work. When I am refactoring old code this is one of the best things to do. Chopping off all the bits and pieces of unneeded legacy code is progress.

Has anyone else removed any code recently they were glad to be rid of? Anyone eliminate any entire class libraries or anything cool like that?

“Do you want complexity with that?”

“No, thank you.”

Fast Beats Right, a Principle of Mediocre Programming

Steve Smith just posted an interesting set of anti-principles, anti-patterns, and anti-practices that make up mediocre programming. In the post one of the principles of mediocre programming that Steve mentions is,

Fast Beats Right (FBR) – It’s more important to get something done that probably works, or that works right now even if it will be hard to change later, than to spend time ensuring that it is correct or is well designed.

I think we’ve all seen people who code this way before. They’ll get the really quick, dirty solution in place. Steve also makes note of what he has experienced as management’s opinion of this behavior.

sometimes management may be OK with dictating that for a given feature or prototype, speed is more important than anything else

The really scary part here is that there are managers who think that faster == better. Some teams have programmers following this principle and the managers think those are the best programmers. Why? Well, that guy gets lots of new stuff done. These other guys don’t (because they have to clean up the crap the fast guy writes.) Sure, for any task that is small enough I can do the work really quickly without testing or structuring things correctly. However, it might not work for all cases. The code could be fragile. It is very hard to determine how well it will stand up. Down the road I might need to add on to that code, and it could be so bad that it needs to be completely rewritten.

I really hope that no one is stuck at an office where management believes that an FBR programmer is a good programmer.

Have you every worked with a coder like this? What was the opinion of developer from the management point of view?

How Coding Katas Can Help You

Here at Nimble Software Professionals one of the activities that we have started doing is coding katas. We do these to help hone our skills as software developers. We do them because we value continual improvement among our team. The importance of an ever-growing, ever-improving team is very important, and through constant training and reemphasis of these techniques we expect to be able to achieve this important endeavor.

As developers we are presented with problems we must work through on a regular basis. Solving these problems is easier if we know all of the theory and mechanics to help us along the way. Knowing design patterns helps, since these are patterns which occur often enough that there is a repeatable solution. You can also just be a programming genius, and that will also help.

So how useful is it to know a bunch of design patterns? Not very if you haven’t had experience using them. You will not see the opportunity to use it if you haven’t seen it used or used it. Through training and practice you will learn what works when and why.

A kata is about solving a known problem. The standard way to do a kata is to follow along with someone who knows how to solve the problem. Following along with someone will let you see how to solve the problem the correct way. This is designed to help you think and solve problems the same way as that known smart person solves problems.

That is a great approach, but I prefer doing that after trying to solve the problem my own way. This lets me get my own perspective on solving the problem first. I can then compare my thought process with the one of the kata leader. Perhaps I prefer something I did over something they did.

The kata should be repeated again later. This time you’ve done it before, so your new solution should be better. Once you finish once again compare with how the leader did it. Make improvements like this every time until you have either the same thing as the leader or until you’re satisfied with your solution. Once you reach that state you will still do the same kata, but attempt to repeat the same solution, so that the process for solving the problem is well understood. You want to know how to solve problems. You do not want to think about how to solve problems.

One of my favorite katas is the Bowling Game Kata. One of the reasons I like it is because my first time solving the problem I created a solution nothing like the one that the kata teaches. From the kata I have improved how I do things. In my first solution for it I violated YAGNI.

My solution worked very well, and if there would have been more development of the problem my solution might have ended up being “better”. But it is true that I do not know what might come for the project in the future my solution was not as good, and since then I have been training myself to not make the same mistake again. By following along with the kata I’ve learned to improve the development process I use.

Programming is Not Just Typing

One of my favorite quotes about programming languages comes from Ward Cunningham who said, “If you don't think carefully, you might think that programming is just typing statements in a programming language.” Not sure if he really said it, but it is attributed to him plenty of times on the Internet.

So back to Ward Cunningham for a minute. I really like that quote. It says one very powerful thing about programming that I think is known by a lot of people using programming languages, but I am not always sure they think about it in this manner. I know that non-programmers certainly don’t understand it. Plenty of people think that all we do all day is type, but there’s a heck of a lot more to it than that.

Nearly a year ago, when Jeff Atwood posted about our being Typists First and Programmers Second, I was quite appalled. Here is one of the most respected individuals in our industry, and he’s making a statement like this in a blog post. Sure I agree that one of the core skills that every programmer needs is the ability to type. I don’t disagree with the importance of typing. I think a programmers ability to quite quickly and accurately is extremely important. He says in the post that there are other things of importance, but I refuse to say that our primary skill is typing.

Although I find that programmers should spend some time thinking and some time typing. If you’re typing non-stop as fast as you can then you’re probably not thinking enough about what you’re typing.

Like broken clocks, even pointy-haired managers are right once a day. Coding is just typing.

This is a bit crazy to me since I work on code every day. I can certainly say that coding is not just typing. This is one of the reasons why I am an advocate of pair programming. I think that a fair amount of time needs to be spent thinking. All programmers need to be able to type quickly, but the core of what we do is the thought and design that goes into making an application that we can be proud.

Don’t get me wrong I have the highest respect for Jeff Atwood. I think he is one of the greats. I just disagree with the priorities here. I believe that a developer can certainly benefit from typing faster. In fact I wish I did type faster. I certainly don’t hunt and peck. I’ve typed without looking at the keys since I was a kid. I can touch-type the “correct” way, but I have my own style that has worked for me since i was a kid.

Most of the development I do these days is pair programming. An Extreme Programming technique I am sure most of you have at least heard of. This technique is an excellent one that I believe produces better software. Why? Well for one because it lets developers spend more time thinking and less time typing. Both guys are thinking, but about different things. One developer has the keyboard at any given time and keeps in his head the path he is on. (This guy is concerned with typing speed.) He types along the path thinking about the code he is currently writing not the structure of the app, but the code he is typing right now. For a short time his typing speed matters.

The programmer in the pair who is not actively typing is spending all of his time thinking. He keeps in his head the path that the typist is taking, not concerned with the syntax of the programming language. That is the other guy thinking about the language syntax. The one sitting back without the keyboard is the guide. He must make sure that the pair stays on the right path using the most efficient route to success.

By spending time thinking the pair is able to take the smarter path to their goal. Rather than brute-force typing speed we use intelligence of our development team to ensure successful work. This isn’t to say that we shouldn’t type very very fast, because typing fast sure does help us be better developers. However, more important than our typing speed is our thinking speed.

If you’re considering your typing speed to be more important than your thinking speed then I am concerned to see how you’ve structured your code in such a way that you need to type very fast. I find that well structured code requires a lot less typing and a lot more thinking.

If you pause and consider for a minute who are the most revered of developers in the world. Do they type fast? I bet most of them do. Is that why we revere them? No probably not. The greatest of people who code are some of the greatest minds in our industry. They are not the greatest typists in our industry. If you could type 200 WPM do you really think your code would be that much better? I doubt a developer could get more than a 10 or 15 percent increase in efficiency even typing that fast. But if you could think twice as fast I am sure you would see a much larger increase in how efficiently you wrote code.

Good luck with either endeavor, but don’t tell me I’m a typist. I am a thinker first and a typist second, and I refuse to let anyone tell me otherwise. Just because someone can type and knows a programming language does not mean that they can create software of any value.

Productive Typing

In software development it is very important that you type quickly. Now some people are going to be thinking that simple words/minute is important. I agree that it is important to be able to type quickly in general while programming. There are other aspects to this as well. Now consider if you have two programmers and one types twice as fast as the other. Which one is more valuable to the company? So I might have oversimplified this, but I would assume most people who go and read blogs are probably trying to improve their skills as a developer and if you're not considering your programming (typing) speed then you're not considering enough.

As a said moments ago, I am not going to talk words per minute. That isn't always relevant since we're not always typing words. Ours are a lot of the same words as well as a lot of symbols. It isn't normal typing. What I am going to say is that developers need to be taking advantage of keyboard shortcuts and snippets; from the standard ones which work in many applications down to Visual Studio specific shortcuts. A lot of developers use add-ins like CodeRush and Resharper to increase their development speed.

Program Agnostic Shortcuts

Starting simply, I will talk about one of the simplest tricks which will help you everywhere. Use your Home and End keys religiously. They will help you tremendously getting you to different points on a line very quickly. This is a simple one that everyone can remember. The extra trick to know here is that you can hold the Ctrl key and it will jump you to the top or bottom of the page.

So I've just mentioned the Ctrl key I will say that it is the most useful key for shortcutting. I'll now go on a rant of the non-VS specific tricks in can help you with.

Everyone should know copy (Ctrl + c), cut (Ctrl + x), and paste (Ctrl + v) There are plenty of other ones dealing with that key that are also very simple. I can't spend the time talking about all of those. Some of the lesser known ones are also important. For example. Everyone knows that you can use the arrow keys to move the cursor right, left, up, and down. If you combine the left-right movement with Ctrl you will notice that the cursor jumps "words". What consists of a word is interpreted differently depending on the application, but try it out in them and you'll see how useful it is. It will save you a lot of time.

Combine this with the shift key for Ctrl +  Shift + [Direction] and you'll be able to select these words very quickly. This is useful for replacing and changing test or simple copying a variable name. Whatever you've got to do. When you're deleting, don't waste time with it. Combing Delete and Backspace with Ctrl will let you delete "words" very quickly.

Visual Studio Specific Shortcuts

I certainly can't cover all of the shortcuts here, but there are a lot of them. For example if you need to make an auto-property all you need to do is be in the context of a class and type "prop" and then hit Tab. You will get a snippet for your property. If you need a for loop you better not waste time writing it. Most for loops are the same, so just type "for" and hit tab. These are all of your snippets and you can customize and create your own. This is easy and there are tools for editing snippets.

You should also look into the different refactorings that Visual Studio is able to do. Right click and choose Refactor from the context menu and you will see a bunch of options available to you.

Also the most powerful shortcut specific to Visual Studio is Ctrl + . which is context sensitive. For example if you change a name pressing that afterward will allow you to do a rename. There are a lot of other context specific options such as including using statements at the top of the file after adding an type which requires one.

Other Tools

If you're really looking to speed up you should look at some of the third party add-ins to visual studio. Resharper and CodeRush are a couple of the popular commercial products. I currently use Resharper, but I've also lost a coding competition to someone using CodeRush. They're great and integrate a lot of what you need. These tools also come with keyboard mapping files which you can print and have a reference of the shortcuts to speed the learning process.

Resharper for example has a lot of shortcuts for navigating. Ctrl + n lets you search for different types and jump directly to them. Ctrl + Shift +  n lets you jump to files. The searching is fairly smart. The tool also adjusts your intellisense so that it pays attention to campital letters. For example if I were going to type "SuperSpecialStaticClass" I could type "SSSC" and that would be the top of my intellisense. If there were a class named "SlightlySpecialStaticClass" I might have to type "SuSSC" or just go down to the next choice in intellisense.

Rather than spend much more time talking about third party tools I will just say that there are a lot of them out there. They're not very expensive and they will make your time spent be more productive.

Make sure you stay up to date on all of the tools and shortcuts available to you.