I think that collaborating with the business and getting things in front of them as soon as possible so that you can make changes to it as you go is a very valuable model. I am also very much for the short release cycles that most agile shops prefer.

What I despise, however, is what I call “Agile as Snake Oil”. There are a lot of disreputable companies that are putting the word out there that all you have to do is hire them and they can “sprinkle a little agile” on your project or your company and you will magically get everything you want.

They crow that Agile means that you can not make up your mind on what you want until the last minute because Agile Developers have to do what you say and are bound by the Laws of Agile to always change the software for the client. They want their cake and to eat it, too. They want all of the spec changes and none of the timeline changes or compromises.

Oh, that they would actually read something like Robert C. Martin’s book, Agile Principles, Patterns, and Practices. I’ll tell you what, I think that if people only read the end of the book, where Uncle Bob tells a tale of two cities, a project where the team does a “traditional waterfall approach” and the same project where the team practices an “agile approach”, it would make a world of difference.

As you can imagine, the waterfall approach ends in disaster, with stress and hard feelings abounding. In contrast, people are satisfied – almost happy – with the agile approach. The HUGE takeaway from the agile story, however, is that it was not a 100% win for either side. They did not hit their original deadline with 100% functionality. Features had to be traded in if the timelines could not move. However, the business stakeholders were the ones who went ahead and made that call.

I covered this in my last “Agile” post over a year ago, but I think that it bears repeating. Every agile project should do these steps

1. Gather requirements
2. Estimate requirements to determine length of project
3. Work requirements in iterations
4. Gauge velocity in coding requirements against estimate
5. Determine whether your velocity requires you to either cut requirements or extend timelines
6. Lather, rinse, repeat

Developers always get a bad rap for number 5 and it is always largely based on our lack of skill at number 2. Estimating is something that developers really should improve on, however, the business needs to understand two major things. Number 1, those timeline estimates are based on developers being able to work on the project at “perfect world” capacity – meaning 75-80% of their time. If developers are interrupted with conflicting priorities, original estimates and timelines are null and void.

Second of all, those who live in glass houses should not throw stones. If the original requirements are so ill-planned that they need to be drastically refined or changed, then developers should be able to refine and change estimates, too, since they are basically working on a different project than the one they started with.

There are obviously no perfect people in this world, so that means that there is no perfect system. Any system will invariably break down because of those imperfect people going around and “being human”. That being said, the best way to get to nirvana is to act like the participants in Uncle Bob’s Agile Story and rely on the two C’s, “communication and compromise”.

Compromising is the original agile. Be retro.

I heard someone speak at a conference here in Ohio who was making this same point. Some time ago, the best visual medium for advertising was the print ad. Since that was the end of the standard understanding, when the web came about, people set out to put up what we now call “brochureware”. Basically taking their magazine ad or brochure and putting it up on the web. No real interaction and no reason to ever have a repeat visitor. Hey, but at least they had an “Internet Strategy”, right?

The same thing is happening now. Mobile is hot, so people are trying to create mobile apps that are nothing more than advertisements or brochureware for their product or business. Not a lot of people “get” mobile yet, so the good ideas are coming slowly. However, just as companies began to create interactive websites that provided a service or amusement while educating or advertising their service, that time will arrive for mobile, too.

Even now, forward thinking companies are getting it. The article mentions Proctor and Gamble’s sponsorship of a 3rd party application called “Sit or Squat” that helps locate public restrooms wherever you are, while at the same time keeping Charmin at the forefront of your mind and associating it with the best possible restroom experiences.

Having an idea or a strategy for what you will do to “accomplish” mobile is great, but the Harvard Business Review article pretty much stops there. In my opinion, the key to having a dynamic and impactful mobile strategy isn’t just how you will market to consumers. It encompasses how your employees will be productive. What sorts of applications could your employees use “on the go” (in meetings, during travel, etc) on a smartphone or tablet device? How will you deliver those applications to them?

The other big key to a successful mobile strategy is integration with your existing business platform. What sorts of services or APIs does your organization have exposed to allow mobile applications to integrate with your systems? If you have none, what would it take to create them? This to me is the heart of a Great Mobile Strategy in the Enterprise. It is mobile as an integrated natural evolution of your systems in a way that encourages productivity and growth. And that is the hard part.

