Thursday, April 30, 2009

Stuff I Have Found Interesting Today

A time management techniques based on 25 minutes of concentrated work and 5 minutes of recovery. I haven't been this strict, but my experience says that amount of time is probably correct. You can download a free book if you want to.

I was never a big Firefox user, but now I use Chrome everywhere I can. This guy explains why.

Wednesday, April 29, 2009

Stuff I Have Found Interesting Today

The latest fom Jurgen. It gets high marks for using one of my favorite phrases "Illusion of control" and for this gem "The reason to empower people is not to improve motivation, but to improve manageability."
Sadly I have done many of these :-(

Some good points on communication and social media. I would have cut out the politcal propaganda, but it isn't too bad. Do you believe that "Words just form 7% of our communication..."? My experience agrees.
Post on scrumdevelopment Yahoo Group in response to a generic question. Gives lots of links and ends with a nice summary of why one-week iterations don't have more overhead, but instead have less. I wish I had written than in my post Why I Recommend One-Week Iterations.

"Next time you see a statistic in a news story that's hard to believe, or needs a bit more depth, type it into Google and pull up your own data graph."

Team City 4.5 Released 
Didn't know what this was, but sounds cool! "TeamCity is a continuous integration and build management system. With TeamCity, you can set up a build server within minutes and enjoy out of the box continuous unit testing, code quality analysis, and early reporting on build problems — even without leaving your favorite IDE."
I'm not this nerdy, but maybe you are.

Tuesday, April 28, 2009

Stuff I Have Found Interesting Today

Keep It Simple, Stupid

Old idea on new technology. Why is it that the simplest rules are the most often broken?


David Anderson nails this one on the head. I think his article applies to all corporate initiatives. Some gems:
  • "The problem with these transition initiatives, and their champions, and their change agents, and their sponsors, and their improvement projects, and their quality teams, and process experts, and black belts, and green belts, and funny handshakes, and secret rituals, and coded handbooks, and group hugs and therapy sessions is, quite simply, they don't work!"
  • "By giving the transition a name, the management has given the workforce a new hate object. Something to despise!"
  • "Continuous improvement is everyone's business!"

8 must read papers for project managers
Pronounce Names
Good idea for those working with foreign born folks on a daily basis.
The World in panoramic 
Interesting concept, although most of the pictures are in Europe.

Gall's Law
My personal experience agrees with this, but I am biased.
Interesting take on enterprise integration. Links to a Arnon calls a Knot ("A knot is an Anti-pattern where the services are tightly coupled by hardcoded point-to-point integration and context specific interfaces"). Not really my area of concern, but it is interesting.
Charles Krauthammer says what I have been thinking for a while "In the end, the spinach must be served." Althought I would have used kale as I like spinach.

Monday, April 27, 2009

Stuff I Have Found Interesting Today

I great read and a must read for any one who buys too many management books. If you read it all the way you will find a few gems (e.g. "In a sense, management theory is what happens to philosophers when you pay them too much.")
Fascinating little story about how a non-native speaker learns the order of adjectives in English. I hope I remember this next time I am writing.
Iteresting how they save money, energy & get more out of your hardware in their newest data center. Those Googlers sure are smart. 
Re: How much refactoring?
Ron continues with an even better anology for software and refactoring: Driving a car and steering. Followed by some back and forth and ending in post 38044 by Ron again. Good stuff for those that aren't rock solid on Refactoring.


Rehire Every Employee, Every Day

Oswald Chamber's daily devotional was quite enlightening to me today.
I discovered a new blog assertTrue() and thus a list of his posts:
Another blog, recommended by the overlords at Google: Gemba Panta Rei
  1. Logical Thinking Process
  2. Objectivity
  3. Results and Process
  4. Synthesis, distillation, and visualization
  5. Alignment
  6. Coherency within and consistency across
  7. Systems viewpoint

Sunday, April 26, 2009

Stuff I Have Found Interesting Today

In Defense of Eye Candy

Interesting article by Stephen Anderson on how/why pretty design is important.

Title doesn't say much, but the article has some good points.

10 rules for great development spaces

I would call it a wish list instead of rules, but I'm not going to split hairs.

Mark Needham explains several ways to make unit testing fun (TDD is the obviously mentioned). He describes a new term for me "Ping Pong Pairing" one person writes the test, the other write the smallest clean code to pass it, swap rinse repeat. I'll have to try it next chance I get.

Saturday, April 25, 2009

Stuff I Have Found Interesting Today

Stand and Deliver Revisited 

Sad story after such an uplifting one. I wonder if we will ever get over the politics of education.

The Scatology of Agile Architecture

Uncle Bob making sure people realize 180 degrees from bad is still bad. BDUF is bad, but NO-DUF is stupid. 

Go Directly to Jail. Do NOT Pass GO .
I love the SCRUM cartoon.

My Quick Oversimplified ASP.Net MVC Pros and Cons

An overview of ASP MVC that seems even handed. I have no experience with it to make any other judgment.

The Economics of Breastfeeding: A Cost-Benefit Analysis 
from PhD in Parenting. This looks like classic over analysis, but it is interesting for those that are at that stage in life

Haven't read it all, but some heavy weight authors: Mary Poppendieck, Robert C. Martin & Scott Hanselman

Friday, April 24, 2009

Stuff I Have Found Interesting Today

Jurgen is writing a book in a very interersting way. I love the quote "So think twice before you comment on my blog posts. I will make fun of you in my book." as he and I did get into a comment arguement last year sometime. I might have to get his book to see if I am made fun of.

Scott educating the masses on an aweomse open source tool.
Good story about how a scrum master that took initiative and changed one of the untouchable scrum practices, the standup). He made it better for his team. It was sad that he was afraid of posting it because of backlash. Why do people take rules made my humans and cling to them as if they were made by God?

