Thursday, February 22, 2007
Moving Out Sale! Everything must go!
Jokes about the one guy who accidently stumbled in here aside I have moved to a new blog on WordPress after a recommendation from a Wise Man.
Wednesday, February 21, 2007
NDepends 2.0 and Managing Change
Scott Hanselman has posted a really interesting article on NDepends 2.0.
I think the main thing that actually interests me about this tool is the ability to find the really bad edge cases. I'm of school of thought that says our primary job as developers is to deliver business value. One of the things I've been guilty of within the last year is the mistaken belief that it is better to throw out working code then to properly refactor it (in my defense I had not yet read the Refactoring book.. or anything by Martin Fowler at this point). I now realize that instead it makes more sense to refactor things in pieces.
Of course this understanding is just the first step. At some point we have to decide what to actually refactor. There are a few ways to drive our refactoring. The most obvious is new functionality. Whenever you enter an area you should leave it better then when you arrived. Even if all you do is take a minute to clean up a method at least you've accomplished something. Next in line comes bug fixes. If you're fixing a bug you should be improving the area (after you added a Unit Test that shows the bug).
But you may (or so it's been rumored) get to a point where you have a few spare moments and no new functionality to add or bugs to fix. It's at this moment that I think NDepends will really have value for me. Because now I can start using its functionality to find the code that is much too complex or components that are in the "Zone of Pain". And I can take some time to improve things piece by piece.
I also gain the ability to get a higher level view of the interdependencies that may not be obvious at first. With this knowledge I can decide whether I want to start small with something that isn't going to cause a potential cascading effect, or at least be forwarned about what I'm getting myself into if I decide to go after something heavier. Knowledge is power after all.
I think the main thing that actually interests me about this tool is the ability to find the really bad edge cases. I'm of school of thought that says our primary job as developers is to deliver business value. One of the things I've been guilty of within the last year is the mistaken belief that it is better to throw out working code then to properly refactor it (in my defense I had not yet read the Refactoring book.. or anything by Martin Fowler at this point). I now realize that instead it makes more sense to refactor things in pieces.
Of course this understanding is just the first step. At some point we have to decide what to actually refactor. There are a few ways to drive our refactoring. The most obvious is new functionality. Whenever you enter an area you should leave it better then when you arrived. Even if all you do is take a minute to clean up a method at least you've accomplished something. Next in line comes bug fixes. If you're fixing a bug you should be improving the area (after you added a Unit Test that shows the bug).
But you may (or so it's been rumored) get to a point where you have a few spare moments and no new functionality to add or bugs to fix. It's at this moment that I think NDepends will really have value for me. Because now I can start using its functionality to find the code that is much too complex or components that are in the "Zone of Pain". And I can take some time to improve things piece by piece.
I also gain the ability to get a higher level view of the interdependencies that may not be obvious at first. With this knowledge I can decide whether I want to start small with something that isn't going to cause a potential cascading effect, or at least be forwarned about what I'm getting myself into if I decide to go after something heavier. Knowledge is power after all.
Tuesday, February 20, 2007
OO in an ASP.Net World..
Raymond Lewallen is trying to collect information regarding the usage of MVP in an ASP.Net world. I'm definitely looking forward to seeing where this takes him. As a windows developer I've always wondered how you bring concepts like OO and now TDD to ASP.Net. I've tried looking around for examples that show these concepts and there seems to be a huge blank spot information wise. It seems like 99% of ASP.Net development is being done using procedural code.
One of the arguments I've heard against bringing OO into the ASP.net world is the "cost" of creating an object. Not in terms of the development time but in terms of actual performance. My view is that creating an object is creating an object and I don't know of a single application that doesn't create at least a string. But the question does need to be answered. Does proper OO code cause performance issues in ASP.Net? I'm not at the point where I can answer this question but maybe someone out there can.
One of the arguments I've heard against bringing OO into the ASP.net world is the "cost" of creating an object. Not in terms of the development time but in terms of actual performance. My view is that creating an object is creating an object and I don't know of a single application that doesn't create at least a string. But the question does need to be answered. Does proper OO code cause performance issues in ASP.Net? I'm not at the point where I can answer this question but maybe someone out there can.
Adding VS 2005 solution file to the New menu
If you're going to start something you should start it right, and that especially applies to a software development project. Depending on the length of your project you may have to live with things for years. One of the things I've really started to get attached to is the concept of working IDE free (where it makes sense). Which isn't to say that I'm going to be coding in Notepad++ any time soon, but it does mean I'm going to setup my project outside of the IDE. Now if you haven't read Mike Robert's article entitled How To Setup a .Net Development Tree I definitely recommend starting there. But if you have read it one of the first things you are going to need to do after creating your folders is create the Visual Studio solution file. Now Mike recommends creating it using the IDE and moving it but personally I think it'd be much nicer if we could just create it from the filesystem. Well it turns out you can and it's not actually that difficult as I found out from Jean-Paul Boodhoo during his amazing week long developer course.
So our end goal is to add the ability to create a new Visual Studio Solution file under the New right click option in Explorer. The first step is to create an actual bare bones Visual Studio Solution File. So to start create a file called Visual Studio Solutions.sln on your file system. Assuming you are using Visual Studio 2005 you will want this file to have the following content:
The next step is to create a registry file to import this new type. I called mine vss.reg but you can name it whatever you want as long as it ends with the reg extension. The contents of this file (assuming Windows XP) are:
The next step is to copy the skeleton solution file you created into the C:\Windows\ShellNew directory (note that you may have to create the ShellNew directory manually). After that is complete all you should have to do now is run the reg file you created. You should now be able to right click in Explorer and see Visual Studio Solution under your right click -> New menu (note that I've seen it where someone had to bring up the menu two times the first time to get it to show)
So our end goal is to add the ability to create a new Visual Studio Solution file under the New right click option in Explorer. The first step is to create an actual bare bones Visual Studio Solution File. So to start create a file called Visual Studio Solutions.sln on your file system. Assuming you are using Visual Studio 2005 you will want this file to have the following content:
Microsoft Visual Studio Solution File, Format Version 9.00
# Visual Studio 2005
EndProject
Global
GlobalSection(SolutionProperties) = preSolution
HideSolutionNode = FALSE
EndGlobalSection
EndGlobal
The next step is to create a registry file to import this new type. I called mine vss.reg but you can name it whatever you want as long as it ends with the reg extension. The contents of this file (assuming Windows XP) are:
Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\.sln\ShellNew]
"FileName"="Visual Studio Solution.sln"
The next step is to copy the skeleton solution file you created into the C:\Windows\ShellNew directory (note that you may have to create the ShellNew directory manually). After that is complete all you should have to do now is run the reg file you created. You should now be able to right click in Explorer and see Visual Studio Solution under your right click -> New menu (note that I've seen it where someone had to bring up the menu two times the first time to get it to show)
Monday, February 19, 2007
Finding Employees
One of the biggest problems I've seen in our industry is finding employees. Or as I like to put it "finding people who know how to get stuff done that you can be proud of". While there are definitely quite a few people "developing software" quite a few of them.. hmm.. how to put it nicely... lets just say I'm glad their not on my project team :) So how do you go about dealing with this?
There are three solutions I can see to this issue.
The first is the easiest and the most damaging. Ignore the problem. Hire whoever you can and let them code the way they have been. If they're the kind of person who learns new things on their own time then great. But if not don't worry about providing any training. Obviously I am strongly against this as you end up having buggy hard to maintain software.
The second is the hardest and it seems like every company that tries it ends up losing their way at some point. Hire only the best. The problem of course being that there is a very limited pool of "the best" and they pretty much have choice of jobs. So at some point no matter how good your environment is you're going to run out of talent. At this point you can either go the Joel route and hire globally or you give up and fall into solution #1.
The third is the hardest for a business to accept. Hire a few of the best to help train everyone else you hire to be better then they were. The reason that this is such a problem for businesses is because of the perceived and real risk involved.
The first risk which we'll call "Nobody to get work done" is IMHO only a perceived risk. There is definitely a cost involved in training your employees but the gain in productivity over the long run more then pays for the cost. I would rather work with a team of 5 who understand OO/DDD/TDD/Agile then a team of 20 guys who picked up VB.Net in their spare time. And nobody said that you had to have everyone fully trained up before they start working. For most people a few weeks of initial training followed by pairing is going to result in huge advances in skills. And before you know it they're training your new guy. Of course this assumes you hire the right people.. which is risk #2.
"Hiring the wrong people" is definitely a big risk. If you are going to be spending so many resources training someone you want to be sure they are a good fit for your team. This is also a hard risk to avoid because it's a hard thing to avoid. You want someone who fits well with your team and who is good at learning new things quickly. This is a lot harder to test for then knowing a specific language or technology. There are plenty of good resources out there on hiring people so spend some time and invest in reading them. Come up with some real questions to ask, find out what they learnt last. And make sure you bring the person in for a day to let them see your process. After all you don't want to hire someone who after a week working for you realizes he made a huge mistake and he hates it. Oh and just to cover your butt make sure you implement a 3 month review process. And don't be afraid to let people go at 3 months if things just aren't going to work. Though it is a good thing if you are honest with the person as soon as you see a problem. You can't expect someone to remedy a problem they may not realize exists.
The other big risk is people leaving. It's not much fun to spend time and resources training someone only to have them leave. My only advice for this is to get over it. People move on. Change is inevitable. Even in a utopian environment things happen and people need to leave for other pastures. All you can do is make your employees as happy as possible and let things work themselves out. The good news is that your employee is most likely going to be a cheerleader for your company if they had a good experience. One of the things I've learnt is that the developer community is alot smaller then we sometimes imagine with our world wide reach. If I want to know about any company in the city it wouldn't take me long to get a few opinions about them (I actually decided against working for an unnamed company specifically because of this).
Of course all this is just theory. So if you've actually seen it implemented or decide to try it yourself let me know how it goes/went ;)
Shane
There are three solutions I can see to this issue.
The first is the easiest and the most damaging. Ignore the problem. Hire whoever you can and let them code the way they have been. If they're the kind of person who learns new things on their own time then great. But if not don't worry about providing any training. Obviously I am strongly against this as you end up having buggy hard to maintain software.
The second is the hardest and it seems like every company that tries it ends up losing their way at some point. Hire only the best. The problem of course being that there is a very limited pool of "the best" and they pretty much have choice of jobs. So at some point no matter how good your environment is you're going to run out of talent. At this point you can either go the Joel route and hire globally or you give up and fall into solution #1.
The third is the hardest for a business to accept. Hire a few of the best to help train everyone else you hire to be better then they were. The reason that this is such a problem for businesses is because of the perceived and real risk involved.
The first risk which we'll call "Nobody to get work done" is IMHO only a perceived risk. There is definitely a cost involved in training your employees but the gain in productivity over the long run more then pays for the cost. I would rather work with a team of 5 who understand OO/DDD/TDD/Agile then a team of 20 guys who picked up VB.Net in their spare time. And nobody said that you had to have everyone fully trained up before they start working. For most people a few weeks of initial training followed by pairing is going to result in huge advances in skills. And before you know it they're training your new guy. Of course this assumes you hire the right people.. which is risk #2.
"Hiring the wrong people" is definitely a big risk. If you are going to be spending so many resources training someone you want to be sure they are a good fit for your team. This is also a hard risk to avoid because it's a hard thing to avoid. You want someone who fits well with your team and who is good at learning new things quickly. This is a lot harder to test for then knowing a specific language or technology. There are plenty of good resources out there on hiring people so spend some time and invest in reading them. Come up with some real questions to ask, find out what they learnt last. And make sure you bring the person in for a day to let them see your process. After all you don't want to hire someone who after a week working for you realizes he made a huge mistake and he hates it. Oh and just to cover your butt make sure you implement a 3 month review process. And don't be afraid to let people go at 3 months if things just aren't going to work. Though it is a good thing if you are honest with the person as soon as you see a problem. You can't expect someone to remedy a problem they may not realize exists.
The other big risk is people leaving. It's not much fun to spend time and resources training someone only to have them leave. My only advice for this is to get over it. People move on. Change is inevitable. Even in a utopian environment things happen and people need to leave for other pastures. All you can do is make your employees as happy as possible and let things work themselves out. The good news is that your employee is most likely going to be a cheerleader for your company if they had a good experience. One of the things I've learnt is that the developer community is alot smaller then we sometimes imagine with our world wide reach. If I want to know about any company in the city it wouldn't take me long to get a few opinions about them (I actually decided against working for an unnamed company specifically because of this).
Of course all this is just theory. So if you've actually seen it implemented or decide to try it yourself let me know how it goes/went ;)
Shane
Customer Service
Say what you want about Joel but sometimes the guy can knock one out of the park and his latest article on customer service is such a beast.
I've personally worked as a developer for a company that had pretty much the same policies as Joel discusses, and in that time I don't think I ever once had to work with a pissed off customer. I actually had a ton of customers who were amazed that they received such good customer service, and I know for a fact it resulted in more then a few sales. Part of the magic I think is making your customer feel like you and your company are treating their issue like it's the most important issue in the world. Even if at the end of the day you can't come up with a perfect solution they'll still remember the effort you put in.
Another nice bonus that Joel doesn't mention is the simple fact that in our industry nobody stays still. People are moving constantly from company to company and if they have a positive view of your company it's alot more likely they'll recommend you to their new employeers.
I've personally worked as a developer for a company that had pretty much the same policies as Joel discusses, and in that time I don't think I ever once had to work with a pissed off customer. I actually had a ton of customers who were amazed that they received such good customer service, and I know for a fact it resulted in more then a few sales. Part of the magic I think is making your customer feel like you and your company are treating their issue like it's the most important issue in the world. Even if at the end of the day you can't come up with a perfect solution they'll still remember the effort you put in.
Another nice bonus that Joel doesn't mention is the simple fact that in our industry nobody stays still. People are moving constantly from company to company and if they have a positive view of your company it's alot more likely they'll recommend you to their new employeers.
Thursday, February 08, 2007
Response to an Otaku
In a recent posting Otaku, Cedrik comments on the "death" of debugging in the world of TDD. I tried making the following post on his blog but for some reason his comment system wouldn't accept it (did I miss a harsh word or a viagra sale attempt in it?). So here it is instead:
I can't come anywhere near Erik in diplomacy and politeness so I'm just going to say that I agree completely with him. If you feel most comfortable running your code every time in a debugger first, then by all means do so. But there is no need to get upset because those around you are feeling more comfortable using their debuggers less.
One thing I will point out is that personally my tests are so specific and simple that it usually takes about 2 seconds of looking at one to verify it is what I want. Of course there are points where I still end up using the debugger. I do find that a large percentage of that time is with code that hasn't (inherited code) been switched (yet) to testable code. While I of course have to start up the debugger in my tests on the rare occasion it is just that, rare.
I can't come anywhere near Erik in diplomacy and politeness so I'm just going to say that I agree completely with him. If you feel most comfortable running your code every time in a debugger first, then by all means do so. But there is no need to get upset because those around you are feeling more comfortable using their debuggers less.
One thing I will point out is that personally my tests are so specific and simple that it usually takes about 2 seconds of looking at one to verify it is what I want. Of course there are points where I still end up using the debugger. I do find that a large percentage of that time is with code that hasn't (inherited code) been switched (yet) to testable code. While I of course have to start up the debugger in my tests on the rare occasion it is just that, rare.
Wednesday, January 03, 2007
First... Err.. Second Post of the New Year
Well it's been awhile since I wrote my last blog entry. I thought I'd throw up a quick post on the state of the union as it was.
- I could not survive without Resharper 2.5. I can now code without having a mouse anywhere near me and it's so much faster.
- I've been doing Domain Driven Design ever since I learnt about OO from my good friend Kris. I just recently found out that was the name for it.
- I've learnt more in the last 6 months then in the last 6 years. While I'm nowhere near the level I'd like to be at, I can happily say I am much better at what I do then I was this time last year.
- The Refactoring book by Martin Fowler has changed the way I develop software. I am constantly looking at my code.
- I still have a ton of stuff to learn...
5 Things Eh?
So I've been dragged into the 5 things blog game by Mr. David Woods
1. I'm a huge fan of zombie movies and books. I just got World War Z for Christmas and I had it finished in 2 days.
2. I prefer being cold to being hot. That's reason #1 you'll never get me to spend more then a week in Florida.
3. My first job as a software developer was working with Visual Basic 6.0. I did that for 6 years and now snuggle up to a C# compiler at night.
4. The last two vehicles I've owned were both new and both were written off within a year (neither was at fault thank you very much!)
5. I once sneezed so hard that I twisted a rib.. or so says the doctor.
As for the 5 people I get to tag.. well it seems most of the bloggers I read have already partaken in the game.. I still have a few up my sleeve to tag..
Sahil Malik
Roy Osherove (Congrats on the new baby boy)
Rob Caron
Brad Wilson
Brian Keller
1. I'm a huge fan of zombie movies and books. I just got World War Z for Christmas and I had it finished in 2 days.
2. I prefer being cold to being hot. That's reason #1 you'll never get me to spend more then a week in Florida.
3. My first job as a software developer was working with Visual Basic 6.0. I did that for 6 years and now snuggle up to a C# compiler at night.
4. The last two vehicles I've owned were both new and both were written off within a year (neither was at fault thank you very much!)
5. I once sneezed so hard that I twisted a rib.. or so says the doctor.
As for the 5 people I get to tag.. well it seems most of the bloggers I read have already partaken in the game.. I still have a few up my sleeve to tag..
Sahil Malik
Roy Osherove (Congrats on the new baby boy)
Rob Caron
Brad Wilson
Brian Keller
Monday, December 11, 2006
Resharper 2.5 EAP Update
Well I've been using the Resharper 2.5 EAP for awhile now and I'm quite impressed with how quickly they have brought the quality of the Visual Basic integration up to snuff. Of course they are only doing the read-only functionality but even that subset of functionality is quite a bit. The EAP has quickly become a tool we can't imagine developing without. One small example is how we've set Alt+U to run all unit tests in the solution. The guy I pair with won't admit it but I think he prefers using the Resharper Unit Test stuff over NUnit. Sure the big green circle isn't as big but the integration and ease of use is so nice. We still use TestDriven.Net for running individual tests but we love Resharper for running all the tests.
In terms of a 3rd party tool nothing I've tried comes close to Resharper in terms of how it will affect your productivity. If you didn't try this before because it was only C# you are in luck. So print out that Key Mapping document and get started today. You won't regret it.
In terms of a 3rd party tool nothing I've tried comes close to Resharper in terms of how it will affect your productivity. If you didn't try this before because it was only C# you are in luck. So print out that Key Mapping document and get started today. You won't regret it.
A Daily Build Process...
We spent a large part of Sunday in at work. Our original intention was to implement a daily build process. The easiest method I could see of implementing this was to use CruiseControl.Net. Before we could do that though we needed to add a few remaining projects to the CC.Net process so that everything was CI'ed.
This is the part where our plans for the day start going south...
As we're adding the new projects we realize that our original directory layout was wrong. And then we realize that our actual build scripts require way to much effort to get working for a new project. At this point we can either leave things as they are and just hack together the remaining builds or we can fix things.
Of course if we don't fix things now we'll just have more to fix later...
So we ended up fixing all our scripts and moving things around. Now this is all based on our current level of knowledge about CC.Net so we may have made a few errors in how we set things up, but I think I'm actually quite happy with how it all came together.
Now about that daily build process...
This is the part where our plans for the day start going south...
As we're adding the new projects we realize that our original directory layout was wrong. And then we realize that our actual build scripts require way to much effort to get working for a new project. At this point we can either leave things as they are and just hack together the remaining builds or we can fix things.
Of course if we don't fix things now we'll just have more to fix later...
So we ended up fixing all our scripts and moving things around. Now this is all based on our current level of knowledge about CC.Net so we may have made a few errors in how we set things up, but I think I'm actually quite happy with how it all came together.
Now about that daily build process...
Subscribe to:
Posts (Atom)