File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Agile and Other Processes and the fly likes Systematic & organized j2ee development 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 "Systematic & organized j2ee development" Watch "Systematic & organized j2ee development" New topic
Author

Systematic & organized j2ee development

hasan khan
Ranch Hand

Joined: Aug 04, 2003
Posts: 222

I am a j2ee programmer, i am not satisfied with the way i am working, can any one suggest me how to make my development work more systematic and organized, i want to do less mistakes and i don’t want to forget many things.


SCJP, SCWCD
Mark Spritzler
ranger
Sheriff

Joined: Feb 05, 2001
Posts: 17260
    
    6

That a huge subject. Too big for a forum answer. But there are lots of books on methodologies. Look at formal methodologies as well as more chaotic ones like Agile. To see which one best suits what you like.

I am going to move this to the Agile and Other Processes forum.

Mark


Perfect World Programming, LLC - Two Laptop Bag - Tube Organizer
How to Ask Questions the Smart Way FAQ
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Mark Spritzler:
Look at formal methodologies as well as more chaotic ones like Agile.


I don't think that "chaotic" is a good description for Agile approaches. Agile development typically is very disciplined. I think the biggest conceptual difference is in predictive (traditional) vs. adaptive (Agile).

For organizing your work, I'd advice to take a look at Scrum, or perhaps the Extreme Programming "Planning Game" practice.

If you tell us more about what your most pressing problems are, we could probably give more concrete advice.


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
Frank Carver
Sheriff

Joined: Jan 07, 1999
Posts: 6920
i want to do less mistakes

I have used two approaches which have helped me get much better at this.

The first is "test driven development" (TDD). Even used on its own, TDD has had a huge effect on the number of mastakes, bugs, faults, poor designs and misunderstandings in my code. Writing tests, then writing code to pass them, and not moving on to any new changes until all the tests pass is a great way to avoid mistakes.

The second approach is continual review - the idea that all code is available for review all the time, and that team members actually read and review all code. This can be done using a method of distributing all "patches" for approval befor including in the codebase, for example, but a simpler and quicker way is to do "pair programming", where two team members work together on each change. Any mistakes or poor decisions will usually be spoted very quickly, before they can get expensive.

and i don�t want to forget many things.

To me, this is one of the hardest problems to solve in software development. There are hundreds of different techniques and products which claim to address this problem. You will need to find one which suits you.

For my own projects I take a two-stage approach. I carry a small notebook and pen with me everywhere, and any idea, thought or note gets written in it, together with the date and enough context (I hope) to make sense later. Each time I work on a particular project, I look back through the notebook for anything appropriate to the project, and add as much as I can to a simple text file in the version-controlled source code of the project. I then work using the text file as a source of tasks, and move or delete each entry which I complete.

If you need to manage external ideas, instructions and requirements, or share progress and prioritisation with other people, then a more open approach might well be more useful.


Read about me at frankcarver.me ~ Raspberry Alpha Omega ~ Frank's Punchbarrel Blog
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Frank, thanks for bringing up TDD - how could I forget that?

Originally posted by Frank Carver:
I carry a small notebook and pen with me everywhere, and any idea, thought or note gets written in it, together with the date and enough context (I hope) to make sense later.


I use index cards for a similar purpose. They have the advantage that they are much easier to reorganize than pages in a notebook...
Fintan Conway
Ranch Hand

Joined: Apr 03, 2002
Posts: 141
Originally posted by hasaN khaN:
I am a j2ee programmer, i am not satisfied with the way i am working, can any one suggest me how to make my development work more systematic and organized, i want to do less mistakes and i don’t want to forget many things.


Hi Hasan,

I believe the best thing that you can do is get JUnit (there should be a version for / comes with your favourite IDE). Then, as Frank suggested, read up on Test Driven Development, and start writing unit tests in JUnit for your code. Just the fact that you have tests that can be run at any time which will validate all the code that you have written will boost your confidence that there are less (ideally no) mistakes. The fact that you are testing everything as you go and will run all tests all the time means that you will not forget code that you have written.

Regards,

Fintan
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
Originally posted by Ilja Preuss:
Frank, thanks for bringing up TDD - how could I forget that?

Because it's become second nature to you--something so obvious that you forget to mention it explicitly.


Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Fintan Conway:

Just the fact that you have tests that can be run at any time which will validate all the code that you have written will boost your confidence that there are less (ideally no) mistakes.


I agree that TDD is a great help in preventing coding mistakes (and design mistakes, while we are at it).

For other forms of mistakes - priorizitation mistakes, communication mistakes with stakeholders, estimation mistakes, risk assessment mistakes etc. pp. you will need other practices.

So tell us Hasan, what kinds of mistakes were you referring to?
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
I really like the posts so far on this, but I'm going to take a tangent for a sec. Since you want to be "systematic and organized" let's think about the old Capability Maturity Model for one person.

Level 1 - Initial. You don't have a clear picture of what you're going to do, you don't keep track of what you did, one time through everything works and the next time it doesn't, you don't know why.

Level 2 - Repeatable. You know what you're doing, you tend to do the same thing every time around.

Level 3 - Defined. Now you've really thought about your process and written down your steps. That checklist of things to remember is a good start.

Level 4 - Managed. You're keeping metrics on how well you do your check list and how much that helps your bottom line. I don't think this has to mean somebody else is "managing" you but maybe you'd have a partner audit your metrics?

Level 5 - Optimizing. After every trip through the process you pause and review what worked and what didn't, refine and tune the process. Over time your metrics tell you when your changes work and when they don't.

Does any of that ring true for the problems you're facing? Maybe it can give you some structure around the structure. When you choose TDD or particular tools or techniques see how they affect the whole process and the bottom line.


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
Steve Dalton
Greenhorn

Joined: Jun 27, 2001
Posts: 13
All good points.

You might also want to look at using a project management/build tool such as Maven - it will get to into best practices such as TDD from the word go and provide you will a consistent look across all your projects making development and maintenance easier and less error prone. It will even generate a lot of the J2EE glue such as descriptors, interfaces etc for you which can often bring in errors. Once you have this in place it's only a short hop to getting a continuous integration process going - which can have a massive effect on quality.

I recently found with Maven that is also very easy to get it to generate reports on code complexity, style, coverage etc - which add to quality, not just of the deliverable, but also the source code - which is such an important (and often overlooked) aspect of quality.

Steve


SCJP<br />SCWCD<br />SCBCD (In progress)
James Clinton
Ranch Hand

Joined: Jun 23, 2003
Posts: 190
Sounds to me you should read 'Effective Enterprise Java - LeMay,Neward', goes hand in hand with 'Effective Java - bloch. After that look into design patterns...
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Systematic & organized j2ee development