Adam.Kahtava.com / AdamDotCom

I was chatting with a Flash Developer turned Web Developer. When asked why he made the transition, he predicted that HTML 5 and the evolution of the web thereafter would lessen the demand for Flash Developers (possibly making them obsolete) and that moving towards a Web Developer / Generalist is an investment for the future. I thought that was an interesting perspective. It’s not far fetched to predict that the open web will replace proprietary browser plug-ins - in many cases digital content has already replaced print.

Behaviour Driven Development (BDD) generally makes use of Mocks, Unit Tests, or specialized BDD Specification Frameworks like RSpec, MSpec, NSpec, JBehave, NBehave. View the list of other BDD frameworks here and read more about BDD here: A New Look at Test Driven Development.

Now, I’ve been finding Behaviour Driven Development fascinating in a geeky kind of way (kind of like functional programming languages, and programming paradigm debates), but BDD has left a gnawing uneasiness in the back of my mind - generally this mind chewing begins when I’m missing the bigger picture or when something just isn’t right. I got a chuckle out of Spolsky’s writing as he discusses specification frameworks:

the geeks … focus on things they can see in the code, rather than waiting for the users to judge. They’re programmers, so they try to automate everything in their life, and of course they try to automate the QA process. This is how you get unit testing … In order to mechanically prove that a program corresponds to some spec, the spec itself needs to be extremely detailed. In fact the spec has to define everything about the program, otherwise, nothing can be proven automatically and mechanically. Now, if the spec does define everything about how the program is going to behave, then, lo and behold, it contains all the information necessary to generate the program! And now certain geeks go off to a very dark place where they start thinking about automatically compiling specs into programs, and they start to think that they’ve just invented a way to program computers without programming.

Now, this is the software engineering equivalent of a perpetual motion machine. It’s one of those things that crackpots keep trying to do, no matter how much you tell them it could never work. - Talk at Yale: Part 1 of 3, Joel Spolsky

Hehehe… Anyhow; I need to cut this post short. My DIY Nuclear Fusion Reactor and perpetual motion machine are calling my name. Errrr… I mean, I need to continue working through the RSpec book and playing around with other specification frameworks, because there’s always value in learning something new.

Eric Evans provides this interesting commentary while he discusses refactoring targets:

When you encounter a large system that is poorly factored, where do you start? In the XP community, the answer tends to be either one of the these:

1. Just start anywhere, because it all has to be refactored.
2. Start wherever it is hurting. I’ll refactor what I need to in order to get my specific task done.

I don’t hold with either of these. The first is impracticable except in a few projects staffed entirely with top programmers. The second tends to pick around the edges, treating symptoms and ignoring the root causes, shying away from the worst tangles. - Domain Driven Design, Eric Evans

I can think of many times where developers (myself included) have really just been gold plating under the guise of refactoring, or other times when refactoring activities contributed superficial cosmetic changes while the real mess lies beneath - getting to the root of the problem requires significantly more time and work than we’re often allocated and the cosmetic changes give us a sense of motion without moving. Then there are the occasions where seemingly superficial refactorings lead to an insightful break through.

Of course Evans isn’t suggesting that we stop refactoring altogether, instead he suggests that we think about what we’re refactoring, and that we focus on the parts of our software that provide the most value - in the context of Domain Driven Design this would be our Core Domain.

Ruby is consistently placed as one of the ten most popular programming languages - see the TIOBE Programming Community Index for more language comparisons. Matz (the creator of Ruby) described his guiding philosophy for the language as one that’s “designed to make programmers happy”. While the Ruby language gets a lot of praise for its zen like qualities, its clarity, and terseness. The tools surrounding Ruby like the RubyGem Package Manager along with its active community and growing collection of Gems (view the list here) are often overlooked.

I like the RubyGem system just as much as Ruby, it makes a developer’s life easy.

For example, let’s say I want to design a new class:

• Install Ruby
• Install the Test-Unit Gem (along with a couple automatically installed prerequisites):

C:\>gem install test-unit
 Successfully installed test-unit-2.0.2
 Successfully installed hoe-1.8.3
 Successfully installed rubyforge-1.0.2
 Successfully installed rake-0.8.3

• Create a new test.rb file along with a new class.rb file (alternately we could have used the Interactive Ruby Shell directly from the command line)
• Run the test (test.rb):

C:\>ruby test.rb
 Loaded suite test
 Started
 .
 Finished in 0.001 seconds.
 1 tests, 1 assertions, 1 failures, 0 errors

• ???
• Profit! :)

