aspose file tools*
The moose likes Agile and Other Processes and the fly likes process of coding Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » Agile and Other Processes
Bookmark "process of coding" Watch "process of coding" New topic
Author

process of coding

saravanan balu
Ranch Hand

Joined: May 19, 2000
Posts: 49
Hi All,
ofcourse everyone will have certain style of doing programming.what approach do you find more meaningful once you get the requirements?
i mean to say how do you start coding once you got the requirements?
Jeroen Wenting
Ranch Hand

Joined: Oct 12, 2000
Posts: 5093
I pick up my keyboard and start punching away...

Still looking for a million monkeys with a million keyboards...


42
fred rosenberger
lowercase baba
Bartender

Joined: Oct 02, 2003
Posts: 11317
    
  16

Here's a few things i try to do...

1) Read the requirements.
2) Repeat step 1 about 20 times...
3) Ask questions about the requirements. make sure and ask about anything i don't completly understand over and over until i do understand it.
4) Read the requirements a few more times, with my new knowledge.

ok, so i may be exaggerating a little, but i'm trying to make a point. i've been burned enough times where i read one or two items, started coding, got into things, then read another part of the specs... and my whole design was kaput.

something else that I sometimes find useful is to write something quick and dirty, that sort of does what they specs want. in the process of doing this, you'll discover all kinds of stuff you (or anybody else) ever thought of. once you spend a little time on it... delete it all. then start over.

and yes, you have to delete it. otherwise you run the risk of saying "well, this sort of works, i'll just tweak it". this defeats the purpose of experimenting, and changes it into hacking-to-get-it-to-work.

Granted, i don't always have time for this, but when i do, it's great.


There are only two hard things in computer science: cache invalidation, naming things, and off-by-one errors
Dirk Schreckmann
Sheriff

Joined: Dec 10, 2001
Posts: 7023
Moving this to the Process forum...


[How To Ask Good Questions] [JavaRanch FAQ Wiki] [JavaRanch Radio]
Junilu Lacar
Bartender

Joined: Feb 26, 2001
Posts: 4462
    
    6

By many accounts, the Test-Driven Development approach works very well.


Junilu - [How to Ask Questions] [How to Answer Questions]
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
Indeed! Writing tests FIRST has a huge influence on the design, leading you to lots of simple, decouple classes. It's also a lot more fun than slaving for hours on some code, finally running it and finding it does not work for completely mysterious reasons.

See JUnit.org for lots of articles and tips. Here's the classic Test Infected: Programmers Love Writing Tests. If this article makes sense and gets you excited, you can change your life!


A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Personally, I very much enjoy the Extreme Programming way of working: http://www.extremeprogramming.org/


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Warren Dew
blacksmith
Ranch Hand

Joined: Mar 04, 2004
Posts: 1332
    
    2
I agree with Fred. Read the requirements first, ask questions about them, even write down the answers to the questions.

Then I proceed with some high level design, deciding on things like layers and packages, before going on to implementation.
Jeroen Wenting
Ranch Hand

Joined: Oct 12, 2000
Posts: 5093
XP is nice in theory but most customers (especially outside IT) don't have time or inclination to be that closely involved (if they even know their own requirements, which is rare).

Typically managers and helpdesks also go extremely quiet when you try to get them to go for flexible small releases instead of a few large fixed milestones which they can nail down as deadlines to slap you around with if you don't meet them after they push them forward to last week.
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
Originally posted by Jeroen Wenting:
XP is nice in theory but most customers (especially outside IT) don't have time or inclination to be that closely involved (if they even know their own requirements, which is rare).

If there is no customer, the project is bound to end up a failure (or more likely people do their best to hide the failure and present it as a success to their superiors regardless of how useless the software ended up being) regardless of whether you're doing small releases or not.

If the customer wants to throw a set of "fixed" requirements over the wall in the beginning of the project, the XP team still delivers those requirements to their best ability (prioritized by their own judgement) but obviously they are missing the invaluable feedback from those small releases.

Then again, I know of at least one project in a pretty large organization where the (internal) end-users are crying for small releases because they have no way of guessing the requirements correctly 3 months ahead but the customer (project manager) refuses to go below 3-month releases for some obscure reason (he has a history in managing power plant construction projects...).
[ June 16, 2004: Message edited by: Lasse Koskela ]

Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
I worked a couple projects with managers who were afraid to show any work in process to the customer. Everything had to be completely finished and polished to a shine before we gave them access. The results were slick and wrong. I started showing the customer what I was doing as often as they'd look in the 80s. My team now does formally defined iterations with a demo and hand-off every two weeks. Much better than the hold-your-breath approach. Customers willing to play along are critical!
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Jeroen Wenting:
XP is nice in theory but most customers (especially outside IT) don't have time or inclination to be that closely involved


"Customer" is a *role* in XP - the Customer has the competence and the authorization to make business decisions. Every project needs someone filling this position - having the actual customer playing this role is preferred, but not really required.

(if they even know their own requirements, which is rare).


The less they now about their actual requirements, the more important is it to include them in a tight feedback loop!

Typically managers and helpdesks also go extremely quiet when you try to get them to go for flexible small releases instead of a few large fixed milestones which they can nail down as deadlines to slap you around with if you don't meet them after they push them forward to last week.


If things were easy, everyone would be doing them. It's a goal worth working towards, though.
Randall Twede
Ranch Hand

Joined: Oct 21, 2000
Posts: 4347
    
    2

i usually start by creating the GUI(assuming there is one).


SCJP
Visit my download page
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
Back in mainframe days before I heard the word "methodology" I wrote the user manual first, then wrote and demonstrated to the customer one feature at a time. That's a bit "big design up front" nowadays, but not entirely evil.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: process of coding