Pragmatic software development is about knowing which tools solve which problems best. For example, test driven development is wonderful for designing a domain layer. Unfortunately, mapping the UI interaction with the domain layer is often painful and done poorly. Using UI Driven Service Layer Development you can more easily decouple the UI layer from the domain layer.
Your team has tested and developed a domain layer. The classes are well designed and contain correct responsibility. You also have mock screens given to you by a UI designer. Your next task is to make the screens work with the existing domain layer. You should begin by creating the UI & service layer, but stub the service layer. Make the entire application "work" with hard coded data returning from the stubs. Patterns and logical groupings will begin to emerge in the stubbed service layer. This approach lends itself to easily refactoring the service layer to an interface that logically fits the UI. Finally, you convert the stubs into real classes that interact with the domain layer.
The finished product is an service layer that the UI can consume without being tied to the domain layer design decisions.
Tuesday, May 24, 2005
Friday, May 13, 2005
Coding standard election
Everyone sees the value in coding standards and agrees that we need coding standards. Unfortunately, the trouble starts when you begin compiling the coding standard list.
I'm very passionate about the perfection of the code I produce. That's not to say that my code is perfect, but I attempt to make it as perfect as I possibly can. Many of my co-workers share this passion. This is part of the reason we are so passionate about coding standards. Unfortunately, we don't always agree on what "perfect" code looks like.
On every project there are wars over "curly braces on their own line", "space before and after an (insert operator, e.g. = or +)", "prefix interfaces with I in C#". In the .NET world Visual Studio helps sort out the problems by auto formatting, but it doesn't address all situations.
Recently, I was pairing and Visual Studio 2005 Beta 2 kept formatting string.Format to String.Format. Stephen Chu noticed and remembered that another version (on another day, when the moon was full or some other reason that VS2005 decided to behave differently) had corrected String.Format to string.Format. He asked if we should have a standard. In general, I believe that standards should be created when necessary, not when possible. So, I responded that "I honestly don't care how VS formats the word 'string', I'm going to read it the same way". I believe that coding standards should be created to increase readability, not beauty.
Some coding standards are required. When starting a new C# project you should always vote no underscore prefix on private fields, camel case for private fields, and prefix all interfaces with "I". Those are obviously my opinions, but they are for clear reasons. Camel case for private fields is descriptive enough that a field is private; therefore, the underscore is unnecessary and redundant. While I actually hate the "I" prefix, Microsoft not only pushes it as a standard, but also follows this standard in the framework. Breaking the standard can cause confusion among developers joining the team. Also, refactoring technologies allow you to easily rename an interface if you change it to a class.
Standards should be significant majority elected. New standards are nominated by an employee and seconded by another before it's put to vote. If a vote takes place, 66% of the team must vote to add it to the coding standard list. Upon addition, a repeal vote will begin and last 7 days. If more than 33% of the team votes to repeal the standard, it will be removed. Once a standard is added and is not removed in the repeal vote it can only be challenged once every 30 days. 34% or greater votes to remove are always successful.
This is a bit of a process, but could be automated and will make coding standard issues easier to mediate.
I'm very passionate about the perfection of the code I produce. That's not to say that my code is perfect, but I attempt to make it as perfect as I possibly can. Many of my co-workers share this passion. This is part of the reason we are so passionate about coding standards. Unfortunately, we don't always agree on what "perfect" code looks like.
On every project there are wars over "curly braces on their own line", "space before and after an (insert operator, e.g. = or +)", "prefix interfaces with I in C#". In the .NET world Visual Studio helps sort out the problems by auto formatting, but it doesn't address all situations.
Recently, I was pairing and Visual Studio 2005 Beta 2 kept formatting string.Format to String.Format. Stephen Chu noticed and remembered that another version (on another day, when the moon was full or some other reason that VS2005 decided to behave differently) had corrected String.Format to string.Format. He asked if we should have a standard. In general, I believe that standards should be created when necessary, not when possible. So, I responded that "I honestly don't care how VS formats the word 'string', I'm going to read it the same way". I believe that coding standards should be created to increase readability, not beauty.
Some coding standards are required. When starting a new C# project you should always vote no underscore prefix on private fields, camel case for private fields, and prefix all interfaces with "I". Those are obviously my opinions, but they are for clear reasons. Camel case for private fields is descriptive enough that a field is private; therefore, the underscore is unnecessary and redundant. While I actually hate the "I" prefix, Microsoft not only pushes it as a standard, but also follows this standard in the framework. Breaking the standard can cause confusion among developers joining the team. Also, refactoring technologies allow you to easily rename an interface if you change it to a class.
Standards should be significant majority elected. New standards are nominated by an employee and seconded by another before it's put to vote. If a vote takes place, 66% of the team must vote to add it to the coding standard list. Upon addition, a repeal vote will begin and last 7 days. If more than 33% of the team votes to repeal the standard, it will be removed. Once a standard is added and is not removed in the repeal vote it can only be challenged once every 30 days. 34% or greater votes to remove are always successful.
This is a bit of a process, but could be automated and will make coding standard issues easier to mediate.
Do you #region?
In C#, how often do you use #region? Lately, I find myself using them only because "I should".
For the most part, I think #region indicates the need for refactoring. Other times, I use #region to hide all my private fields or something similar. Usually, there are so few of these per class that it's unneeded (but it looks nice?). In the end, it's probably more trouble opening and closing them when I need to add new fields.
There are times that a #region makes sense. If you have repeating code, that cannot be refactored, a #region with a short description can be quite nice. See Accessing Private Members in C# for an example. This is rare though, always look for refactoring before settling on a #region. Also, in .NET 1.1 #region is great around generated code. However, in .NET 2.0, with the introduction of partial classes there seems to be less and less need for #region.
For the most part, I think #region indicates the need for refactoring. Other times, I use #region to hide all my private fields or something similar. Usually, there are so few of these per class that it's unneeded (but it looks nice?). In the end, it's probably more trouble opening and closing them when I need to add new fields.
There are times that a #region makes sense. If you have repeating code, that cannot be refactored, a #region with a short description can be quite nice. See Accessing Private Members in C# for an example. This is rare though, always look for refactoring before settling on a #region. Also, in .NET 1.1 #region is great around generated code. However, in .NET 2.0, with the introduction of partial classes there seems to be less and less need for #region.
Wednesday, May 11, 2005
NCover Code Coverage Tool
NCover is a code coverage tool for .NET. Unfortunately, NCover is actually 2 totally different coverage tools that share the same name. Neither one seems to be very mature, and people seem to be split on which one is better. They were designed to produce the same result, a code coverage report. But, they both work in very different ways. I don't think there is any hope for collaboration.
The best solution to the naming conflict I've seen to date is naming one NCover@SF and the other NCover@GDN.
NCover@SF is NCover hosted at SourceForge. This version of NCover uses instrumentation to get coverage results. Copying the original and instrumenting the copy is suggested. It includes functionality to deinstrument your code after the tests have been run, but in practice you'll likely delete all temporary code after test completion. I've successfully used it on a .NET 1.1 project and a .NET 2.0 project. NCover@SF runs as a NAnt task and is fairly easy to set up. The documentation is minimal and even wrong in 1 place, and the project website is not the best. However, the simplicity of using the tool makes up for these drawbacks.
NCover@GDN is NCover hosted at NCover.org; however, in the past this version of NCover was hosted at GotDotNet, thus the name. NCover@GDN uses the .NET Framework profiler API to monitor an application's execution. When a method is loaded by the CLR, NCover@GDN retrieves the IL and replaces it with instrumented IL code. NCover does not change your original IL code, it simply inserts new code to update a visit counter at each sequence point. After the .NET process shuts down, the profiler outputs statistics to a file in the current directory. I've not used NCover@GDN, but some of my co-workers are successfully using it. I've been told that it only works for .NET 1.1 and not .NET 2.0.
The best solution to the naming conflict I've seen to date is naming one NCover@SF and the other NCover@GDN.
NCover@SF is NCover hosted at SourceForge. This version of NCover uses instrumentation to get coverage results. Copying the original and instrumenting the copy is suggested. It includes functionality to deinstrument your code after the tests have been run, but in practice you'll likely delete all temporary code after test completion. I've successfully used it on a .NET 1.1 project and a .NET 2.0 project. NCover@SF runs as a NAnt task and is fairly easy to set up. The documentation is minimal and even wrong in 1 place, and the project website is not the best. However, the simplicity of using the tool makes up for these drawbacks.
NCover@GDN is NCover hosted at NCover.org; however, in the past this version of NCover was hosted at GotDotNet, thus the name. NCover@GDN uses the .NET Framework profiler API to monitor an application's execution. When a method is loaded by the CLR, NCover@GDN retrieves the IL and replaces it with instrumented IL code. NCover does not change your original IL code, it simply inserts new code to update a visit counter at each sequence point. After the .NET process shuts down, the profiler outputs statistics to a file in the current directory. I've not used NCover@GDN, but some of my co-workers are successfully using it. I've been told that it only works for .NET 1.1 and not .NET 2.0.
Monday, May 09, 2005
www.TextDrive.com
If you are looking for Ruby on Rails web hosting check out TextDrive.
"TextDrive is the right choice for those who use and wish to support free, open-source publishing applications such as Textpattern, WordPress, Instiki and frameworks such as Ruby On Rails."
"We have no photographs of our CEO strutting past server racks, or of women in telephone headsets ready to take your call, but we hope you’ll consider joining us all the same."
beautiful.
"TextDrive is the right choice for those who use and wish to support free, open-source publishing applications such as Textpattern, WordPress, Instiki and frameworks such as Ruby On Rails."
"We have no photographs of our CEO strutting past server racks, or of women in telephone headsets ready to take your call, but we hope you’ll consider joining us all the same."
beautiful.
Sunday, May 08, 2005
Technology vertical
In Software development companies will prevail I stated that I think that in house development is doomed. Building from this argument, I believe that we will see a time where technology is a vertical such as banking or insurance.
Technology is something that every company needs, just like financial services, benefits packages, etc. However, unlike banking or insurance, many companies today still strive to handle all thier technology needs in house.
I believe a much better approach for large corporations would be to purchase technology as a service. Technology companies could handle hosting, custom application development, environment set up, etc. CTO (or CIO) internal positions would still be required, much like a CFO currently is. Additionally, there would be supporting internal positions for the CTO. But, application development, integration, security, etc would be handled by the professionals employed by the technology company.
Some CIOs are already requesting software as a service. The message last week in Santa Clara was Some of you are doomed. No one is surprised by this message. The Standish group is reporting that only 29% of projects were successful in their last study. In the past we've tried contractors and in house development. Then, offshore became the trend. However, based on the current state of things clearly need a new approach.
Technology companies comprised of quality individuals will drive technology success in the future.
Technology is something that every company needs, just like financial services, benefits packages, etc. However, unlike banking or insurance, many companies today still strive to handle all thier technology needs in house.
I believe a much better approach for large corporations would be to purchase technology as a service. Technology companies could handle hosting, custom application development, environment set up, etc. CTO (or CIO) internal positions would still be required, much like a CFO currently is. Additionally, there would be supporting internal positions for the CTO. But, application development, integration, security, etc would be handled by the professionals employed by the technology company.
Some CIOs are already requesting software as a service. The message last week in Santa Clara was Some of you are doomed. No one is surprised by this message. The Standish group is reporting that only 29% of projects were successful in their last study. In the past we've tried contractors and in house development. Then, offshore became the trend. However, based on the current state of things clearly need a new approach.
Technology companies comprised of quality individuals will drive technology success in the future.
Saturday, May 07, 2005
When 1 + 1 != 2
The common belief about pair programming is that you achieve the productivity of 1.5 developers on their own. The problem with this measurement is that the productivity of each developer is unique to that developer. Also, it assumes that the developer is productive at a steady pace for 8 hours a day 5 days a week.
I believe that in rather common situations pair programming can be much more or less productive. And, while 1.5 may be the mean, it's more often much more or less.
Since I joined ThoughtWorks I've noticed increases in my productivity. This is for several reasons, including:
Do you know anyone indifferent about pairing? I don't, it's a love or hate relationship. I think this is largely because of the productivity that is achieved. If you have a successful experience you see how great it is and love it. Obviously, it can also be painful and very unproductive, thus the hate emotion. But, if you don't love pairing, I'd have to ask if you actually love programming.
I believe that in rather common situations pair programming can be much more or less productive. And, while 1.5 may be the mean, it's more often much more or less.
Since I joined ThoughtWorks I've noticed increases in my productivity. This is for several reasons, including:
- Pairing doesn't allow slack time. In the past I often completed tasks ahead of schedule and ended up with extra time. Usually, I filled this time with browsing, emailing, etc. However, pairing forces me to focus and move on to the next task.
- Pairing gives you 2 points of view. The continuous code review provides confidence. There is no better feeling than programming with confidence. Test driven development gives you some confidence; however, it only validates what you test. Pair programming goes above and validates the design from 2 points of view while development is being done. Additionally, 2 points of view limits wasted time. Have you ever had the feeling that what you were doing was wrong and you were going to have to throw away the code? Unfortunately, when I'm not pairing I usually finish, and then look at what I can improve. Then, often, I have to explain the code to someone else to get their point of view. And, in the end I throw most of the code away. However, when I pair, the other developer is following my train of thought and we can stop, visualize the end result, and discuss better options.
- Workstation set up. Have you ever tried to drive on someone else's computer when they used a natural keyboard and you are used to a laptop keyboard? You adapt, but it's annoying. Obviously, productivity will suffer some.
- Motivation. My first pairing partner and I had something in common, lack of motivation. We couldn't get our schedules to match, and we ended up spending much of our time explaining what we had done while the other person was away. Then, when we did pair, we weren't focused and spent much of the time day dreaming. Why pay attention, someone else was doing the work. We were both slackers, but pairing couldn't remedy our slacking if we weren't motivated.
- Speak the language. Nothing is more frustrating than looking to someone for design advice and they are stuck on something syntax related.
Do you know anyone indifferent about pairing? I don't, it's a love or hate relationship. I think this is largely because of the productivity that is achieved. If you have a successful experience you see how great it is and love it. Obviously, it can also be painful and very unproductive, thus the hate emotion. But, if you don't love pairing, I'd have to ask if you actually love programming.
Sunday, May 01, 2005
Technology evolution hides incompetence
New technology is released so often that the failures of the past are quickly hidden by a version n+1 in a new language. Your VB6 app is so horrible you can no longer maintain it? That's ok, rewrite it in .NET. Your .NET app is horrible? Don't worry, the new version of Java will solve your concerns.
It's not the software that is bad, it's the people writing it. Applications shouldn't be rewritten every 2 years, especially since most application development is still done in a waterfall approach and it takes on average a year to produce any production code.
Stop investing in the "latest" software trend and invest in the current product. The first thing you can do is get some very talented help.
Imagine how much you'd save if you actually had a product that ran for 5 to 10 years and you didn't have to employ two dozen developers to make minor changes to it.
It's not the software that is bad, it's the people writing it. Applications shouldn't be rewritten every 2 years, especially since most application development is still done in a waterfall approach and it takes on average a year to produce any production code.
Stop investing in the "latest" software trend and invest in the current product. The first thing you can do is get some very talented help.
Imagine how much you'd save if you actually had a product that ran for 5 to 10 years and you didn't have to employ two dozen developers to make minor changes to it.
Software development companies will prevail
Eventually, software development will be done by software development companies. Some companies already get it, and they hire companies like ThoughtWorks to do development for them. The end result is a better product at a cheaper price.
Other companies that don't get it still do in house development. The problem with in house dev is that everyone involved on the project is overhead. Therefore, corners are cut, roles that are required are not filled, and quality suffers. Often many junior employees are hired because of cost concerns. The result of the cost "savings" is bad code, which costs quite a bit to maintain. Additionally, the turn over rate of the talented developers is higher because there is always a better opportunity around the corner. In the end, technology evolution kills the project and all the failures are swept under the carpet as version 2 is built in the latest technology.
A hybrid approach where a company like ThoughtWorks is brought in to work with the in house team can also work. Then, the maintenence can be done by some of the original developers. Also, the heuristics of the software development company can be transferred to the in house developers.
I've been seeing this trend for several years; however, since technology evolution hides the project failures, in house only companies fail to recognize the problem. The process will be slow, but software development companies will prevail, eventually.
Other companies that don't get it still do in house development. The problem with in house dev is that everyone involved on the project is overhead. Therefore, corners are cut, roles that are required are not filled, and quality suffers. Often many junior employees are hired because of cost concerns. The result of the cost "savings" is bad code, which costs quite a bit to maintain. Additionally, the turn over rate of the talented developers is higher because there is always a better opportunity around the corner. In the end, technology evolution kills the project and all the failures are swept under the carpet as version 2 is built in the latest technology.
A hybrid approach where a company like ThoughtWorks is brought in to work with the in house team can also work. Then, the maintenence can be done by some of the original developers. Also, the heuristics of the software development company can be transferred to the in house developers.
I've been seeing this trend for several years; however, since technology evolution hides the project failures, in house only companies fail to recognize the problem. The process will be slow, but software development companies will prevail, eventually.
Subscribe to:
Posts (Atom)