If you aren’t in a place where new applications can integrate with you, then you are in a place that is stagnant. If every new application has to tear down and throw away what came before it, you are asking to fall behind. A Great Mobile Strategy starts with a Great Overall IT Strategy that allows mobile to become not just something “checked off” or “bolted on” but a full-fledged member of your company’s application stack.

There are a lot of developers who only want to do the “latest and greatest” thing. They practice what I like to refer to as RDD, which stands for Resume Driven Development. Every project is just a way to make their resume that much more enviable. It is even a little hard to fault these people at first blush because in the IT industry, if you aren’t pressing your skills forward, you are quickly becoming irrelevant. However, sometimes developers forget that they are being paid to deliver a solution for a client or employer. The client’s needs should always come first.

Are you doing work for a PHP and MySql shop? Could Ruby or Node or Cassandra help them solve their problem? Sure, but their existing code is in PHP, their on-staff developers know PHP, and finding PHP developers to hire is easier than finding a good developer who knows Node or Cassandra. You may very well be doing them a huge disservice by building them a “blazing fast web scale” solution.

That’s where Great Judgement comes in. New technologies may offer benefits, but there are always trade-offs in technology. The first is your own knowledge. If you are very familiar with C# and .Net and don’t know Ruby, but you try to put together a Ruby on Rails solution for a client that isn’t mandating Ruby, you are very likely going to cost them time and money while you deliver more slowly, let alone any mistakes you are sure to make or hard-to-maintain patterns you might leave behind because of your inexperience.

The second trade-off is the number of available developers to maintain and build upon your code. The system may really hum when you write it in Brainf*ck, but you just pretty much made sure that there are maybe 30 people in the world who could help that company maintain or grow it. Larger companies aren’t as susceptible to this as smaller companies because they usually have rigid standards in place, but the “market” for your code – be it the language, the framework, or even your patterns – should be at the forefront of your mind as you plan.

The third trade-off is not to over-engineer. Some developers want to create a highly robust and scalable system with a caching layer, failover clusters, and load balancing for every one of their solutions. They want a pluggable architecture and a side of fries with that. The problem is that they are making a small inventory application for the secretary to maintain her office supply levels for a staff of 9. Sad to say, but a simple Access database that would take an hour of your time to create may be all that they need.

I haven’t thought enough to actually assign Great Judgement as the number ONE trait of a great developer, but I definitely have to agree with the author, Tammer Saleh, on many of his points. If Great Judgement isn’t number one, it is certainly in the team picture. If you use Great Judgement, you are a long way to delivering valuable solutions to your clients and that may improve your resume way more than buzzwords.

After I arrived at my answer (by doing just that last year), I went into the Project Euler forums and found that quite a few people did it just the same way. Others actually attempted the prime factorization necessary to compute the least common multiple and had varying degrees of success.

With my recent foray into Scheme, I decided to hit the forums to see if anyone attempted problem 5 in Scheme. The first Scheme solution that I found was the following:

;; find the smallest number where n is
;; divisible by all numbers in given list
(define smallest-divisible-by
(lambda (num-list)
(let loop ((i 1))
(if (divisible-by i num-list)
i
(loop (+ i 1)))))) 

