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?
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.
So I was using a RadGridView to display some data and I wanted to add a tooltip with more information. Shouldn’t be too difficult. I of course checked through intellisense to see if there were any obviously named properties for setting a tooltip.
I checked on the RadGridView tag for the properties and I also checked the GridViewDataColumn for it. Didn’t come up with anything so I Binged until I found a potential solution. It didn’t really make sense to me and the solution had me doing a lot of what seemed like extra stuff. It was adjusting the tooltip using the styles for the cell. So, then it hit me that I was thinking about this the wrong way. Since I just wanted text and a tooltip why don’t I just add that in?
So I took control of things and I just used a template for the column instead. Here is the quick and easy way to add a tooltip into a RadGridView.
<grid:RadGridView x:Name="RadGridView1" AutoGenerateColumns="False">
<grid:RadGridView.Columns>
<grid:GridViewColumn Header="Person">
<grid:GridViewColumn.CellTemplate>
<DataTemplate>
<TextBlock Text="{Binding NickName}"
ToolTipService.ToolTip="{Binding FullName}"
VerticalAlignment="Center" />
</DataTemplate>
</grid:GridViewColumn.CellTemplate>
</grid:GridViewColumn>
<grid:GridViewDataColumn Header="Place"
DataMemberBinding="{Binding Place}" />
<grid:GridViewDataColumn Header="Thing"
DataMemberBinding="{Binding Thing}" />
</grid:RadGridView.Columns>
</grid:RadGridView>
And there you have a tooltip on the text of a cell in a RadGridView. You can obviously add different content items into the DataTemplate so that you can support more advanced templates. Just throw the tooltip on the root element inside the DataTemplate and you’ll be set.
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.
I’ve been having an interesting conversation with Peter Blum about the different directions in which ASP.NET is currently developing. He has some very interesting points that he is making about this topic. So he asked me if I use dynamic data, which is of course how all of this conversation started. I informed him that most of my exposure to ASP.NET Dynamic Data has just been playing around with it. I really haven’t done any applications using it. (I of course don’t consider little test applications and demos to be real applications.)
I also admitted that I’ve been heavily involved with MVC since the early beta versions of it. I didn’t mention at the time that I also started using AJAX very early on as well. I did a lot with “Atlas” as it was called at the time. His responding comment was quite interesting.
the Insiders are so heavily into MVC that we don’t have enough people who push Microsoft to improve the webforms technology
I really think that he makes a great point here since MVC got here we really don’t hear too many of the prominent voices talking about improvements that can be made to ASP.NET Web Forms. Yes, I know there are those who do not like MVC. I read some of their blogs. Some of their reasons are well thought out and very relevant. What I am seeing less often is people commenting on the things that can make web forms better.
Something I’ve said many times since MVC came around is that it is great for certain circumstances. If you’re in one of them, use MVC. If your task requires Web Forms, then use them. Heck, if you need classic ASP, go for it. Using the right tool for the job is extremely important. Just because you’ve mastered the hammer and the screwdriver doesn’t mean you should use them to dig a hole.
A trend that Peter also noted in our conversation is that Dynamic Data came around and there was a little bit of hype for it, but the hype largely died out. MVC, however, has had continual hype, growth, and attention since its mention. AJAX also had a large amount of support and a great following from MVPs, insiders, and influential people.
The thing with Dynamic Data though is that in concept it is a very cool idea and has the potential to be great. It, like all technology, needs to have feedback from the community. It is up to the developers to push Microsoft into developing the technology in the correct direction. I think this is one of the reasons that Peter has been working so hard on Dynamic Data.
With the early beta versions of ASP.NET MVC some of the “testability” was really not there. People trying to use it had to use workarounds to get things to work. For example controllers used to call a method to show the view. They didn’t return ActionResults as they do now. The problem is that it was hard to see what was called so you couldn’t really test it. So I created “fake” controllers to do my testing since the controllers were inadequate at the time. Developers using and giving feedback about what needed to change is what made that project a success.
Not sure if we can revitalize the interest in Dynamic Data and get the ball rolling in the right direction for it, but I can say that I’ve heard very little about it lately. So how about it? Willing to try out Dynamic Data and see how it can be made better?
Peter made DES Dynamic Data, which is supposed to enhance a lot of the aspects of ASP.NET Dynamic Data perhaps I’ll try it out and see if it makes Dynamic Data spectacular.