Win a copy of Design for the Mind this week in the Design forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Systematic & organized j2ee development

 
hasan khan
Ranch Hand
Posts: 223
Eclipse IDE Firefox Browser Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Mark Spritzler
ranger
Sheriff
Posts: 17278
6
IntelliJ IDE Mac Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Frank Carver
Sheriff
Posts: 6920
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 142
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 11962
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Steve Dalton
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
James Clinton
Ranch Hand
Posts: 190
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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...
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic