Archive for November, 2011

Technical Debt – MIT says its expensive

Friday, November 18th, 2011

“… findings from the MIT Sloan School of Management, Agile businesses have a huge “Return on Agility”: 29% higher earnings per share; net margins at over 20%; the return on assets are greater than 30%; and revenue growth is a steady (always important to Wall Street) 8% or more.”

http://blog.castsoftware.com/the-financial-implications-of-technical-debt/

 

So technically, MIT says that Agility is good for business, but the rest of the article talks about how technical debt can take a smoothly running agile business and grind it to a halt with a very quick negative feedback loop.

 

If you have business people who are pushing for “more functionality now, you can fix it later” this article could save your sanity.

Software Developers and Capitalism – The $10,000,000 question

Wednesday, November 16th, 2011

Software developers seem to have a genetic defect when it comes to understanding the relationship between the work they do and the pay they receive.  This is not a good thing, and it is not going to change.  The reasons seem to come down to hubris and an unconscious attitude of “We don’t want to change and you can’t make us.”

My friend Nick Malik  once wrote about the subject in programming, contracting and pay.  There is room for an entire genre of books in this subject, but sadly, no market.  Approximately 99.99% of developers do not buy books about business or money, and therefore it’s not worth writing about it.

This is too bad because software developers often end up looking for work while blind to their true value to a business.  Software developers seem to understand that “my work is worth $x.xx an hour” but they do not understand the WHY behind it.  Their job worth intelligence score is very low.

 

You on the other hand are someone who is somehow interested in how businesses make money, and you are also not satisfied with minor linear pay raises.  In order to get 20 – 50 percent pay increases a year, you have to raise your job worth intelligence.

Here’s a quick little story problem to test your job worth intelligence.

Let’s imagine that company JKL has a particular job function (FooBar) that has to be done.  That job function will have to be done for at least the next 6 years.  The FooBar job function is so important that there’s even a FooBar department with 100 dedicated people performing the FooBar job function.  Every one in that department makes $50K annually.

JKL has access to a consulting group which offers a tiger team of 5 expensive programmers, each of whom cost $200K annually.  This tiger team has a track record of completing their projects on time and on budget.

The tiger team says that they can, in 1 year, automate the FooBar department such that the department can effectively cut %50 percent of it’s staff, immediately, at the end of the project.

The tiger team has one additional contractual item.  On successful completion of the project; each of the 5 tiger team members will be paid an additional $100,000 per year for the next 5 years.

Questions

  1. Is this a good deal?
  2. If you are the CEO of JKL, why would you hire or not hire the tiger team?
  3. How long would you have to think about it?
  4. By how many dollars will JKL’s bottom line be moved by doing this project?

 

Originally published by Malcolm Anderson on 13 July 2007 at
http://groups.yahoo.com/group/scrumdevelopment/message/24271
minor edits have been made for clarification

One Secret To Writing Understandable Unit Tests

Wednesday, November 2nd, 2011

Here’s a quick secret to writing understandable unit tests.

 

Name your object under test, the lower case letter o.

 

As in object.

 

As in

Foo o = new Foo();

 

The value of this approach is that in any test file, it’s very easy to determine what a particular test is trying to accomplish.

“What test class am I in?  The file name is Foo_Test.  In this case, o must be Foo”

 

It also reinforces the idea of one test class per application class.

 

Either way, when you come back to look at your code, you’ll be surprised at how easy it is to figure out what your intent was.