Contrasting this to the Java / C# world: I’d be installing a compiler (or slower yet an IDE), then installing / configuring a testing framework. I’d also probably be installing a build process tool (like ant / nAnt), then I’d need to create a build file.

Similarly if I wanted to install Rails at the command line I specify gem install rails or if I want to use  RSpec gem install rspec.

The Ruby tools, ecosystem, and community is fantastic.

Some people advocate frequent backups - and some go so far as to suggest making use of offsite storage, duplicating their DVD/CD collections, and so on. This fixation on personal data redundancy seems multi-compulsive for an individual or a family (running a company is obviously a different situation).

I personally do not have a data backup plan - aside from online storage like Google Docs, Flickr (for photos and videos), and source control. I have lost years worth of files a number of times, and every time my hard drive comes screeching to a halt, I feel that burning pit of anxiety deep in my stomach, but guess what? It doesn't last long. Seriously, over the years there has never been a case where I lost something that I absolutely needed (again, personal pictures and videos are an exception). After losing data, I find myself pining for a couple recently created / used files, I then recreate the files in a quarter the time it took me to do the first version, then I forget about the heaps of digital baggage I was hording over the years.

Personal data loss might be part of a natural regeneration process - like a forest fire, it makes way for new growth and forces us to focus on the present.

Stop fighting nature, forget about a data backup plan, involuntary random data purging might be good for all of us. Perhaps a digital natural disaster is in order for you. :)

Can you let go of your bits? What is your backup strategy? Why do you backup?

The Law of Two Feet is just as applicable to life, as it is to Open Spaces.

The Law of Two Feet:

If at any time during our time together you find yourself in any situation where you are neither learning nor contributing, use your two feet. Go to some other place where you may learn and contribute. - Open Spaces, Wikipedia

By applying this philosophy to software development (programming languages, operating systems, and development ecosystems), I’ve really been been re-igniting my passion as a software developer. I am foremost a software developer and the tools and products I choose are secondary, but I lost sight of this over the past couple years. I was buying into being a [insert your choice of ecosystem, language, operating system here] developer.

Anyhow; this isn’t to say I won’t be raising my concerns (running away), I’ll continue to make noise (because I believe it has value), but when change doesn’t manifest. I will (like so many people before me) use my own two feet and move towards a situation where I can continue to learn, contribute, and be the change I’d like to see .

Steve Ballmer (the CEO of Microsoft) made this comment during Mix ‘08 during his interview with Guy Kawasaki:

GUY KAWASAKI: Okay. … so it was like in the ashtray of your Lexus?
STEVE BALLMER: I’m a Ford guy, and I’m slightly offended by that. My father who worked for Ford would be offended, but nonetheless …

Fair enough, Ballmer likes Ford, but what kills me is that he apparently made his choice by association. Like Ballmer, my extended family are (were) also employed by Ford in the US Rust Belt. However, I still value quality and the economics of a purchase over my family affiliations. Of course, this is a broader issue - many people favour historical affiliation / brand loyalty over critical thinking and this may never change, but Ballmer is the CEO of Microsoft!

Now Ford, GM, Chrysler are on the verge of bankruptcy, and while many factors contribute to their situation. I think most people agree that these automakers kept making poor decisions for short term revenue gains - they kept making bigger expensive, less efficient cars, they were inward focuses and failed to look at possible future scenarios (like a global economic recession, skyrocketing oil prices, doomsday, blah-blah-blah). Basically, the big three automakers have been out of touch with the rest of the world. People like me (and probably you too) have never owned a domestic car. For myself, imports offered better value for my money (better fuel efficiency, a higher resale value, and a longer life). In addition, imports felt safer, sturdier, and were more aesthetically pleasing. Imports offered quality over quantity, and they looked nice too - imports made me a happy satisfied consumer.

Like the big three automakers, Microsoft (or Ballmer at least) is out of touch with their community (their developers). For myself, the community oriented / collaborative communities outside Microsoft are continually drawing me in. The openness of these communities and their open solutions is one part of the interest, but I’m also growing tired of working in an ecosystem (and with developers) that literally lag years behind the rest of the software world. Down here in the trenches Microsoft centric developers bear a striking resemblance to the unionized American autoworkers - inflexible, arrogant, and inward focused.

I want a development stack I can be proud of, that embraces quality over quantity, to work with developers that share my values, and an environment that offers more aesthetics. In short I want to be a happy satisfied developer.

