RSS Feed
If you've made it this far, I can tell you that the title is tongue-in-cheek. No throwing things at me or unsubscribing (thus cutting my readership in half).
Over the course of my career, I've seen attempts on various projects to eliminate the need for ongoing developer involvement in system maintenance. The argument goes something like this: If we could just build a flexible business rules engine, we wouldn't have to call the developers every time we need to update our FILL IN THE BLANK.
Don't get me wrong... there is definitely a time and a place for application configurability. It's just that business owners (egged on by developers looking for a good challenge) tend to over-extend the concept. For example, they may foster the creation of a new micro-language for defining pricing rules. Something like:
IF ($PRICE$ > 100) $PRICE$ * .90 --> $PRICE$ ELSE $PRICE$
Given that I personally know both people who read my blog, I know you could implement the parser to apply this business rule. And why not? Now my business owners can be in complete control of their pricing rules! We're not just talking a few canned rules... No, I mean autonomous, unbridled, master-of-your-own-universe power!
But there are a few catches. What happens when my business owner misses a closed parentheses? Well, it's back to the drawing board to write a user-friendly syntax checker (a.k.a. compiler). But then, they forget the symbol for manufacturer cost and complain (which is, of course, $MFG_COST$). Well, it's probably time for documentation (language specification) and macro-builder (IDE). The next complaint you get is "My pricing rules are getting really hard to enhance without messing them up." Well, this time (again because I know who my readers are) you realize you'll need to implement a unit testing framework and educate your business owners on Test Driven Development.
By now, however, the gig is up. You don't know how to implement a unit testing framework for your new language, POOP (Pricing Open Operation Protocol). However, you've now spent 20% of your career developing it, its compiler, it's language specification, and its IDE. You're highly invested - it's no time to abandon POOP now!
You forge on... You begin gathering pricing requirements from your business owner (if only you could just program all day), implementing them, and demonstrating them for acceptance. It's just that you're life is harder than it used to be. You used to have a powerful, expressive language (C#), complete documentation (MSDN), whiz-bang development tools (Visual Studio & Resharper), and unit testing framework (NUnit). Now you've just got POOP.
Thursday, June 16, 2011
Tuesday, August 19, 2008
Tarantino Gets Noticed!
This is my second blog post today - a first for me! I just noticed that Gabriel Schenker did a really nice write up on Tarantino Database Migrations. As with my blogging, I kind of assumed Headspring would be the only user of Tarantino when I open-sourced the project on Google code. It's very flattering to see someone like Gabriel take the time out of his day to document the project.
As Jeffrey Palermo mentioned, we're always looking for contributors. In particular, an Oracle guru that could add Oracle support would be very welcome :). However, if we don't get a contributor, I plan to add Oracle support before the end of the year to support my current project.
Happy Migrating!
NAnt and Setup Projects (*.vdproj)
If you're like me, you're lazy. And last night, while on my couch watching the Olympics, I attempted to do a simple thing - compile a solution containing a setup project (.vdproj) from NAnt. After all, when you're distributing a Windows Forms application to a non-technical audience, it's natural to want an installer to bootstrap to the .NET framework, copy the application to the program files directory, and create an icon on the desktop and start menu. To enhance efficiency through automation, it's also natural to want to build the software on a build server instead of manually on a developer workstation. Let's just say it took longer than a few heats of the 100m butterfly to complete this simple task. Hopefully I can decrease that learning curve for you, my fellow developer.
My first thought was, "I'll use msbuild to compile the solution". It's completely logical, but unfortunately impossible. vdproj files can only be compiled by Visual Studio. After about an hour of scouring the Internet in denial and throwing up in my bathroom, I accepted this *enormous* limitation. Apparently this issue has been known by Microsoft since at least 2004, but they haven't had time to address it. Most likely this time was instead spent pursuing the Microsoft dream. By the way, in the Microsoft dream a non-technical website administrator drags their entire SQL Server database onto the ASP.NET "design surface" and selects the publish option from the build menu.
The next problem that arises is: how do I call Visual Studio from NAnt? What executable and command-line arguments do I use? How do I dynamically determine where Visual Studio is installed? Below is some NAnt code that answers these questions:
<readregistry
property="ide.dir"
key="SOFTWARE\Microsoft\VisualStudio\9.0\InstallDir"
hive="LocalMachine" />
<echo message="IDE Directory is ${ide.dir}" />
<exec
program="devenv.exe"
workingdir="."
basedir="${ide.dir}"
commandline="src\XYZ.sln /Clean"/>
<exec
program="devenv.exe"
workingdir="."
basedir="${ide.dir}"
commandline="src\XYZ.sln /Rebuild Release"/>
Thursday, August 14, 2008
Ready, Set, Panic!!!
I saw a TV commercial recently that reminded me of what it's like for developers learning advanced object-oriented development techniques. The commercial showed a golfer standing in front of a golf ball, club in hand. Before he swings, he thinks about all of the tips his friends have given him about golf:
1. Pretend you're sitting sideways on a horse
2. Pretend your arms are limp spaghetti noodles
3. Pretend you're standing in two feet of water
4. Pretend you're wearing a tractor tire around your waist
He's thinking about so many things that instead of hitting the ball, he releases the club in his backswing and nails his caddy - after all, he forgot to grip the club. I couldn't find the clip on YouTube, but I found something very similar to give you an idea:
http://www.youtube.com/watch?v=svDFoBHzM1A
I had a similar experience when learning to water-ski on one ski. I didn't get on top of the water until I realized the only thing I needed to remember was to push hard with my back foot. That was it - when the boat engine roared, I pushed with my back foot. Viola!
When I began working for Jeffrey Palermo, I struggled to find a common theme to guide my development decision making. The list of rules to follow when writing maintainable, object-oriented software is immense:
1. Don't repeat yourself (DRY)
2. Liskov Substitution Principle (LSP)
3. Single Responsibility Principle (SRP)
4. Scoping
5. Design patterns
6. Loose coupling
7. Strong cohesion
8. Small classes
9. Limited dependence on infrastructure
10. And on, and on
For developers dedicated to excellence (but unfamiliar with advanced OOP), the list above can basically prevent them from ever writing any code. In my case, what will Jeffrey think of the code I commit? How do I *know* I'm not writing the legacy code that will torture my team in the future? Is there a simple rule I could follow (like pushing with my back leg) that I can focus on to be successful?
Fortunately, I found just such a rule to address all of the concerns listed above. It is... drum roll... 100% Unit Test Coverage. Specifically:
1. Unit test every meaningful input combination
2. In Onion Architecture terms, test the behavior of only one domain object or service at a time
3. Test all delegation from one class to another
4. Keep your tests small and readable
Viola!
By testing all delegation logic, you're almost forced to define an interface for each of your services so you can mock them when unit testing the classes that depend on them.
By testing every meaning input combination, you're forced to break up code into small, simple classes. Methods with high cyclomatic complexity will create too many input combintations. A class with 16 input combinations can often be broken up into two classes with four input combinations each. You just cut the number of test cases in half (4 + 4 = 8, 4 * 4 = 16).
By unit testing your classes, you prevent any dependencies on infrastructure. For example, you can't include code like DateTime.Now directly in your classes. Otherwise, you'll need to reset your system clock to produce a predictable unit test result - yuck.
You'll quickly find yourself learning design patterns because design patterns allow you to break large logical structures into small, individually testable classes.
The mistakes you do make will be small and easy to correct. After all, your unit test suite will catch any refactoring mistakes you make.
The next time you're feeling overwhelmed keeping up with the Palermos, Millers, and the like, challenge yourself to achieve 100% Unit Test Coverage. If you're like me, you'll find it rarely leads you astray.
1. Pretend you're sitting sideways on a horse
2. Pretend your arms are limp spaghetti noodles
3. Pretend you're standing in two feet of water
4. Pretend you're wearing a tractor tire around your waist
He's thinking about so many things that instead of hitting the ball, he releases the club in his backswing and nails his caddy - after all, he forgot to grip the club. I couldn't find the clip on YouTube, but I found something very similar to give you an idea:
http://www.youtube.com/watch?v=svDFoBHzM1A
I had a similar experience when learning to water-ski on one ski. I didn't get on top of the water until I realized the only thing I needed to remember was to push hard with my back foot. That was it - when the boat engine roared, I pushed with my back foot. Viola!
When I began working for Jeffrey Palermo, I struggled to find a common theme to guide my development decision making. The list of rules to follow when writing maintainable, object-oriented software is immense:
1. Don't repeat yourself (DRY)
2. Liskov Substitution Principle (LSP)
3. Single Responsibility Principle (SRP)
4. Scoping
5. Design patterns
6. Loose coupling
7. Strong cohesion
8. Small classes
9. Limited dependence on infrastructure
10. And on, and on
For developers dedicated to excellence (but unfamiliar with advanced OOP), the list above can basically prevent them from ever writing any code. In my case, what will Jeffrey think of the code I commit? How do I *know* I'm not writing the legacy code that will torture my team in the future? Is there a simple rule I could follow (like pushing with my back leg) that I can focus on to be successful?
Fortunately, I found just such a rule to address all of the concerns listed above. It is... drum roll... 100% Unit Test Coverage. Specifically:
1. Unit test every meaningful input combination
2. In Onion Architecture terms, test the behavior of only one domain object or service at a time
3. Test all delegation from one class to another
4. Keep your tests small and readable
Viola!
By testing all delegation logic, you're almost forced to define an interface for each of your services so you can mock them when unit testing the classes that depend on them.
By testing every meaning input combination, you're forced to break up code into small, simple classes. Methods with high cyclomatic complexity will create too many input combintations. A class with 16 input combinations can often be broken up into two classes with four input combinations each. You just cut the number of test cases in half (4 + 4 = 8, 4 * 4 = 16).
By unit testing your classes, you prevent any dependencies on infrastructure. For example, you can't include code like DateTime.Now directly in your classes. Otherwise, you'll need to reset your system clock to produce a predictable unit test result - yuck.
You'll quickly find yourself learning design patterns because design patterns allow you to break large logical structures into small, individually testable classes.
The mistakes you do make will be small and easy to correct. After all, your unit test suite will catch any refactoring mistakes you make.
The next time you're feeling overwhelmed keeping up with the Palermos, Millers, and the like, challenge yourself to achieve 100% Unit Test Coverage. If you're like me, you'll find it rarely leads you astray.
Friday, August 1, 2008
Conventionalism over Confucianism
Since the .NET 1.0 Beta was released in 2001, I've been firmly in the .NET camp. However, there is (at least) one thing that the Ruby-on-Rails guys really nailed - Convention over Configuration.
How should I organize my solution? What should I name my views? What should I name my product category table this time (tblProductCategory, ProductCategory, or product_category)? How should I test my data access layer? In my opinion, the best answer to these and the thousands of other trivial decisions we make as developers every day is "You tell me" or "I'll tell you", but let's be consistent.
During my time as a developer, I have made two observations about (non-Headspring :) ) developers. First, most developers feel entitled to largely contribute to these kinds of decisions or outright make them for themselves (and thus not be consistent with the rest of the team). Second, in pursuing their agendas, they feel justified in spending hours arguing the relative merits of their trivially different positions.
On the surface, this may seem like a plus. "Isn't it great that our developers are so passionate about pursuing perfection?" In practice, though, all this philosophizing about casing, underscores, solution organization, and other small issues comes at a price. That time is not spent thinking about software licensing, golf-club fitting, apartment locating, and Sarbanes-Oxley compliance (my last several projects). In short, it's not spent thinking about how to address the difficult business problems we were hired to alleviate through technology.
This is where clearly defined and rigorously practiced technical leadership is worth its weight in gold. Like in any discipline, a good leader relies on his or her own experience and seeks the input of other team members. The leader than aggregates all of this information, makes a decision, communicates the decision, and ensures compliance (through carrots and sticks). While developers tend to fear strong technical leadership, good leadership makes everybody more comfortable in their role by providing clear expectations. It also greatly increases team effectiveness (by eliminating wasteful discussions) and the likelihood of delivering software that truly meets the needs of the business.
This technical leadership is particularly important in the land of .NET. Let's face it - the development techniques Microsoft promotes in its sales demos, certified training curricula, and Patterns and Practices website do not generally constitute solid software engineering practice. For example, with the exception of Scott Guthrie and Scott Hanselman, I have yet to find anybody in Microsoft even talking about test-driven development.
To this end, Jeffrey Palermo has been working hard to harden the definition of the Onion Architecture. For at least our Headspring team, this architecture will provide guidance to better enable our technical leaders to move quickly and deliver excellence.
How should I organize my solution? What should I name my views? What should I name my product category table this time (tblProductCategory, ProductCategory, or product_category)? How should I test my data access layer? In my opinion, the best answer to these and the thousands of other trivial decisions we make as developers every day is "You tell me" or "I'll tell you", but let's be consistent.
During my time as a developer, I have made two observations about (non-Headspring :) ) developers. First, most developers feel entitled to largely contribute to these kinds of decisions or outright make them for themselves (and thus not be consistent with the rest of the team). Second, in pursuing their agendas, they feel justified in spending hours arguing the relative merits of their trivially different positions.
On the surface, this may seem like a plus. "Isn't it great that our developers are so passionate about pursuing perfection?" In practice, though, all this philosophizing about casing, underscores, solution organization, and other small issues comes at a price. That time is not spent thinking about software licensing, golf-club fitting, apartment locating, and Sarbanes-Oxley compliance (my last several projects). In short, it's not spent thinking about how to address the difficult business problems we were hired to alleviate through technology.
This is where clearly defined and rigorously practiced technical leadership is worth its weight in gold. Like in any discipline, a good leader relies on his or her own experience and seeks the input of other team members. The leader than aggregates all of this information, makes a decision, communicates the decision, and ensures compliance (through carrots and sticks). While developers tend to fear strong technical leadership, good leadership makes everybody more comfortable in their role by providing clear expectations. It also greatly increases team effectiveness (by eliminating wasteful discussions) and the likelihood of delivering software that truly meets the needs of the business.
This technical leadership is particularly important in the land of .NET. Let's face it - the development techniques Microsoft promotes in its sales demos, certified training curricula, and Patterns and Practices website do not generally constitute solid software engineering practice. For example, with the exception of Scott Guthrie and Scott Hanselman, I have yet to find anybody in Microsoft even talking about test-driven development.
To this end, Jeffrey Palermo has been working hard to harden the definition of the Onion Architecture. For at least our Headspring team, this architecture will provide guidance to better enable our technical leaders to move quickly and deliver excellence.
Wednesday, July 30, 2008
The Holy Grail - Application Development without Developers
If you've made it this far, I can tell you that the title is tongue-in-cheek. No throwing things at me or unsubscribing (thus cutting my readership in half).
Over the course of my career, I've seen attempts on various projects to eliminate the need for ongoing developer involvement in system maintenance. The argument goes something like this: If we could just build a flexible business rules engine, we wouldn't have to call the developers every time we need to update ourFILL IN THE BLANK.
Don't get me wrong... there is definitely a time and a place for application configurability. It's just that business owners (egged on by developers looking for a good challenge) tend to over-extend the concept. For example, they may foster the creation of a new micro-language for defining pricing rules. Something like:
IF ($PRICE$ > 100) $PRICE$ * .90 --> $PRICE$ ELSE $PRICE$
Given that I personally know both people who read my blog, I know you could implement the parser to apply this business rule. And why not? Now my business owners can be in complete control of their pricing rules! We're not just talking a few canned rules... No, I mean autonomous, unbridled, master-of-your-own-universe power!
But there are a few catches. What happens when my business owner misses a closed parentheses? Well, it's back to the drawing board to write a user-friendly syntax checker (a.k.a. compiler). But then, they forget the symbol for manufacturer cost and complain (which is, of course, $MFG_COST$). Well, it's probably time for documentation (language specification) and macro-builder (IDE). The next complaint you get is "My pricing rules are getting really hard to enhance without messing them up." Well, this time (again because I know who my readers are) you realize you'll need to implement a unit testing framework and educate your business owners on Test Driven Development.
By now, however, the gig is up. You don't know how to implement a unit testing framework for your new language, POOP (Pricing Open Operation Protocol). However, you've now spent 20% of your career developing it, its compiler, it's language specification, and its IDE. You're highly invested - it's no time to abandon POOP now!
You forge on... You begin gathering pricing requirements from your business owner (if only you could just program all day), implementing them, and demonstrating them for acceptance. It's just that you're life is harder than it used to be. You used to have a powerful, expressive language (C#), complete documentation (MSDN), whiz-bang development tools (Visual Studio & Resharper), and unit testing framework (NUnit). Now you've just got POOP.
Over the course of my career, I've seen attempts on various projects to eliminate the need for ongoing developer involvement in system maintenance. The argument goes something like this: If we could just build a flexible business rules engine, we wouldn't have to call the developers every time we need to update our
Don't get me wrong... there is definitely a time and a place for application configurability. It's just that business owners (egged on by developers looking for a good challenge) tend to over-extend the concept. For example, they may foster the creation of a new micro-language for defining pricing rules. Something like:
IF ($PRICE$ > 100) $PRICE$ * .90 --> $PRICE$ ELSE $PRICE$
Given that I personally know both people who read my blog, I know you could implement the parser to apply this business rule. And why not? Now my business owners can be in complete control of their pricing rules! We're not just talking a few canned rules... No, I mean autonomous, unbridled, master-of-your-own-universe power!
But there are a few catches. What happens when my business owner misses a closed parentheses? Well, it's back to the drawing board to write a user-friendly syntax checker (a.k.a. compiler). But then, they forget the symbol for manufacturer cost and complain (which is, of course, $MFG_COST$). Well, it's probably time for documentation (language specification) and macro-builder (IDE). The next complaint you get is "My pricing rules are getting really hard to enhance without messing them up." Well, this time (again because I know who my readers are) you realize you'll need to implement a unit testing framework and educate your business owners on Test Driven Development.
By now, however, the gig is up. You don't know how to implement a unit testing framework for your new language, POOP (Pricing Open Operation Protocol). However, you've now spent 20% of your career developing it, its compiler, it's language specification, and its IDE. You're highly invested - it's no time to abandon POOP now!
You forge on... You begin gathering pricing requirements from your business owner (if only you could just program all day), implementing them, and demonstrating them for acceptance. It's just that you're life is harder than it used to be. You used to have a powerful, expressive language (C#), complete documentation (MSDN), whiz-bang development tools (Visual Studio & Resharper), and unit testing framework (NUnit). Now you've just got POOP.
Friday, July 18, 2008
Welcome to Headspring!
In what has become a growing trend, we've recently brought on two outstanding new team members: Blake Caraway and Duane DeRouen.
Blake comes to us from Callaway Golf Interactive where he led teams to implement distributed e-commerce systems. Blake is a technology thought leader and has experience working with clients to define what they really need (as opposed to what they initially think they need).
Duane joined us officially after playing an instrumental role at our largest client. His expertise in project and account management will be vital to our company's continuing success.
On a personal note, my biggest motivation in being on the leadership team of a small company has always been to have the opportunity to work with the very best people. Our two newest hires exemplify that excellence in their work, and I can't wait to spend more time in the trenches with them.
Blake comes to us from Callaway Golf Interactive where he led teams to implement distributed e-commerce systems. Blake is a technology thought leader and has experience working with clients to define what they really need (as opposed to what they initially think they need).
Duane joined us officially after playing an instrumental role at our largest client. His expertise in project and account management will be vital to our company's continuing success.
On a personal note, my biggest motivation in being on the leadership team of a small company has always been to have the opportunity to work with the very best people. Our two newest hires exemplify that excellence in their work, and I can't wait to spend more time in the trenches with them.
Subscribe to:
Posts (Atom)