Welcome Guest.   Make a donation to an author on the site November 28, 2014, 05:05:56 AM  *

Please login or register.
Or did you miss your validation email?


Login with username and password (forgot your password?)
Why not become a lifetime supporting member of the site with a one-time donation of any amount? Your donation entitles you to a ton of additional benefits, including access to exclusive discounts and downloads, the ability to enter monthly free software drawings, and a single non-expiring license key for all of our programs.


You must sign up here before you can post and access some areas of the site. Registration is totally free and confidential.
 
The N.A.N.Y. Challenge 2011! Download 30+ custom programs!
   
   Forum Home   Thread Marks Chat! Downloads Search Login Register  
Pages: [1]   Go Down
  Reply  |  New Topic  |  Print  
Author Topic: What is "cowboy coding?"  (Read 2951 times)
zridling
Friend of the Site
Charter Member
***
Posts: 3,291


Linux captive

see users location on a map View Profile WWW Read user's biography. Give some DonationCredits to this forum member
« 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!
Logged

- zaine (on Google+)
JavaJones
Review 2.0 Designer
Charter Member
***
Posts: 2,537



see users location on a map View Profile WWW Read user's biography. Give some DonationCredits to this forum member
« 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. cheesy I'd love to hear what some real coders think of this though.

- Oshyan
Logged

The New Adventures of Oshyan Greene - A life in pictures...
mouser
First Author
Administrator
*****
Posts: 33,703



see users location on a map View Profile WWW Read user's biography. Give some DonationCredits to this forum member
« 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.
Logged
JavaJones
Review 2.0 Designer
Charter Member
***
Posts: 2,537



see users location on a map View Profile WWW Read user's biography. Give some DonationCredits to this forum member
« 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. smiley

- Oshyan
Logged

The New Adventures of Oshyan Greene - A life in pictures...
app103
That scary taskbar girl
Global Moderator
*****
Posts: 5,328



see users location on a map View Profile WWW Read user's biography. Give some DonationCredits to this forum member
« 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.
Logged

Pages: [1]   Go Up
  Reply  |  New Topic  |  Print  
 
Jump to:  
   Forum Home   Thread Marks Chat! Downloads Search Login Register  

DonationCoder.com | About Us
DonationCoder.com Forum | Powered by SMF
[ Page time: 0.032s | Server load: 0.08 ]