Website Home | Blog | Software | Reviews and Features | Forum | Help | Donate | About us
topbanner_forum
  *

avatar image

Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
  • August 31, 2015, 05:55:09 AM
  • Proudly celebrating 10 years online.
  • Donate now to become a lifetime supporting member of the site and get a non-expiring license key for all of our programs.
  • donate

Author Topic: What is "cowboy coding?"  (Read 3140 times)

zridling

  • Friend of the Site
  • Charter Member
  • Joined in 2005
  • ***
  • Posts: 3,292
    • View Profile
    • Read more about this member.
    • Donate to Member
What is "cowboy coding?"
« on: June 22, 2006, 05:12:24 PM »
Curious if others do this, too. Nick Bradbury talks about cowboy coding a meme tracking feature for his FeedDemon app:

"So, given that I'm supposed to be a seasoned, old school programmer, you probably think that I first sketched out some ideas for how this feature should work, and then followed some sort of formal design process before coding it.... Nope. I went straight to coding. No design. No plan. No nothing....

Read on and let us know what you think!

JavaJones

  • Review 2.0 Designer
  • Charter Member
  • Joined in 2005
  • ***
  • Posts: 2,636
    • View Profile
    • Read more about this member.
    • Donate to Member
Re: What is "cowboy coding?"
« Reply #1 on: June 24, 2006, 12:53:27 AM »
Hmm, I think you might want to give a bit more info on this up-front. It's actually really quite interesting and insightful. Basically the idea is that if you come up with an idea for something that you think might have unforeseeable problems (e.g. it depends on other people's code/systems that you may not be familiar with yet), then you just start coding immediately so you can (hopefully) run into the problems quickly and solve them. Then when you've done a few iterations of this exploratory, trial-and-error process, you start over with the lessons you've learned and do a proper structured (planned) version of the feature.

This technique is particularly interesting to me as I've just read the "tips for the one man programmer" article linked from here a while back and it stressed planning quite a bit. At the time I agreed with it wholeheartedly. However I think this is an interesting twist on that. It is a way to potentially combine the best aspects of the true "cowboy coder" and the more methodical, "professional" approach.

That being said I'm not actually a developer so I'm not sure how valuable my opinion is. :D I'd love to hear what some real coders think of this though.

- Oshyan

mouser

  • First Author
  • Administrator
  • Joined in 2005
  • *****
  • Posts: 34,933
    • View Profile
    • Mouser's Software Zone on DonationCoder.com
    • Donate to Member
Re: What is "cowboy coding?"
« Reply #2 on: June 24, 2006, 01:12:12 AM »
i'm a big believer in planning out programs and structures, but like most of life, it depends on your goals and the scope/timeframe of your project.

i think this kind of approach makes most sense in terms of the famous idea to "plan to throw one away [because you will anyway]".

the idea being that you can't really anticipate and plan everything, so you are better off just plunging right in and expecting that you will learn a lot in the process, and write the *real* permanent code later and throw the initial code away.

if this is your approach, i think it makes a lot of sense to just jump right in, as a learning excercise.

OR

if it's a small enough project and you are a good enough coder (or have written this kind of program before) you may get away with a one-shot fast coding project.

learning what will work and learning how to anticipate issues, and learning what kinds of program and data structures will work for a task is really most of the difference between someone who has been programming fro 15 years vs. someone who has been programming for 2 years.  as you get better you will be able to see and anticipate things that new programmers won't.

For bigger projects though, i'd always recommend some planning, especially if you're not prepared to throw one away.. Otherwise it's far to easy to paint yourself into a corner and realize that the foundation of your code is fragile and not well suited to the task.

This issue is also particularly important when other people are going to be using your software.  It's far too easy to realize half way in that you are going to have to make some changes to the data files, etc., that will render the new version incompatible with the old.  people usually don't like to hear that.

JavaJones

  • Review 2.0 Designer
  • Charter Member
  • Joined in 2005
  • ***
  • Posts: 2,636
    • View Profile
    • Read more about this member.
    • Donate to Member
Re: What is "cowboy coding?"
« Reply #3 on: June 24, 2006, 01:47:46 AM »
Yes, I liked the first approach you outlined. That's what I found valuable in the article. :)

- Oshyan

app103

  • That scary taskbar girl
  • Global Moderator
  • Joined in 2006
  • *****
  • Posts: 5,559
    • View Profile
    • App's Apps
    • Donate to Member
Re: What is "cowboy coding?"
« Reply #4 on: June 24, 2006, 04:50:06 PM »
Usually an idea will sit in my mind for a bit while I imagine what it looks like, what it does, and imagine myself as the user. I literally mentally use my software over & over.

Then I start drawing doodles in a notebook just not to forget what I am seeing in my mind's eye.

After a few days, it becomes more refined...I start seeing how things behind the GUI will work...start making more textual notes to myself...a list of questions to answer, things to research.

Then I write my crazy looking pseudocode....and make longer lists of questions to answer....and start researching for answers and saving links.

At some point when I feel my GUI vision is ok, I will start work on that.

Sooner or later I get to the actual code...and have lists of links to info I researched to answer my questions from my list to guide me as I code.

When I think it's finished...I use it...a lot. That's when I compare my vision I had in the beginning to what I have created...see if they match up...if there is room for improvements..then fix it, because it's never quite what I meant.

This is why I am such a slow coder and work best alone.