January 2008 Entries
Ok, so it isn't necessarily the most efficient way to spend your time. It is usually better to buy your tools whenever possible, but it is a great way to learn. Of course I am not talking about recreating Nant or CruiseControl. What I am suggesting would be more in the nature of a test harness for integration testing purposes. These are strategic tools that will pay for themselves as you move from development into production support.
One area where these harnesses come in handy are integration points between systems. This is a notoriously difficult place to debug since you have to re-point servers to developer machines in order to walk through the code. Your test harness is essentially a mock for the integration point. If something is failing and you are able to pick up the message and inject it into the destination.
Many developers end up creating these little applications. We were doing it long before TDD came along. At that point it was close to the only type of testing. Try it out and you will find some interesting things about your system.
I normally only like to post links where I can add value. In this case I think Firebrand's post
stands on its own. Take the time to check out and reflect on his list of quotes from Frank Lloyd Wright.
File this under "take you lessons from all parts of life".
Recently there has been a lot of buzz about a picture of "Bigfoot" on Mars taken by the Spirit rover. As an amateur astronomer and a skeptic this has been humorous and disturbing to watch. You have to wonder how people could actually believe that this might be a life form. We are talking about a planet with very little atmosphere and no magnetic field to protect it from cosmic radiation.
If you take a look at Emily Lakdawalla's blog post you will see what people aren't mentioning about this image. The rock is actually two inches tall and only a few yards from the rover.
So what can we learn from this that we can apply to software development? Look at the whole picture. The perception the individuals have within a project are colored by how much they actually see. Someone who does data entry can give you really good information about how certain screens should work, but they may not have a good corporate picture of where everything fits together. We need to spend time looking at the panoramic as well as the macro.
Another thing we can learn is to understand that people see what they want to see and have their own agendas. Some people may see Bigfoot because it supports some of their other beliefs like the Loch Ness Monster. A manager may want a feature implemented because it will keep their employees busy, but it may not actually be in the best interest of the company as a whole.
So don't take things on face value. Ask as many questions as you can without grinding the project to a halt. Even then, some questions may be important enough to stop the project. If it is in the best interest of the company you have to ask the hard questions.
Managing a software development project is always a risk versus benefit balancing act. It seems that lately the scales have tipped way over to the side of reducing risk rather than supplying benefit.
What do you do when you have a problem with an application but a fix won't be allowed because there is a work around? The benefit needs to be put into terms of savings. Does the solution require regular intervention on the part of a support team or is the user delayed in their work while waiting for the work around to be executed? These are factors that have a cost.
In the end it may still be determined that the cost of a work around is less than the benefit of a new feature or fixing a different problem. Remember though that it is always worth making decision makers aware of the real cost of something not being fixed. This can cause the risk associated to be accepted because the benefit is more clearly stated.
I have posted before about reading other's code. What happens when you need an example to get ideas from or to better understand usage. Let's face it. Documentation of a language doesn't always give you everything you need to know. If you haven't already found it, Krugle is a good place to look for code sample. It is the Google of code files. It has been around for a while but I don't believe that most developers know about it or use it as much as they might benefit. Try it out.
Now you may want to look at code that isn't indexed on Krugle but you have the assembly for it. In this case you will want to download Reflector. This is another way to get hints and tricks from other's code. Of course Reflector is looking at the the compiled code instead of the original source, but you will get the gist of what the developer was doing.
Ok, I'm not actually going to get into the whole global warming debate. I just thought it would be a funny title for a post about a very cold day in the the Chicago suburbs. If you look back a year on this blog you will find a post with a picture of sign saying -4. When I woke up this morning it was at least -7 with a wind chill of -30. Of course a little over a week ago it was +60. As they say around here, "if you don't like the weather, wait five minutes and it will change". Stay warm.
This week has been pretty busy with the promise of it only getting busier, but I am feeling pretty good. What is the reason for this optimistic outlook you might ask? Mainly it is the number of compliments on my work this week. Thankfully it has made me realize that this is something I need to do more often. Nothing makes your life better than lifting up those around you. So let me start by thanking all of you who read my blog and all of you who have contributed constructive comments. While I am at it thanks to the GWB crew for keeping this site up and running. Now it is time to go thank a few more people in person. Later ....
Many new developers (and old developers) feel that reading other people's code is boring if not torture. I suggest that you look at this necessary evil as opportunities to discover treasures. You can learn new techniques by reviewing other's work. You can also learn things that you shouldn't do or remind yourself why you don't code a certain way. Either way you will most likely see code implemented in ways that you wouldn't normally do yourself.
So lets take this discussion beyond just reading the code by eye. Stepping through the code will help you to learn even more. You will see things that you didn't notice by just reading. This is mostly because there are only so many variations that most people (at least normal people) can mentally exercise.
If you want to work on this technique for improving your skill try checking out Scott Hanselman's blog where he posts Weekly Source Code. There are also a couple of people who post in their blogs challenging readers to figure out what is wrong with their code. Give it a try.
The most recent Polymorphic Podcast does not have a lot of technical content, but I found it very interesting all the same. I am sure the most people go through times in their career where they wonder why they doing the job they are. Putting it another way, "what do you want to do when you grow up"? Of course we know that people in IT never grow up, but that is besides the point.
Since this is the beginning of a new year it is a great time to get fired up about goals. Mine for this year include stepping up my architecture skills to the next level and creating more benefit for my company's clients. What are you going to do to invigorate your career?
I am involved in working to get the Chicago chapter of IASA started and would like to find out who what architect are in the Chicago area. Please use the contact page of this blog to send me send me your information. I also encourage you to go to the IASA home page
and register. It will give you access to a growing number of architect resources including a new video
that was just released.