The Bird Is The Word
No Pain, No Gain? Part 2 : Tools
Dec 22nd
Some developers are elite, they only code in notepad. I on the other hand don’t fall into that category; I love my tools! This post is to recognize the importance of productivity tools and realizing the pain of living without them. A good carpenter could build your house with just a hammer and a handsaw, but we all know that is a completely insane undertaking. Approaching a development project is the same. Just like any other professional, developers should hone their tools.
The Tragedy
There are developers out there only using the basic Visual Studio IDE and what Microsoft provides to them out of the box. Although these developers are creating applications, they are probably feeling the pain in two places. You can code yourself into a corner when developing using drag and drop development. I am not going to say it is evil, because drag and drop certainly has a place, but it is intoxicating. Drag, Drag, Drag, Done! You’ve just created a application, but what happens when you need to step outside of the box of the visual studio designer? Many developers freeze and panic at this point, because there is no feature in their Visual Studio toolbox for that! The other problem with drag and drop, is that developers can get into brain-dead development. Like I said, it is intoxicating to drag a new feature onto your application, but does it really need to be there? Now I am picking on drag and drop, but there is another bigger tragedy. The tragedy is that these developers don’t explore the larger ecosystem of .NET. There is cool stuff happening outside of the realm of MSDN and Microsoft guidance.
The other issue I see is that many professional developers don’t have a proper development environment. What do I mean by development environment? To me there are minimal standards for a development environment: Source Control, Local Database Engine, External Text Editor, and Reflector. That’s it for a minimal productive development environment, if you are missing any of those then you are doing yourself an injustice.
The Remedy
So you are missing some of the things I mentioned above, but don’t fret I will give you a couple of tools that can fill those places and explain how they can ease your development life.
Reflector
USE THIS! You will be better for having done so. It disassembles any .Net assembly and shows you the code inside. I have progressed my skills exponentially by just reading other peoples code. At this point in my career I would say I read more code than I write. When you are scratching your head about why a call into a third party assembly is exploding, you can use reflector to see if the problem is yours or the third party.
Source Control
I personally have used Visual Source Safe, Team Foundation Server, CVN, and SVN. I currently love SVN because it allows me the facility to host a repository locally or use many of the FREE Subversion providers on the internet. I also have great Visual Studio integration with the free add-in Ankh-SVN. I’ve included the links to some SVN providers along with the link to Ankh-SVN below. Now you have no excuse to back up your tireless efforts in coding.
- Unfuddle – SVN Provider
- BeanStalk – SVN Provider
- Codeplex – TFS Provider (Open Source Only)
- AnkhSVN – Open Source Visual Studio Plugin
You’ll thank me when your machine blows up and you still have your code safely on the net. Your Welcome!
Database Engine
This isn’t so much an issue until development teams make it an issue. I’ve been part of development environments where there was one database that everyone developed against *cough* Oracle. What a freaking nightmare. Oracle released a developer version of their database, but the damage was already done. Developers yelling “You changed my data!” at each other, on the verge of fist fights. So as a rule of thumb, every developer should have a local instance of the database in their environment. If your database is “too complex” for that then you probably have bigger problems.
Use the appropriate engines for your project : SQL Server, Oracle, MySQL,, or SQLite.
External Text Editor
“I already have Visual Studio, who needs this?” Visual Studio is slow to load, especially with all those plug-ins (check out my load screen!). Visual Studio is also overkill when all you need to do is change a configuration setting or look at a text file. Waiting for Visual Studio can seriously hamper your groove, and sometimes you just don’t have that luxury. In addition, sometimes your IDE is not available because your are on another machine. I personally like Notepad2. It is quick and it is portable. It also gives you nice syntax highlighting for XML and HTML.
The Extras
Now what I mentioned above is just a minimum, but the extra tools make things better. Let’s look them over.
GhostDoc
I’d swear there was someone reading my code. This tool basically documents your code with a click. You need this if you do a lot of documentation in your code. It will literally save you thousands of commenting keystrokes.
ReSharper
A productivity tool like no other. My previous post explains it all. It is the difference between coding like the tortoise or the hare.
ORM – Object Relational Mappers
SQL is a powerful language, but I hate writing repetitive CRUD statements. An Object Relational Mapper is the way to go when designing a system. You can save hundreds of man hours not writing CRUD code and getting to what really matters. A nice introduction to Object Relational Mapping is Linq2SQL, check it out if you haven’t already.
Enterprise Library
Enterprise Library has been around for a long time and I love it. It is a set of proven industry practices packaged up for you nice and neatly. Don’t reinvent the wheel when you have a Ferrari waiting to pick you up.
In Summary
Tools are awesome, it is one of the greatest advantages we have over other development communities. You should also never get too comfortable with a tool set, because there is always something coming out that could serve you better. Tools are meant to help you do the job, they aren’t the job itself. If a tool doesn’t serve you well, then you should just avoid it and find something that works.
No Pain, No Gain? Part 1: Bugs
Dec 15th
I recently listened to Jeremy Miller in the Alt.Net podcast, and I also watched the latest in the NHibernate series from TekPub. The common thread I see between both these things is the act of achievement in your own development life. Jeremy Miller talked about the state of Alt.Net and how he and others can further the cause of the movement. The main message I got was, get your house in order. Knowing who you are and what you do can go a long way in reducing the pain of development.
The TekPub series talks about NHibernate and integrating it into Rob Conery’s Kona project, but Oren Eine said something very interesting. NHibernate is a tool to keep you from doing the grunt work associated with a database. Which is exactly why I purchased the NHibernate series, I want to reduce the amount of time spent grunt working and optimize the time spent adding value.
This series of posts will be as much introspective as it is informative. I will look at things that cause me pain in my day to day development, and also explore methods to alleviate the pain (short of morphine shots).
Let’s start with the biggest area of pain, Bugs.
Bugs
No software developer likes to release code that has bugs in it, but bugs are an inevitable pain every developer will have to deal with. I personally have had my fair share of bugs, but I have always been able to resolve them quickly and effectively. The pain with dealing with bugs can come from two places: the act of trying to preemptively stop them, or the act of reacting.
Stopping Bugs
If you are anal about the code you write, then you probably employ some kind of testing methodology: Test Driven Development, Behavior Driven Development, Integration Testing. All These methods make sure your code works. The pain with using these methodologies is that they require a substantial amount of effort to implement. They require understanding and a time investment that some developers just don’t want to put in. I can’t say I blame anyone for not adopting a testing methodology, it takes discipline and dedication.
There are several test generating tools out there, but few really make the process any less painless. You usually are trading one set of pros and cons for another. The trick here is to build a system of developing tests regardless of tools you use. A system that is smaller in complexity is ideal. Test Driven Development has Red Green Development; a process where you get tests to fail then pass. A small but effective system of writing tests. A solid system can help bake practices in and make you more disciplined.
After understanding why I should write tests, I found that bugs in my code are melting away. It’s hard to make a test pass when all your assumptions are correct but the code isn’t. So am I saying that everyone should adopt a testing methodology? No I’m not, but I do recommend it to those developers who don’t like dealing with bugs later because it can substantially reduce those incidents.
So you’ve spent the time to write tests, but bugs still creep into your code. Time to panic! Aaaaah!
Fixing Bugs
I’ve seen this one too often. A bug is found and everyone goes into fire-drill mode. Managers hovering, programmers sweating, IT guys pushing continual updates. It is like watching a slow motion crash test. The problem usually get’s fixed, but not the best way. In addition, the fix usually introduces more bugs.
The solution here is to understand what is happening. Far too often, companies feel that panic mode is ok but it psychologically drains everyone involved. This can bring morale down and breed resentment amongst groups. Why didn’t the testers catch that major bug? How could the programmers have been so stupid? Why are the managers making me push a solution every 5 minutes? What happened to the order of things?
So how do you reduce this pain. Well I’ve experimented with a few options and found that sandboxing is the best course of action. A sandbox environment that is exactly like your production environment. This might seem obvious but the number one sin that most people commit is, they don’t respect the concept of those environment. A sandbox should be your first and only place you push code. Once you are happy, copy that exact environment over to production. There should never be any code directly pushed to production. Respect the structure you setup and it will help you, don’t respect it and it will come back to haunt you.
Beta environments are also a good way to reduce the pressure of critical bugs. Many application have employed this method with success. Create a clone of your web application/application that is strictly Beta. There is an implied agreement between you and your users that there are bugs and the experience might not be ideal. That way you won’t be surprised when a critical bug occurs, also your clients will hopefully understand why the application broke.
Conclusion
Bugs are a part of our development life. They are present and they will always be there. The best thing we can do is take an approach that makes it less painful in our development lives. Some developers are more comfortable writing tests to preemptively stomp bugs, while others thrive in the panicked environment of critical bugs. I personally feel that I don’t want to let bugs get out the door, so I test everything with a three pronged approach. Unit Testing, Integration Testing, and Quality Assurance.