In all fairness, it’s great how Microsoft is opening up (i.e. IronRuby, IronPython, MVC, etc…), but there are already more open established and mature communities outside Microsoft. I also really like C#, WCF, ASP.NET MVC, and Server 2008, but it’s all the baggage associated with the Microsoft ecosystem. It’s also fair to mention that the ALT.NET community is making great strides, but it is fundamentally discouraging that ALT.NET had to be formed in the first place. I mean, where are all the ALT.Rails, ALT.Ruby, ALT.Linux, ALT.Java communities?!

According to popular developer consciousness:

good programmers tend to cluster in some organizations, and bad programmers tend to cluster in other organizations … (Demarco and Lister 1999). - Steve McConnell

Can we draw the corollary that:

Good programmers tend to cluster away from traditionally closed development ecosystems like Microsoft, and bad programmers tend to cluster toward Microsoft like ecosystems?

Following Robert Glass’s train of thought:

The most important factor in software work is not the tools and techniques used by the programmers, but rather the quality of the programmers themselves. - Robert Glass, Facts and Fallacies of Software Engineering

Could we conclude that:

Good programmers tend to realize that an investment in their personal development is more important than learning the latest tools? Are product / tool based ecosystems like Microsoft’s at direct odds with the core values of a good programmer?

My hunch is that exceptional developers are versatilists. These developers cluster around organizations that embrace knowledge over tools, open technologies, open communities, and these great organizations also embrace vernacular culture. What do you think?

I was at the point where I could visualize the project’s code, the team had gelled, and we only had a couple remaining issues. This was after almost a year of over time and personal sacrifices. From our perspective (the developers) everything was great. Then for reasons beyond our control, the project was canceled. I was DEVASTATED! Somewhere over the course of this project I had lost my personal life and began equating my personal success to the project’s success. When the project came to a screeching halt, so did I.

Listening to Yegge, Spolsky, and Atwood really brought up this uncomfortable memory of projects past.

[Yegge] some people … they can’t handle [a failed project]. They’re out on the ledge, you have to talk them down real slow, it’s usually more junior people. 

[Spolsky] I don’t know about junior, but … that they identified with the project, and that is kind of important. … People are going to be … devoted to a project that they identify with.

[Yegge] … identifying with anything so strongly that it starts to give you emotional reaction is really bad. You never know when your language is going to be obsolete or your project is going to get canceled or your favorite framework is going to be replaced. - Steve Yegge, Joel Spolsky, stackoverflow podcast #25

I can certainly relate.

My experience was a lesson learned, which resulted in a couple personal changes:

• No overtime at the expense of personal life or prior commitments.
• A quest for a more outward facing perspective on projects and the industry in general.
• A need for remaining emotionally detached from the project - as well as the frameworks, technologies, and the languages that I use.
• An aversion towards organizations that encourage the type of situation I had gotten into.
• Skepticism towards company loyalty, brand loyalty, etc…

One of the risks to a project’s success is a dysfunctional team. It’s common for team morale to fluctuate as a project moves through its life cycle - project politics, bureaucracy, challenging overtime demands, etc, can all take their toll on a team. A team under stress can take a couple of diverging roads - from what I’ve experienced a team can rise to the challenge (like a family) and grow stronger, or digress into a winner-takes-all environment (like Survivor).

There is no “I” in “T-E-A-M”. A team falls apart when members begin participating in backstabbing, which often results in negative alliances being formed between members - while a sense of self preservation and distrust creeps around the otherwise neutral team members. Soon the team digresses into a group of individuals operating in silos. I don’t think it’s possible to put a finger on the catalyst for the entire process, but it could boil down to a combination of: an overly cynical team member, a preexisting alliance between team members, lack of leadership on the project, a team member with an unexplainable need for political control (perhaps lack of confidence in their abilities), a dysfunctional working environment, or human nature?…

No individual is a success who hurts the team, and no individual is a failure who helps it. - Software Project Survival Guide 

How can we cope? Bottom line: RESPECT. Treat your team as family, recognize that everyone has different strengths and weaknesses. Don’t participate in backstabbing, be transparent and honest, if you have an issue with a team member then make it a point to discuss your concerns with that member. Anyone participating in backstabbing is hurting the team.

Nobody on the team should feel unappreciated or ignored. This ensures high level of motivation and encourages loyalty toward the team, and the goal of the project.  - Respect, Extreme Programming Values

A project’s success hinges tightly on the team. Being a team player and having great interpersonal skills can be more important than technical skills - most people can rapidly learn new technical skills, but being able to function within a team might be an ingrained personality characteristic.