Re: Lean Study Tour - Day 3: Bad News First

An interesting exchange between Kent & Ron. I remember reading about Appreciative Inquiry a while ago...maybe I will have to give it a second look. Further down in the message trail some posts An Appreciative Retrospective by Diane Larson. Seems like a good start since Barnes & Nobles doesn't carry "The Thin Book of Appreciative Inquiry" in stock anywhere in Richmond!


Re: How much refactoring?

Message thread on the Scrum development group that makes some excellent points. Here is my favorite excerpts:
  • "I try only to have a perfect design for right now. I never even manage that."
  • "Less refactoring makes it take LONGER! Refactoring is no more waste than is sharpening your tools."

The Software Craftsman's Ethic 
From the Software Craftmanship Google group is an interesting document:
We Care
We consider it our responsibility
  to gain the trust of the businesses we serve;
    therefore, we
      take our customer's problems as seriously as they do and
      stake our reputation on the quality of the work we produce.
We Practice
We consider it our responsibility
  to write code that is defect-free, proven, readable, understandable and malleable;
    therefore, we
      follow our chosen practices meticulously even under pressure and
      practice our techniques regularly.
We Learn
We consider it our responsibility
  to hone our craft in pursuit of mastery;
    therefore, we
      continuously explore new technologies and
      read and study the work of other craftsmen.
We Share
We consider it our responsibility
  to perpetuate the craft of Software;
    therefore, we
      enlist apprentices to learn it and
      actively engage other craftsmen in dialogue and practice.

Thursday, April 23, 2009

Stuff I Have Found Interesting Today

Japan’s Weird Unemployment Solution

Crap Code Inevitable? Rumblings from ACCU.
I agree with Uncle Bob on this. There was a book I read once called "Quality is Free". It was targeted at manafacturing, but the essence is true for many things (including software). Quality produces lower defects which are expensve to fix. Thus keeping "crap" out of the software is like exercise. it costs some time up front, but is way cheaper and less time consuming than a hospital visit.
This guy has some good points and some good jabs. I think I just might have to learn javascript after all :-)

Wednesday, April 22, 2009

Stuff I Have Found Interesting Today

From Susan Polgar's blog, Peace Pals Art contest for children ages 5-17

Integrity - I With a great quote for CS Lewis. Reminds me of a quote I heard from a friend "Management is easy once you let go of your integreity".

Social Networking for Developers Funny repsonse to Scott Hansleman's StackOverflow Question - How can social networking sites make you a better developer? Faily short good read.

Jurgen Accountable or Responsible? light but I like the quote that he borrows from another post that borrowed it from a newsgroup entry "So I TAKE responsibility and I am HELD accountable."
Why Do You Care About What “Everyone” Else Does? puts into words what I was thinking when I saw Jurgen's survey. For the record I didn't think it through this clearly, but luckily she did.
Is Git more than just a version control system?  Fascinating read on using Git as a backend for a database

How Apple Co-Founder Steve Wozniak Gets Things Done Interesting that he uses Eudora...I remember that name, but that's about all. Gotta love the picture at the end....guess which one is the geek?


A Modest Proposal for the Copy and Paste School of Code Reuse is rather long for such a short point, but maybe he didn't have enough time. The suggestion at the end sounds good to me:

What I propose is this:

// codesnippet:1c125546-b87c-49ff-8130-a24a3deda659

