Win a copy of Programmer's Guide to Java SE 8 Oracle Certified Associate (OCA) this week in the OCAJP forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

process of coding

 
saravanan balu
Ranch Hand
Posts: 49
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 5093
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I pick up my keyboard and start punching away...

Still looking for a million monkeys with a million keyboards...
 
fred rosenberger
lowercase baba
Bartender
Posts: 12185
34
Chrome Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Dirk Schreckmann
Sheriff
Posts: 7023
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Moving this to the Process forum...
 
Junilu Lacar
Bartender
Posts: 7594
53
Android Eclipse IDE IntelliJ IDE Java Linux Mac Scala Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
By many accounts, the Test-Driven Development approach works very well.
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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!
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Personally, I very much enjoy the Extreme Programming way of working: http://www.extremeprogramming.org/
 
Warren Dew
blacksmith
Ranch Hand
Posts: 1332
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 5093
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 11962
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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 ]
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 4467
3
Java Python Scala
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
i usually start by creating the GUI(assuming there is one).
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic