It hasn’t been long since I joined Telerik, but I’ve been associated with them some time before as a Telerik Insider. I made the decision to join Telerik because of the great people, their community support, and of course, their awesome products. If you’re Telerik fan, I have a favor to ask you.

This is the final voting period for the DevProConnections Community Choice Awards. Please vote for Telerik today!

If you haven’t tried Telerik products before, download a trial of something you’re interested in. As you can see from the category list, there’s something for everyone. We even have seventeen freebies!

I was driving down the road to pick up dinner when a familiar tune came on the radio. I usually listen to music on my Windows Phone, but I had forgotten to put it in my pocket before I left. The song started out with an electronic voice saying “cowboy… cowboy.” Since I grew up in the 90s, I decided to turn it up for nostalgic purposes.

Back in the 90s, I was a certified cowboy coder. Even in 2000 when I started working on a team project, the team and the product had little to no discipline. Requirements were handed off as features the owner of the company would like, and they were divided up to be tackled by individuals based on interest. Some might call this “agile,” but there were no cycles, no unit testing, little shared ownership, and little accountability. I did things my own way, and learned from others around me.

As I matured as a developer, I came to realize how important certain skills were in working with teams. I found myself worrying about the maintainability of code as I knew it would one day be handed off to others. I found myself wanting to ensure my code does what I expected it to do. I found myself caring less about what I was doing specifically and more about the success of the team.

Earlier today, I encountered a StackOverflow question about what the opposite of TDD. Someone proposed the term “Cowboy Driven Development.” I feel this term isn’t correct, because an individual cowboy coder may utilize test-driven development. The response also contained a list entitled “The Cowboy Way.”

The Evil Cowboy Coder

The list the user posted describes someone you would despise working with. I followed the provided links to the source on c2.com. The top paragraph of the wiki describes the traditional cowboy coder, but the list describes someone I can only deem as an evil cowboy coder.

The Cowboy Way (from c2.com):

• The speed with which I can hack something together determines my worth
• People who need comments in order to understand my code are too dumb to be working with me
• People who ask me questions about my code are too dumb to understand it, and (therefore) are too dumb to be working with me
• Other people's code is just crappy, but mine is self-descriptive and beautiful
• Exploiting a compiler-dependent language feature to save a line of code is "elegant"
• Other people on my team cause all of the bugs; I'm the one that fixes them
• My code is never at fault, always perfect, and I don't make mistakes
• Since my code is never at fault, I don't need to test it thoroughly, if at all
• Since my code is always perfect, it never needs to be refactored no matter how long it's been in the codebase or how much has changed around it
• Since I never make mistakes, I can yell at anyone else who does
• Since my code is perfect, if the program crashes due to unexpected data, it's the user's fault for entering bad data.
• Since my code is perfect, if the program fails after a minor machine configuration change, it's the sysadmins fault for changing it.
• Since my code is perfect, if the program runs too slowly, it's the managements fault for not providing a faster machine.

If someone exhibited all of these traits, I am amazed they have a job. However, I don’t really think this is a traditional cowboy coder than a know-it-all or alpha coder. These developer archetypes aren’t mutually exclusive.

Here is a contradictory quote immediately following the list.

I worked in a whole company of these people; some of whom really seem to think this way. They're nice people, don't get me wrong, but they just don't seem to think very much about the usability of their code.

The list describes someone who is downright mean. Sure, the subject may be nice on other topics, but when it comes to code, this person is horrible.

I don’t think c2.com list is a good indicator of the evil cowboy coder, or the code rustler. Here is a better one.

The Code Rustler Way:

• Making money is of paramount importance; therefore I will obfuscate code and withhold vital information so I will need to be consulted in the future.
• I ignore standards set by team.
• I intentionally use poor naming so others cannot understand it.
• I become irate when others modify my code.
• Since I pasted the code, it’s mine to take credit for even if copied off the Internet.
• I steal code created by others from one project and use it on another.

The Good Cowboy Coder

The cowboy coder who is not a code rustler may not work well in teams, but this person is good, and even desired, for certain situations. Here is how to identify a cowboy coder.

The Cowboy Way:

• The speed with which I can hack something together determines my worth.
• Team standards do not matter to me, only working code.
• My own tools and processes are proven, therefore I will use them.
• I am not concerned with what others think of my coding style.

Startups and small business will bring a cowboy coder in to quickly create projects. The result is that other developers have difficulty in maintaining the project as the code, processes, and tools may not be familiar. However, the business requirements may dictate a need for speed and lower cost to quickly get the project off the ground.

Other companies may bring in cowboy coders to troubleshoot issues with a current codebase. This occurs when the development team is already having issues meeting deadlines, and bugs are piling up. The contractor doesn’t have time to become familiar with the processes of the team and is brought in only to alleviate existing problems.

