raganwald
(This is a snapshot of my old weblog. New posts and selected republished essays can be found at raganwald.com.)

Friday, October 07, 2005
  Just do it


Eric Sink has some terrific advice:
You could spend a lot of time trying to figure out if this idea is any good, and at the end, you wouldn't really know. Alternatively, you could spend the same amount of time implementing this idea, after which you will have the opportunity to really find out if it's any good.
Small Ideas
I could link this over to my own struggle to get my idea out of the garage and (at the very least) sitting in the driveway where my neighbors can think up polite ways to ask "WTF?"

But really, this principle is so simple we should look for it in far more places. Isn't this the foundation of iterative development? Can you make a wireframe or mockup or prototype faster than you can draw a pretty UML diagram?

What about selling agile practices? Which ones can you just do? Wouldn't it be easy to say "we've been trying X for four weeks and we've achieved Y and Z"? Isn't it far better to risk asking forgiveness than campaign for permision?

Why not just try pair programming? What's stopping you from just doing test-driven development on your own personal tasks? Is there any reason you can't use Cruise Control on your workstation even if the team doesn't buy into continuous integration? What's wrong with writing all of your tests in FITnesse and sharing the results?

I'll make you a deal. I'll stop wasting time writing this blog entry now if you will go ahead and think of one thing you could just go ahead and do.

You've got your idea? Ok, here's my 'end' of the bargain.

Labels:

 

Comments on “Just do it:
You know, I did this just two days ago. I do enterprise work in a corporation where "iterative" means once the analysis is done and the spec is signed off, the programmers will release code to QA a few times before it's tested. I'm tech lead on a project using a new platform that no one has any experience with, and my project manager keeps asking me how long it'll take to do my design doc. I barely have an idea what it'll say! Two days ago, after complaining that we never do anything iterative, I suggested that instead of doing a design doc, we should just start building a small prototype of the solution, using the platform. We'll get experience with the platform, and maybe it'll grow into the final product -- if not, it's small, so we can scrap it and start over. He's on board, and we're looking to co-locate the tech team. I think it'll work well. The thing that struck me, after my PM agreed to it, was how simple it was to just ask.
 
This post has been removed by a blog administrator.
 




<< Home
Reg Braithwaite


Recent Writing
Homoiconic Technical Writing / raganwald.posterous.com

Books
What I‘ve Learned From Failure / Kestrels, Quirky Birds, and Hopeless Egocentricity

Share
rewrite_rails / andand / unfold.rb / string_to_proc.rb / dsl_and_let.rb / comprehension.rb / lazy_lists.rb

Beauty
IS-STRICTLY-EQUIVALENT-TO-A / Spaghetti-Western Coding / Golf is a good program spoiled / Programming conventions as signals / Not all functions should be object methods

The Not So Big Software Design / Writing programs for people to read / Why Why Functional Programming Matters Matters / But Y would I want to do a thing like this?

Work
The single most important thing you must do to improve your programming career / The Naïve Approach to Hiring People / No Disrespect / Take control of your interview / Three tips for getting a job through a recruiter / My favourite interview question

Management
Exception Handling in Software Development / What if powerful languages and idioms only work for small teams? / Bricks / Which theory fits the evidence? / Still failing, still learning / What I’ve learned from failure

Notation
The unary ampersand in Ruby / (1..100).inject(&:+) / The challenge of teaching yourself a programming language / The significance of the meta-circular interpreter / Block-Structured Javascript / Haskell, Ruby and Infinity / Closures and Higher-Order Functions

Opinion
Why Apple is more expensive than Amazon / Why we are the biggest obstacles to our own growth / Is software the documentation of business process mistakes? / We have lost control of the apparatus / What I’ve Learned From Sales I, II, III

Whimsey
The Narcissism of Small Code Differences / Billy Martin’s Technique for Managing his Manager / Three stories about The Tao / Programming Language Stories / Why You Need a Degree to Work For BigCo

History
06/04 / 07/04 / 08/04 / 09/04 / 10/04 / 11/04 / 12/04 / 01/05 / 02/05 / 03/05 / 04/05 / 06/05 / 07/05 / 08/05 / 09/05 / 10/05 / 11/05 / 01/06 / 02/06 / 03/06 / 04/06 / 05/06 / 06/06 / 07/06 / 08/06 / 09/06 / 10/06 / 11/06 / 12/06 / 01/07 / 02/07 / 03/07 / 04/07 / 05/07 / 06/07 / 07/07 / 08/07 / 09/07 / 10/07 / 11/07 / 12/07 / 01/08 / 02/08 / 03/08 / 04/08 / 05/08 / 06/08 / 07/08 /