Whenever I think of cowboys, I think of free spirits, tanned, dusty loners riding their trusty steeds across the rugged vistas of the South-West. I think of self-sufficient men whose only visceral fears might be that of a warm bubble bath or a soothing MANicure. Basically, I think of The Magnificent Seven, minus the unfortunate Horst Buchholz.
When I hear the term "Cowboy Coder", I think of the smartass kid in high school who thought he knew more than the Comp. Sci. teacher and brought the whole school network down through some clever cocktail of arrogance and incompetence.
Whoah Cowboy!
While software development is one of the best careers for creative, independent thinkers (stay tuned for an upcoming blog entry on that very subject), it is not a place to exercise one's Lone Ranger sensibilities. Developing serious software is generally a team effort (just don't tell Chris Sawyer). When managing a software project and the various rough characters that make up a team of developers, it is important to put in place a development process that leverages the strengths of the many while smoothing out the inevitable friction their individual efforts will cause.
As defined in The New Dictionary of Cultural Literacy, "Too many cooks spoil the broth" means that "When too many people work together on a project, the result is inferior." (Ask Microsoft about that one.) In other words, even with the best of intentions, it is possible for a skilled developer to write code that will "break" someone else's code. In fact, you can pretty much expect it. (When one developer does this repeatedly, he's likely gone off and become a Cowboy Coder.)
So how do you give free reign to your developer's creativity while ensuring that their individual efforts don't slow down the progress of the whole?
When I hear the term "Cowboy Coder", I think of the smartass kid in high school who thought he knew more than the Comp. Sci. teacher and brought the whole school network down through some clever cocktail of arrogance and incompetence.
Whoah Cowboy!
While software development is one of the best careers for creative, independent thinkers (stay tuned for an upcoming blog entry on that very subject), it is not a place to exercise one's Lone Ranger sensibilities. Developing serious software is generally a team effort (just don't tell Chris Sawyer). When managing a software project and the various rough characters that make up a team of developers, it is important to put in place a development process that leverages the strengths of the many while smoothing out the inevitable friction their individual efforts will cause.
As defined in The New Dictionary of Cultural Literacy, "Too many cooks spoil the broth" means that "When too many people work together on a project, the result is inferior." (Ask Microsoft about that one.) In other words, even with the best of intentions, it is possible for a skilled developer to write code that will "break" someone else's code. In fact, you can pretty much expect it. (When one developer does this repeatedly, he's likely gone off and become a Cowboy Coder.)
So how do you give free reign to your developer's creativity while ensuring that their individual efforts don't slow down the progress of the whole?
Enter Continuous Integration
One of the best ways to avoid Wandering Cowboy Syndrome is to implement an agile methodology with, among other things, Continuous Integration (CI). If you've never heard the term "Continuous Integration" or are only vaguely familiar with its meaning, it's worth your time to read the Wikipedia entry on the subject. It's clear and concise. Alternately, please allow me to attempt to summarize what "CI" is in as few words as I can:
When trying to summarize the key strengths of CI, two adverbs come to mind:
There be Flex in them thar fields!
So where is the Flex, you might ask. I'm coming to that. My previous CI experience was on a Spring/Maven/Hibernate/Oracle project at Industry Canada. I'll admit that getting a handle on all of the Spring XML boilerplate configuration files, proxies, etc. was a pain, however, the benefit of using a continuous build tool (Bamboo with CVS) and unit testing framework (JUnit, of course) was evident from the get-go.
So, when I came on board here at 4Point, I was glad to hear that the Flex and Java development process was moving towards a test-driven, continuously integrated development process. I was even glad when I was asked to set it all up (naïve, I know). It wasn't all simple and straightforward, so hopefully I can save you some grief by explaining how I managed to get Hudson, Ant, FlexUnit, Air and Subversion to all play nice.
But that's for another blog posting, pardner...
Y'all come back for Part 2 now, ya hear?
Note: Continuous Integration is only a benefit if the unit tests that go with your code are well written, so for now, if you're new to Unit Testing/Test-Driven Development (TDD), please go through this tutorial by Neil Webb on unit testing Flex code. It's really very well written and will go a long way to getting you writing CI-friendly code.
One of the best ways to avoid Wandering Cowboy Syndrome is to implement an agile methodology with, among other things, Continuous Integration (CI). If you've never heard the term "Continuous Integration" or are only vaguely familiar with its meaning, it's worth your time to read the Wikipedia entry on the subject. It's clear and concise. Alternately, please allow me to attempt to summarize what "CI" is in as few words as I can:
Continuous integration improves the process of merging the code contributions of multiple developers through the use of unit testing and automated build tools. Developers check in small code changes and related unit tests throughout their working day. Build management software automatically validates that no individual code submission breaks the compilation process or causes one or more unit tests to fail. In the case of a build or unit test failure, all users are notified as to who checked in the faulty code/tests, allowing the offending party to correct the failure as quickly as possible.Peer Pressure: The Good Kind
When trying to summarize the key strengths of CI, two adverbs come to mind:
- Continuously -- No cowboy can mosey very far from the
herd. By setting an expectancy that code will be checked in at least once daily, you
know that a developer will only work on bite-sized chunks of
functionality and that these "chunks" won't wander off and break the
build. If they do wander, they won't have time to go very far.
- Transparently -- The single most powerful behaviour-correcting tool a group possesses -- peer pressure -- can be brought to bear on any transgressor. Everyone is notified when a build is broken, so everybody instantly knows who broke it. While this pressure generally takes the form of jocular, light-hearted jibes, trust me: nobody wants to be the last person to break the build.
There be Flex in them thar fields!
So where is the Flex, you might ask. I'm coming to that. My previous CI experience was on a Spring/Maven/Hibernate/Oracle project at Industry Canada. I'll admit that getting a handle on all of the Spring XML boilerplate configuration files, proxies, etc. was a pain, however, the benefit of using a continuous build tool (Bamboo with CVS) and unit testing framework (JUnit, of course) was evident from the get-go.
So, when I came on board here at 4Point, I was glad to hear that the Flex and Java development process was moving towards a test-driven, continuously integrated development process. I was even glad when I was asked to set it all up (naïve, I know). It wasn't all simple and straightforward, so hopefully I can save you some grief by explaining how I managed to get Hudson, Ant, FlexUnit, Air and Subversion to all play nice.
But that's for another blog posting, pardner...
Y'all come back for Part 2 now, ya hear?
Note: Continuous Integration is only a benefit if the unit tests that go with your code are well written, so for now, if you're new to Unit Testing/Test-Driven Development (TDD), please go through this tutorial by Neil Webb on unit testing Flex code. It's really very well written and will go a long way to getting you writing CI-friendly code.
I find CI is critical to making unit tests work for you in the long run. I find it helps motivate the writing of high coverage test suites. You know those tests pay off every time someone else commits code.
Moreover, the instantaneous ability to run the latest build is a real bonus for measuring where you are. I can see my coworkers changes before checking his changes out. No one needs to tweak their environment and check out head into a clean workspace. CI just gives you the latest and greatest right away.