Cowboy coders are regularly hired to do small projects for companies without project management or a development team. When that coder moves on, another cowboy coder is brought in to make enhancements or bug fixes. I’ve worked on projects with many styles of development, and it was likely a result of several cycles of cowboy coders.

You’re Not Immune to Cowboy Syndrome

You work well in a team that practices SCRUM, BDD, and you prefer declarative code. One day, you find yourself put on a team that uses a different set of standards and practices. SCRUM and BDD have worked well for you, do you try to change the team or do you acclimate?

You have several options: adopt the team’s standards, encourage the adoption of your standards, go rogue, or find another team. A few years ago, I worked on an Agile/SCRUM team that had a cowboy coder. At first, he tried to change things to his “better” way. When it was rejected, he continued doing things his way. He was moved to a position that would have minimal impact on the rest of the team, but eventually he became fed up with it and moved on.

Now consider this: are you agile? Would you do the same as my former coworker if you were on a team that wasn’t agile? If so, you would be deemed a cowboy coder as he was.

Laptops typically have special shortcut keys to help you when you plug up projectors, but did you know that Windows 7 has a shortcut key as well? Press Windows Key + P to bring up your display and projector options!

Since I have multiple monitors on my desktop, the extend option is correct for me. Knowing this shortcut can save you time if you’re about to give a presentation and you’re having difficulty with the projector. It’s also useful when recording demos on your desktop and you want to quickly turn off your secondary displays!

I am preparing to upgrade a Team Foundation Server 2008 to Team Foundation Server 2010. Based on prior experience of upgrading from 2005 to 2008, I decided it would be a good idea to read the manual this time. A quick server for “TFS 2010 install guide” took me to what I was looking for: the Team Foundation Installation Guide for Visual Studio 2010.

I downloaded the RTM of the CHM file and opened it up only discover is was devoid of any content. (Excuse the screenshot, my work laptop is on XP).

I was perplexed… why is this empty file on Microsoft downloads.

I checked the options menu to see if there was anything that could help. What I found was a list of standard options for Internet Explorer. I clicked on Home, and nothing happened. I decided the problem must be a security issue.

I then opened up the properties on the file itself and found an interesting option I’ve never seen before.

That did the trick.

If you’ve ever opened Office files that you’ve downloaded from the Internet, it will give you the option to unblock content within the Office program. The properties option is present on those files as well (I went back to check). It appears that the Help Viewer needs to be updated to be more user friendly.

Emad posted a slideshow of photos from CairoCodeCamp. It was one of the most amazing experiences of my life. I not only got to present at an excellent conference, but I was able to visit the pyramids of Giza and the Cairo Museum while I was there! This video will give you a small taste of what I experienced in Egypt.

I started writing this article with code in mind. It wasn’t until I put the pieces together that I realized the repercussions. The two projects I write about allow one to specify and create the robots to start the robot apocalypse. Warning: you might need Robotic Studio as well!

Microsoft Research has a tendency to release things that require several cups of coffee to wrap my head around, and the TLA Toolbox is no exception. With it, you write PlusCal algorithms (get it right, it’s an algorithm language, not a programming language) which get’s translated to a TLA+ specification. TLA+ Toolbox can then run a model checker.

To get full usage of the tool, you should read the book, Specifying Systems. It’s available for purchase or free for download. This isn’t your typical evening computer book read though… Specifying Systems is full of mathematical symbols… it reads more like a thesis than a popular computer science book.

 
^{Hour Clock Specification formula from Chapter 2 of Specifying Systems}

Being the three-letter acronym for three-letter acronyms, I had to sift through a few entries to figure out what TLA actually meant. I eventually found that it stands for temporal logic of actions. It describes behaviors in concurrent systems, which makes sense considering time is an element of concern in concurrent systems.

Mentioning concurrent systems, another project had a release today… SIGMA: Large-Scale and Parallel Machine-Learning Tool Kit. Here’s the summary:

The goal of SIGMA is to provide a group of parallel machine-learning algorithms that can meet the requirements of research work and applications typically with large-scale data or features. The tool kit includes more than 10 algorithms and it makes them run on single multicore machine or on a HPC cluster with hundreds of machines and thousands of CPU cores running.

Parallel machine-learning algorithms? I’ve watched too many science fiction movies to know where this is going.

Installing SIGMA gives you a program called MLUI3 Studio. As promised, there are 10 algorithms including some training data and other inputs for the tests. Some of these algorithms are your typical classification and decision making algorithms. For those of us who fear a robot apocalypse, three stand out.

Neural Networks: with this the possibility exists for all of our machines to combine into one giant processing unit.

Boosting: One processing unit not scary enough? Each individual machine is a poor learning. What if each individual machine on the neural network could provide synergy in boosting other’s learning ability.