(define divisible-by
(lambda (n lst)
(if (null? lst)
#t
(if (= (remainder n (car lst)) 0)
(divisible-by n (cdr lst))
#f)))) 

;; generates a list of numbers between start and end
;; contract: number, number -> list
(define make-list-range
(lambda (start end)
(if (> start end)
'()
(cons start (make-list-range (+ start 1) end))))) 

(smallest-divisible-by (reverse (make-list-range 1 20)))

This was just a brute force method in Scheme. He created a list and then tried to find a number that was divisible by all of the numbers in the list. The bad news is that it took 97 seconds on my MacBook Pro with a Quad Core i5. That is completely unacceptable.

I got to thinking about it and I wondered if Scheme had a least common multiple function, as functional languages often have “neat math stuff” in their bag of tricks.

It turns out that it does. If I run this code:

(lcm 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20)

It returns the answer as soon as I hit enter, computed almost instantly. It may be cheating to use a built-in function, but in real life, I don’t think so. I think you use the best tool for the job and if I can answer a problem with no development and an instant result, I think that that is the tool I should use.

Once I had the .iso, I tried to install it in VMware on my MacBook Pro, but VMware kept complaining about some stupid error or another when it was trying to boot from the .iso, so I decided to move on. I fired up Virtual Box and this time got no complaints. The install was pretty quick and painless and took “maybe” a half hour, I didn’t time it. I created the virtual machine with 2 processors and 2 gigs of RAM and plenty of hard disk space.

My “artsy” install screen.

I also had to accept a license (it seems pretty lax):

Once I got all situated and into the OS, I was presented with a kind of confusing “totally green” screen. I was moving my mouse around and when I got to the “Start Button Corner”, some things popped up on the screen.

When I clicked “Start”, I got my first big time look at the new Metro UI.

If I scroll to the right a little, there is more.

But don’t worry, though, if too much change isn’t your thing. If you click “Desktop”, you get to see “Old Faithful”.

My first order of business – of course – was to check and make sure my blog was still okay. I mean, a man has to have priorities.

This version came with a Twitter client called Tweet@rama. It definitely is built in the Metro UI style that those of us with Windows Phone 7s are used to. It seems to have a panorama view and familiar styling on all of the icons and buttons.

Of course, you can run Visual Studio on it, but OH NOES… JavaScript!?!? Calm down, people, C# is still on here too…

All in all, Windows 8 is a good-looking operating system. If you can get behind the Metro UI on the Windows Phone, you will be at home here. The tiles can be moved around and they dip and slide out of each other’s way as you are doing any housekeeping or clicking. Also, there are Live Tiles – like WP7 – that update with current information.

If I was using this on a touch device, I would call this a definite home run. The problem is that the side scrolling was a little clunky to me using a mouse. It could be a VM issue, but my scroll wheel on the mouse that normally lets me press and slide up-down-left-right on a page did not work, so I had to go down and grab and move the horizontal scrollbar. Those of us who develop for the web know that people really hate doing that.

It is possible that Microsoft is betting on a huge move to touch devices being front and center for most business users in the future. I’m sure there is a happy story for developers and people who do a lot of data entry, but after an hour of playing, I don’t know what it is yet

Do you have it installed yet? What do you think?

There are two very common mathematical examples that are always used when talking about recursion in programming. The first is computing a Factorial and the other is the Fibonacci sequence. Who am I to buck tradition?

First, we’ll look at the Fibonacci sequence. The first 10 numbers of the sequence are 1 1 2 3 5 8 13 21 34 55.

Here is how we would implement that in Scheme.

(define (fib n)
    (if (< n 2)
     n
     (+ (fib (- n 1))(fib (- n 2)))
    )
)

That function calls itself recursively to figure out what the nth digit of the Fibonacci sequence is. So, if we'd like to see it print out in a chain, we can just call that function in a loop.

(let loop ((n 1))
  (if (<= n 10)
    (begin
     (display (fib n))(newline)
     (loop (+ n 1))
    )
  )
)

That looks like this:

A factorial (ex: 5! = 5 * 4 * 3 * 2 * 1 = 120) in Scheme would be coded simply like this:

(define factorial
  (lambda (n)
     (if (= n 0)
         1
         (* n (factorial (- n 1)))
     )
   )
 )

Here is something interesting. Because Scheme is dynamic with its type system and this function can return anything, I can actually work with really large numbers. For example, here I call the function twice, once with 5 to return 120 and the second time with 50 to return 30414093201713378043612608166064768844377641568960512000000000000. That is obviously WAY too big to be returned with any native .Net data type. Also, both of those calls returned as quickly as I hit Enter.

Up until now, there isn't much special about these recursive functions. However, Scheme does allow something that C# doesn't allow (well, it can in very special circumstances) and that is tail recursion. This is also (sometimes controversially) called tail optimization and is something of a hallmark of functional languages.

Traditionally, for every method/function/procedure call you are making in a language, you are building on the stack until that method/function/procedure returns. You see this all the time when you look at a stack trace while you are debugging. However, when you recursively call the same method over and over and over again, you risk a stack overflow. Imagine I wanted to find out what 50000! was. I would be putting 50000 function calls (all to the same function) on the stack and depending on the architecture I was on, I could overflow the stack (on my Macbook Pro, it did return after a few minutes with a VERY large number - pages and pages of scrolling).

What tail call optimization does is "discard" the stack up to the point when it calls itself again because the function will just be returning itself, so it doesn't need to keep track. If that sounds wayyy insane, let's think about our terms. First "tail position" refers to the last thing that happens in a function before it returns. In the case of tail recursion, the last thing that occurs is a call to the function itself. Even though it looks like my factorial example from earlier might be tail recursive, it really isn't. Here it is again.

(define factorial
  (lambda (n)
     (if (= n 0)
         1
         (* n (factorial (- n 1)))
     )
   )
 )

Take notice of the last line: (* n (factorial (- n 1))). You see how the last thing the function does is multiply the number passed in (n) against the result of the function called again with "n minus 1". So, we can't just jump ahead to the new function and only return its results because those need to bubble up the stack, being multiplied against the function's original n all the way up.

What we need to do is track our own progress, so that the function doesn't need to be multiplied by anything outside of itself. One thing we could do is just take the accumulation as a second parameter, but that is relying on the caller of the function to kind of do something unnatural and not obvious when calling the function. What we'll do instead is declare a local function inside of our function and call this local function with our parameter and a variable that accumulates and tracks our state.

The factorial function in full tail-recursive glory could look something like this

(please note: this isn't formatted the "Scheme-Way" because I was trying to make it as readable as possible)

(define pete_factorial ; our function
 (letrec ; defining something here with local scope
  (
   (inner_factorial ; a locally scoped function
    ; local function is a lambda taking 2 params
    (lambda (the_number our_accumulator)
     (if (= the_number 0) ; if the number passed in is 0
       ; return the current accumulation
       our_accumulator
       ; else call the local function again with the decremented
       ;number and an up-to-date accumulator
       (inner_factorial (- the_number 1) (* our_accumulator the_number))
     ) ;closing the if
    ) ; closing the lambda
   ) ; closing the inner function def
  ) ; closing the letrec body
; actual pete_factorial definition is a lambda
(lambda (actual_parameter_passed_in_to_pete_factorial)
  ; lambda body that calls the local function with the param and
  ; an initial accumulator of 1
  (inner_factorial actual_parameter_passed_in_to_pete_factorial 1)
) ; close lambda
) ; close pete_factorial body
) ; close define statement

Hopefully, that is fairly clear. I've actually had this post in the hopper for some time while I wrapped my head around exactly what we were accomplishing here. Then, when I thought I had it and it was time to write, I still wasn't prepared to explain it clearly. I hope that the combination of the formatting, comments, and verbose variable names helps you to understand it. I know that it helped me out a great deal.

As I've said, our basic goal here is to keep the stack from having to keep track of our state. In the original one, it worked out to be something like

factorial(5)
5*factorial(4)
5*4*factorial(3)
5*4*3*factorial(2)
5*4*3*2*factorial(1)
5*4*3*2*1*factorial(0)
5*4*3*2*1*1
120

In my severely-commented tail recursive case, it doesn't have to do that. It loads the function onto the stack and it keeps it there. Every definition describes that it basically does a GOTO and just keeps calling back to the top of the function (the inner function) over and over again. Because we keep our own state, the last thing to evaluate is just returned because the last value of the function is the answer.

This time, it is:

(pete_factorial 5)
replace arguments with (5 1), goto "inner_factorial"
replace arguments with (4 5), goto "inner_factorial"
replace arguments with (3 20), goto "inner_factorial"
replace arguments with (2 60), goto "inner_factorial"
replace arguments with (1 120), goto "inner_factorial"
replace arguments with (0 120), goto "inner_factorial"
return 120

I know we've covered a lot here, but this is good solid computer science stuff. It definitely doesn't hurt to think about it from time to time and really understand what is going on with the computer and within our languages when we write our code.

If you have any questions, or want me to try to clarify something, let me know in the comments and I'll do the best I can.

In our last example, “result1″ and “result2″ were simple return types. If you wanted, the “result1″ or “result2″ could also be functions that are evaluated to get a return value. Let’s look at that.

In this case, if 4 is greater than 0, we are going to multiply 4 times 4, if 4 isn’t greater than 0, we are just going to add 4 plus 4.

(if (> 4 0) (* 4 4) (+ 4 4))

You can see that because 4 is greater than 0, it executed the first block which evaluated 4 * 4 which is 16. Like last time, here is the equivalent C# version to hopefully add clarity.

if (4 > 0)
{
     return 4 * 4;
}
else
{
     return 4 + 4;
}

One of the most powerful things you can do in a functional language is – of course – to define your own functions. Here is a simple function that defines a function named pete that squares a number passed to it.

(define pete (lambda (x) (* x x)))

So here, we are calling the define language construct (which is how you declare variables, functions, etc in Scheme) and defining “pete” which is a lambda that takes one parameter – x – and returns the output of the * function being passed x and x. You see that if we call the pete function and pass in 7, it returns 49 as you would expect.

Functions are first class citizens in Scheme, so you can pass them around as arguments. Let’s see this example where I’m going to let us “do-stuff-to-four-and-nine”. My goal here is that we are going to create a function that takes a function as a parameter. It then calls that function, passing it 4 and 9.

So, first the function. (I used a hard return in the REPL window so that the screenshot below would definitely fit. It does not cause a problem in the language to have it there).

(define do-stuff-to-four-and-nine (lambda (our-func) (our-func 4 9)))

All I’ve done is define “do-stuff-to-four-and-nine” as a function that takes a parameter (our-func) that I then use in the body of the lambda, calling it and passing 4 and 9 as arguments. Next, let’s define 4 functions that we can pass to our “do stuff” function.

You should be able to simply read these by now. All four take two parameters, and are plainly named for the simple operations they perform on them.

Now, all that is left is to call the “do-stuff” function and pass it each of these functions in turn.

Interestingly, the function must take the right number of arguments. If not, the language throws up on you. Notice here that I define a function that only takes one argument. Then when I try to pass it in to our “four and nine” function, I get an error.

I hope that you’ve learned a little bit more about how Scheme works and how powerful it can be. My next post is going to take a look at recursion in Scheme and putting a lot of these lessons together.

I thought that I’d check it out and I saw that it was written in Scheme. I personally hadn’t spent any time in LISP or any LISP dialects, so it seemed like something interesting to dive in to.

On my Mac, using Homebrew, it was a breeze to get started. At first, I just typed

brew search scheme

I found what I was looking for and then typed

brew install scheme48

Here is an example of what you would see installing it on a Mac.

That’s it! (if you are on Windows, you can get install instructions here)

The only things I knew about Scheme were that it was functional and there were a lot of parentheses. I was right on both accounts. Aside from a few exercises where you were to type a number and have it spit back out to you, the first thing you run into is this:

(* 2 2)

Well, at first glance, stuff like that will throw you a little bit. However, with only a little bit of thought, you can see that it makes perfect sense. We have to think functionally. The parentheses tell us that this group is all one function call and reading left to right we see that we are calling the multiplication function – the * – and passing in the numbers 2 and 2 as arguments. That’s it. So (* 2 2) outputs 4 and (* 2 3 4) outputs 24. Also, we need the parentheses. Without them, you don’t get the desired result as you can see below.

What about control flow? That, too, is very simple. The syntax is simply (if (condition) result1 result2). It is very similar to an IIF statement, but without the commas. If you take this code, you get the result pictured below.

(if (< 4 5) "four is less than 5" "four is not less than five")

If you are having any trouble making sense of it, it might be helpful to think of this code in terms of how it breaks out in C#

if (4 < 5)
{
     return "four is less than five";
}
else
{
     return "four is not less than five";
}

I hope that if the Scheme code was confusing to you, that the C# translation helped a bit. You'll notice that just as a Ruby function returns the last thing that was evaluated, so too does Scheme. That's why there are no return statements in my Scheme example, but there are in the C# example.

Next time, we'll look at more complex if statements and travel down the functional road a little further.

If we keep the “Software Developer As Craftsman” metaphor, a carpenter might have 10 years of general carpentry skills, or 20 years at furniture making. What a carpenter would never really need to put on a resume is:

• Hammer – 20 years experience
• Manual Saw – 20 years experience
• Table Saw – 18 years experience
• Router – 14 years experience
• Clamp – 20 years experience
• Sandpaper – 20 years experience
• Belt Sander – 19 years experience

For an experienced carpenter, it very rarely matters what his toolset is, it matters what skills he possesses. The tool often just offers an easier or faster way to do something he already knows how to do.

With so many things changing so quickly in software development, it really is the skills that matter. It is possible to have almost 30 years of object oriented programming skills. You can have 15 years of skills with the web. You can’t have 5 years of experience with .Net 4 or 10 years of experience with Rails.

As “new and better” things are constantly released, it really is the skill that is transcendant, while the tools come and go. The proven ability to learn the tool is even a skill, but the act of knowing the tool alone is not. I am great with a hammer, but I couldn’t build you anything from scratch. In that same way, someone who only knows the C# language isn’t necessarily going to be any good in some enterprise shop or someone who only knows Ruby isn’t necessarily going to be the person you want to have as the only employee at your start up.

I think that I’ve almost always agreed with Phil, but I never really had the idea codified in my head so succinctly. I’m not saying the tools are worthless (obviously, a carpenter becomes very familiar with his tools – as should we), but I do think that we as programmers are almost worthless if we don’t hone the things that are transcendent skills.

Cameron is writing from the perspective of a Startup Company. He does make an exception to the overtime rule for the founders, but for his employees he says,

There are no heroes at our office. When the clock strikes five,
the team goes home. If they try to keep working, I tell them that
the game's over and they lost. They either put too much on their
plate, got taken off-task, or were wasting time. None of those
justify working past five, on a holiday, or over a weekend.

I certainly applaud his motiviations. He sticks to this rule even when clients ask for it, when they’d need it to win new business, etc. It is one of his company’s core values and they stick to it. Everyone realizes that when an employee (especially a salaried one) works overtime, he is “doing more than he agreed to” and is “taking away family time” and “upsetting the work/life balance”. However, what I find interesting are some of the reasons that their company takes that choice away from their employees.

One major reason that Cameron cites is that to persuade employees to work overtime, the noble concept of “sacrifice” is invoked. In his mind, soldiers, firefighters, and police officers sacrifice, and to try to align that concept with “expected overtime” is a dangerous habit to get in to.

He points out that the employees who work over are the “heroes” and those who don’t are “losers who let you down”. In his words, “Yearly reviews just got a whole lot easier”. Later he says, “How could I promote a loser when they’re surrounded by winners?”.

I want to deal with that point first. He is obviously being rhetorical and a little sarcastic with those last quotes, arguing his point to ad absurdum. However, I think there is a point to be investigated there. My current boss has taught me a lot about managing people and the value of making “the hard decision”. It sounds to me like Cameron is welching a little bit on managing employees. Sometimes, you have to make the hard choices. As my boss likes to say, “Who do we pay to do the hard stuff?”.

Imagine on one hand that you have an employee who works only 40 hours and is very productive, gets along well with others, is a leader, and so on. Now, imagine you have another employee who works a ton of overtime, but you know that it is because he isn’t very efficient. He has a good work ethic and to make up for his lack of efficiency (and “social time” during work hours), he tries to even it out with that overtime. Now, if you are a manager who can’t promote Mr. Productive Forty and explain to Mr. Compensating why he didn’t get the job, you aren’t much of a manager and should rethink your career path.

Let’s pretend there is another scenerio. This time, you have two very equal employees. One of them is a “5:01 Developer” (gone by 5:01 every day) and the other works over to make sure things get done on time, or to add special features off of the “nice to have” list that never gets prioritized ahead of “big projects”. In that case – all else being equal – why wouldn’t you promote the overtime guy?

These kinds of decisions are why you are the person writing the reviews.

A point that Cameron makes alongside this one is the concept of burnout. This is definitely a very real problem. However, I feel that he’s again arguing to take the “copout” path. He seems to be claiming that it is impossible or would require too much work to monitor and make sure that his employees aren’t burning out. There is a big difference between running a guy at 80+ hours a week for months at a time, working 1 or 2 60-70+ hour weeks before huge release, and regulary working 50 hours a week because that’s what you are comfortable working.

As I admitted earlier, I definitely work overtime. I am soon taking my first vacation week in years (only because the company stopped paying out for unused time – I have to “use it or lose it” and I’m too practical for that ). However, I’ve been going at this pace for about five years straight now, across 2 companies. I’m not close to burnout. You can’t manage people homogeneously, you have to manage to the individual. I’m more of a sports car, not a minivan, there is no danger of running the engine at a little bit higher speeds.

I’m not bragging. My point is that I’m different than other people and a team needs all kinds of people on it. The Apostle Paul actually writes to this point quite eloquently in the Bible in 1 Corinthians 12:14-21:

Even so the body is not made up of one part but of many.
Now if the foot should say, "Because I am not a hand,
I do not belong to the body," it would not for that reason
stop being part of the body. And if the ear should say,
"Because I am not an eye, I do not belong to the body," it
would not for that reason stop being part of the body. 

If the whole body were an eye, where would the sense of hearing be?
If the whole body were an ear, where would the sense of smell be?
But in fact God has placed the parts in the body, every one of
them, just as he wanted them to be. If they were all one part,
where would the body be? As it is, there are many parts, but one body.

The eye cannot say to the hand, "I don't need you!" And the head
cannot say to the feet, "I don't need you!"

There are things I do well and things that I don’t do well, and I realize that I don’t always see them clearly. The way that that is remedied is that my team is made up of all sorts of people. The person building the team knows what he has, and fills the gaps appropriately. The fact that I can easily work 50 hours a week or more without burning out is just a tool that my company has at its disposal, just as all of the other skills of employees are at their disposal.

One point that I just could not grasp in Cameron’s blog post was the fact that he is willing to let his clients down because of this overtime policy. Even if the work completed because of overtime would win their clients more business or help solve a serious problem that they are having, overtime is still off limits.

I see nothing wrong with working over to win new business, for you or for one of your clients. Your client has likely worked with others who cannot deliver these things and you make yourself indispensible to him as someone who can deliver them. But again, there is the potential for abuse, but that relies on your client service managers or account representitives to “do the hard stuff” of recognizing and stopping abuse before it gets anywhere.

As I was discussing this topic with a good friend of mine, he pointed out to me that one problem he had with overtime was that it “excused” or “covered up” poor planning. For instance, if a project was projected to have 15 features and be delivered in 2 months, but was estimated poorly, that can be a problem. Proper Agile philosophy is to have the business either extend the date based on the metrics from the iterations, or cut features. Another approach is for it to still spend the hours, but spend them in 60, 70, or 80 hour weeks to meet the deadline. That’s a “death march” and no one really wants that.

However, sometimes it is politically expedient to deliver the project by working the overtime. Not everyone works at a company that can afford to turn down external clients or at a consultancy that can easily refuse work. A good deal of software development is done as part of an “in-house” shop that develops software for “an enterprise”. There are 100 ways that you can curry favor by seemingly doing the impossible and those who don’t see the value in that don’t have a very mature view of the “real world”.

However, the issue then comes if you don’t learn a lesson about your estimating and back yourself into those kinds of corners on project after project. Again, I fall back on “Who do we get to do the hard stuff?” If your Project Managers can’t control these projects from the outset, you probably have the wrong people in there.

This has definitely been one of my longer rants and I know that a lot of people will disagree with me. Feel free to leave a comment below, or blog your own responses. If you do a reaction blog, please link it in the comments so that I can read the discourse and the other readers may benefit, as well.