- (void)fadeOutWindow:(NSWindow*)window{
        // code
Attach a one line comment convention with a new GUID to any code snippet you publish on the web. This ties the snippet of code to its author and any subsequent clones. A trivial search for the code snippet GUID would identify every other copy of the snippet on the web:

Why estimate? Is estimating due to lack of trust? I'm not sure I agree with everything in this, but the key point I took away was make sure you are spending the appropriate amount of time on the estimates. Take the value in consideration. I like estimated, but I only spend about 2-4 hours a month on them.
Two posts that tell me that middlemen of all types beware, the internet is a great middleman: 

Martin Fowler is writing a new book on DSLs and he has this page for those that want to read drafts 

Tuesday, April 21, 2009

Stuff I Have Found Interesting Today

Freakonomics had The True Cause of College-Tuition Inflation? which has me hoping they get it before I have to pay for it.

I found Scott Berkun from and he had some interesting posts.  Advice for new managers and Top ten reasons managers become great on management.The most interesting was Job loss map (coolness & badness) which basically just point you to which is amazing for us visual folks.
Is the Supremacy of Object-Oriented Programming Over? from Object Mentor Blog by Dean Wampler is an interesting take on the current practice of OO and the rise of functional programming. It is a good read if you are interested in that stuff like I am. It talks a bit about concurrency which leads me to the next one.
Which links to The Free Lunch Is Over: A Fundamental Turn Toward Concurrency in Software. and is kind of a rebuttal to the it. I think the poster has some good points. One of my many blogs talked about the key to performace is getting the computer to do less. I think lack of simplication is what dooms most large systems and a focus on essentials will lead to better and faster systems.

In the Scrumdevelopment Yahoo group I found a post that made me go huh? Introduction and question about dividing a scrum team in which the guy wants to split his team into 3 2-person "teams" to parrallizwe the work stream?!?!? Ron's response put him in his place with the following recommendations:

0. Have a real PO set the priorities;

1. Do not split the team;

2. Work on things in true priority order;

3. Recognize that working on everything is not an example of 2.

What's weird is that I blogged back two days ago about a situation that wasn't too far off from this one situation. 

Monday, April 20, 2009

Stuff I Have Found Interesting Today

Jurgen's latest: Leader vs. Ruler: Which One Are You? BTW NOOP stands for "NO OPeration" Ididn't know that before today, I guess I gotta stop calling it nüp and start calling it no-op. It's agood read. Some sections I particularly liked:

  • "reading the book Tribes, by Seth Godin. In his book Seth says that never in history has it been so easy for anyone to be a leader. These days, with the use of social media, each of us is able to attract our own followers. And on Twitter, this is exactly what we're doing (quite literally). Seth explains that a crowd becomes a tribe when it has a leader that the people are following out of their own free will. And the interesting thing is that people can follow different leaders for different causes."
  • "in many social systems rulers can peacefully co-exist with leaders. For example: in any football (or soccer) match you will find leaders (one in each team) and rulers (the referees). They all play their parts in making the game work for everyone."
  • "To be a leader is not the next step for managers"
  • "It is the manager's job to give room to leaders"
  • "It's the managers' job to make sure that leadership is cultivated, and that the emerging leaders are following the rules."

From Freakonomics comes a discussion about an MBA course I interested in (trust me that's rare) “Using Experiments in Firms" from Don’t guess, experiment. Some quotes from the interview:

  • “The level of experimentation is abysmal. These firms do not take full advantage of feedback opportunities they’re presented with. After seeing example after example, we sat down and said, ‘We have to try to do something to stop this.’ One change we could make is to teach 75 to 100 of the best MBA students in the world how to think about feedback opportunities and how to think about designing their own field experiments to learn something that can make their company better.  
  • One example was a company that was told by consultants that sales surged when it advertised on television – without realizing that its advertisements appeared just before big holiday sales days."It wasn't that advertising caused their sales to go up but that knowing their sales were going to go up caused them to advertise a few weeks earlier.”

Levitt says in the blog entry "Thankfully, the reporter did not mention that most of the students hated the class." Gotta love his self deprecation.

Jeff's latest:How Not To Conduct an Online Poll

Basically a review of Inside the Precision Hack. I found this somewhat interesting, but was kind of shocked at the quote from the article "The poll announces (perhaps subtly) to the world, that the most influential are not the Obamas, Britneys or the Rick Warrens of the world, the most influential are an extremely advanced intelligence: the hackers."

WHAT?!?! Jeff's review is bit more tame "... is it really a precision hack when your adversaries are completely incompetent?". I think this guy is WAY off base, but he did the homework so you gotta give him some credit.

Sunday, April 19, 2009

Psychological Projection and the Geek

I have been following an interesting and somewhat contentious debate on the Yahoo XP newsgroup titled People vs Process. When post 150279 came across my screen I felt compelled to respond. What's interesting about this as I had a discussion with a co-worker about this from a completely different angle on Friday. She was expressing frustration about some one at work that I had expressed similar feeling about in the past. I think she was looking to vent, but I took the opportunity to explain that the problem we have with the person has more to do with us than them. Another connecting piece of information came from a podcast. I think it was SO #49, but it could have been Hanselminutes #158, all I remember is that is was Joel speaking.

As I recall Joel was talking about how programmers think and how they want to solve every problem they run across. In fact they want to treat everything like a computer program. They also get frustrated by the world they live in as it does not appear to be running an operating system. Thus the reason why most geeks never make good managers or business people. I resembled his remarks and it stuck with me through my day.

Back to my point if I can find it. Geeks typically suffer from a lack of the ability to see the world from outside themselves. They can certainly look at themselves (and everyone they come in contact) in a critical manner, but they really can't see themselves as others see them. Thus they are often baffled when they find out other people's opinion of themselves. If you are still with me then you either know a geek or you are/where one and that's OK.

Here is where Psychological Projection comes in. Here is my take: when there is conflict between a geek and another (doesn't really matter if the other person is a geek or fact if they are a geek the conflict seems to be worse) the root cause of this conflict is that the geek projects their thoughts, motivations, desires, feelings, and so on onto the other person. Thus their own insecurities come out. Here are some examples (these are not translations for all such statements):
  • "He's an idiot" -> I am insecure about my intelligence as I place my self worth upon it
  • "He's selfish" -> I wished I got more attention
  • "He just doesn't get it" -> I wish I was more important so people would listen to me
I hope this helps you to understand geeks and if you are a geek please take some time to read up on this important physiological concept and I hope I didn't butcher it.

Saturday, April 18, 2009

Handling Multiple Small Projects

Anyone who has worked in IT has had the situation in which you are assigned to more than one IT project. For this post I will use the term IT project to mean a body of work needed to accomplish a recognizeable business function. It may touch one system in one file and it may touch 7 systems in 11 different ways each. Typical IT management thinks like an accountant:
Let's see, I have 6 1-month projects and 3 developers  (Mark, Luke & John). I'll give 2 each and tell the customer that they will all be done in 2 months! Man I'm good.
Obviously this is a straw man, but it is the general thinking I have seen and read enough times to believe it is prevalent. The only way I know to analyze this is with some basic math. Let's assume that the estimates are accurate. Let's assume that each developer is equally productive (lets call it P). Let's call the work to be done on each project W1, W2...W6. Lets call the time to complete each project T1, T2...T6. So the basic formula is Tn = Wn/P.

All seems good, but IT work doesn't work like painting a fence. In painting a fence if you have painted 1/10 of the fence in one day you are pretty sure than in 10 days you wsill be done. IT work almost always follow an S curve.
You start off getting little done, followed by moments of massive productivity, followed by some painful moments of finishing/fixing the project. Agile/Lean techniques can help straighten out the curve, but it still isn't a line and I'm not sure it's a healthy goal.

So if Mark is working on projects 1 & 2 and 1 happens to get hard Mark is likely to spend more time on 1 than 2. Which means 2 suffers becuase 1 was got hard. So instead of finishing them both in two months they both slip a week or three. The other problem is that it is a known fact that focusing one one project at a time is fater than focusings on 2.

Another problem is the poor return on investment. By definition, IT projects are being funded by a business of some sort. This business usually spends money for one of two reasons, either it will save money or increase sales. Accounting 101: Time vlaue of Money (PV = FV/(1+i)^n) means the early you save/make the better off you are.

Scenario A (projects in parrallel)
PV1 = FV1/(1+i)^2
PV2 = FV2/(1+i)^2

Scenario B (projects serial)
Project 1 goes first
PV1 = FV1/(1+i)^1
PV2 = FV2/(1+i)^2

PV2 in both scenarios are equal and it we assume i>0 (which is true except in cases of deflation) then PV1 for scenario A is always less than PV1 for scenario B. BTW this even assumes the two scenarios take the same amout of time.

Therefore delivering 2 projects in 2 months is worse than delivering 1 project per month. The key in any time management course/book/workshop/blog is focus on the important things first. The key to multiple projects is getting the business to prioritize and have IT to focus. 

In my little example let's assume the number represents the priority. I would get the 3 developers together and have them decide the most productive way of tackling the list. They might decide they all can contribute to 1, but only one has the knowledge for 2 and while that is going on the other two can tackle 3 and so on and so forth. Then have them use an estimation technique (e.g. planning poker is fun and has on-line support).  Do some simple planning to come up with estimated completion dates for the customer and you are going to do better than most. Of course, if you have a true Agile team then simply work them in priority order.

Friday, April 17, 2009

Stuff I Have Found to be Interesting Today

The Marshmellow Test - willpower via distraction, was interesting.

Jeff Atwood has a new entry: Exception-Driven Development. Great opening picture and some great advice. He does get TDD confused with unit testing everything. Nobody's perfect.

Esther Derby has a good post on Five Ways that Team Members Build Trust with Each Other. She led me to this good post on Feedback. This is an issue I struggle with. I have always loved the the perfection game in the Core by McCarthy.

Freakonomics shares some info that disturbed me. 70k$ to run for mayor of Rapid City, SD every two years and it only "pays" 90K$/year?!? Politics has become a strange/scary world. 

Thanks to the power of Twitter I found 10 Programming Proverbs. Great humor, wisdom and pictures to boot.

On the yahoo group for XP there is a thread that started as One project per person X One project per team and has evolved into "People vs Process". The real action begins with post 15015. Here are some posts I have read and enjoyed:
  • 150128:Talks about a good way of managing a difficult situation brought up
  • 150181: Has Ron trying to explain that the person isn't the problem
  • 150219: Has another trying to explain the same thing differently
  • 150232: more clarification of the problem...
  • 150272: Ron will not let this one go
It is still going on...and may never end :-)

Saturday, April 11, 2009

The Animal - a geek's tale about a vacuum cleaner

The last two vacuum cleaners we bought were the top rated by consumer reports. My wife's opinion of them, in a play on words, THEY SUCKED. She was using our latest one in an effort to clean the house when it billowed smoke and stunk up the whole house. Two positives came out of this. The first was a house full of fresh air. The other was that she picked the next vacuum cleaner, the dyson DC-17.

This vacuum looks like a geek designed it and belongs in the engine room of a space ship. It has what looks like in-take valves on top (in purple), leading into a clear bin with a metallic grey base. I don't do it justice in either words or photos.

When I opened the box I actually wanted to clean the house. Luckily, the feeling wore off before I could act. It took more time to get it out of it's tightly packed box than it did to assemble. My wife immediately gave it a test run on the foyer rug. Before she was done with the rug the fairly large bin was filled. Mind you we hire a cleaning service and they vacuum that rug every two weeks! 

One grey button poress and the bin is removeable by the clear handle on top. She walks over to the trash can and presses a bright red button and viola the bin is emptied. After replacing it and finishing the rug she the pulls out the wand. To do this all she has to do is pull the red handle up and the wand assembly detaches from the main unit. The suction on this wand is scary. Keep it away from small animals. We love it and we haven't even used the three impressive looking attachments.

If you can afford the high price I highly recommend it.

Saturday, April 4, 2009

The Geek's Role in Business

I'm a geek. I like understanding how things work and sometimes it just doesn't matter what that thing it. I think it's cool that Pete Brown is writing a C64 emulator in Silverlight. I was mesmerized by the inner working of CouchDB. I even find musings of a different way of organizing a company interesting. I have a reached an age in which I embrace what I am.

One thing I have witnessed over the years is that business people need geeks to make/support the things they sell. This is helpful as they pay pretty good. I have also witnessed that many geeks think they are smarter than the business people because they are more logical. I once believed this nonsense. I now know that each person has their role to play in the ugly game of making money. The geek's role is actually pretty well defined, but for some reason most geeks seem to overstep their bounds.

The geek's role is to provide options to the business person(s) and to clearly articulate the advantages and disadvantages of each. The geek's role is not to make that decision or even influence it. A good business person can actually understand the advantages and disadvantages and make a good business decision without your input.  They don't even owe you an explanation. They are responsible for making the money that makes it way to your bank account. The geek knows a lot, but is not all knowing (yes even you).

Agile Software Development is the first process framework for software that I have seen that tried to make this distinction clear. I find that when Agile is practiced well the customer is forced to make decisions (something they aren't use to in traditional disfunctional processes) and the developer gets to provide options and make all purely technical decisions (I find there are really very few of these). If you are a geek or in the role of a geek remember to provide options and help the decider understand the advantages and disadvantages of each. There are ALWAYS options. You should provide them even if you don't like them. It's kind of like eating a vegetable you didn't like as a kid. Just smile and do it!

If you employ a geek, be patient they mean well.