Expectation-maximization: The one thing us humans had left going for us was our ability to be random and go with our “gut” instinct.  These instincts are likely the combination of many factors we have trouble computing the correct decision, but our subconscious is lending us a hand (like when you’re in the zone and you do instead of think). With expectation-maximization, we have lost that advantage. The bots can now find the maximum likelihood based on probabilistic models, even when those models depend on unobserved latent variables.

We’re doomed. Cyberdyne is alive… and to think, Microsoft Research has even had a project called Terminator since 2004. How could no one see this coming?

I received an email from a coworker today. She received a new computer and was having trouble viewing work items in Visual Studio. When she tried to open one up, she would receive the following error.

Could not load type 'Microsoft.TeamFoundation.WorkItemTracking.Client.WorkItemTypeDeniedOrNotExistException' from assembly 'Microsoft.TeamFoundation.WorkItemTracking.Client, Version=9.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'.

She had Visual Studio 2008 SP1 installed, and she was obviously connecting to Team Foundation Server. I then decided to look at my version of Team Explorer and compare it to hers. In my installed products (under Visual Studio, Help, About) I had “Microsoft Visual Studio 2008 Team Explorer - ENU Service Pack 1 (KB945140)” and she did not.

The updates to Team Explorer come from Visual Studio 2008 SP1, so my best guess is that her system had SP1 installed before Team Explorer was installed. If you ever encounter this problem, the fix is to reinstall Visual Studio SP1.

In late October of 2009, seventeen luminaries of the service oriented architecture community came together to debate and hash out a document known as the SOA Manifesto. This paper establishes what was missing amongst the hype: clarity and direction.

SOA prioritizes:

Business value over technical strategy
Strategic goals over project-specific benefits
Intrinsic interoperability over custom integration
Shared services over specific-purpose implementations
Flexibility over optimization
Evolutionary refinement over pursuit of initial perfection

And here are the guiding principles of SOA:

Respect the social and power structure of the organization.

Recognize that SOA ultimately demands change on many levels.

The scope of SOA adoption can vary. Keep efforts manageable and within meaningful boundaries.

Products and standards alone will neither give you SOA nor apply the service orientation paradigm for you.

SOA can be realized through a variety of technologies and standards.

Establish a uniform set of enterprise standards and policies based on industry, de facto, and community standards.

Pursue uniformity on the outside while allowing diversity on the inside.

Identify services through collaboration with business and technology stakeholders.

Maximize service usage by considering the current and future scope of utilization.

Verify that services satisfy business requirements and goals.

Evolve services and their organization in response to real use.

Separate the different aspects of a system that change at different rates.

Reduce implicit dependencies and publish all external dependencies to increase robustness and reduce the impact of change.

At every level of abstraction, organize each service around a cohesive and manageable unit of functionality.

I agree with all of these, but I do have confusion about the first principle: “respect the social and power structure of the organization.” That’s good advice for someone navigating a political structure in business, but what exactly does that have to do with a service oriented architecture? It seems like an auxiliary concern that shouldn’t be included in the guiding principles of the manifesto, yet seventeen people smarter than me decided to stick it at the top. What am I missing?

In any case, I do agree with the manifest, and I’ve signed it. Have you?

The first Columbia Code Camp will be hosted on January 30th, 2010 at Midlands Tech NE Campus. We are seeking speakers for up to six tracks with five or six sessions each. Sessions are expected to last one hour with a 15 minute break in between.

If you are passionate about a topic you feel the Columbia .NET community would be interested in, please submit it at http://columbiacodecamp.com/register. The cutoff for speaker registration is January 1st, 2010 or when all sessions are filled. We will have many certified professionals presenting at this event, but we are especially looking for local talent.

PLEASE FORWARD THIS E-MAIL to those you think may be interested, and please spread the word through Twitter, Facebook, and blogs.

Topic ideas:

1) .NET 4 and related technologies (themed)
2) Current .NET development topics
3) Non .NET technologies (yes, these are accepted!)
4) UI Design and business related topics essential for the .NET developer

Code camps are volunteer driven events that are free for attendees. As such, speakers are expected to provide for their own travel arrangements. If you are affiliated with an organization that would like to sponsor Columbia Code Camp 2010, please contact president@columbiadevelopers.org.

Columbia Code Camp 2010 will be on Saturday, January 30th, 2010 at Midlands Tech NE Campus, 151 Powell Rd, Columbia, SC. Registration is now open! I will announce sponsors and speakers periodically. 

What can you expect at our code camp? A great community event with other fellow developers learning about some of the newest technologies. It will features many speakers including Microsoft MVPs, books authors, and local talent.

Code camps are by and for the developers community with community developed material. If you've never spoken before, this is a great opportunity to put something together and present on it. Sessions range from information "chalk talks" to formal presentations.