Joshua Marinacci's Blog

How do you develop?

We hear a lot about development processes these days, but I'd like to know what techniques people actually use? Do you create UML diagrams? Do you map out the states? And when it comes down to the actual code, how do you break it up into classes and packages? Does your methodology vary depending on the type of program you are creating?

When I'm creating a new program I start with a single class and a main method and then grow from there. First I put the minimum functionality in there, just to make sure it works. This is especially helpful if I'm trying out new technology, say a library for generating PDFs.

Once I have the minimum working I start writing down what the finished program should do. Not a complete design document, just a list of functions: what the program should be able to do. From there I start pulling the code into different classes and packages.

I do structure my code differently depending on the type of program it is. For servlets I focus on data modeling, since there is usually a backend of some sort that I'm connecting to. I create classes that represent each underlying object in the system, then I create various handlers to create, manipulate, and store those objects. The UI is constructed on top of that using XSLs or JSPs.

If I'm writing a Swing application I focus on the taskflow of the user. Where will the user start? Where will the user want to go from screen X? How should validation and error conditions be handled? I usually create classes to model each window. All of the code to create the panels, sub panels, and widgets goes in that class. As the size of the class grows I pull the major chunks out (say a reusable subpanel for selecting a date). I make my event handlers anonymous at first and then pull them out into inner classes and later into full classes in an event package.

I've discovered that I have a very iterative way of doing things. Constantly writing and refactoring, growing the application but always making sure it continues to work. Does this mean I unconsciously follow XP?

Comments

• Good question
  When working with teams on large projects, I am a proponent of what I call the "shaft of light" theory. Envision the entire application as a big fluffy cloud of uncertainty. Now pick a sliver of the problem and implement all of the layers that are necessary to get from the "Sun" (usually the user) to the "ground" (usually a database). This "shaft of light" gives you a sliver of functionality that actually works and helps identify and resolve the biggest implementation issues.

  Posted by: johnreynolds on December 17, 2003 at 06:50 AM

• Do you have the spirit?
  Joshua,

  In his introduction to the Korean edition of Extreme Programming Installed Ron Jefferies writes:
  "Over time, people have argued that the specific practices are not what is central to XP, but that it is instead some spirit, or some principles, that form XP's basis. They say that if you have this spirit, if you understand these principles, then you understand XP. I believe that this view is correct, but it does not mean to begin by inventing your own XP."

  So if you have this spirit it's highly likely that you were in fact doing XP without even knowing it. That's so cool. If you do have the spirit please let us know what it feels like and how you were able to receive the spirit that Ron is speaking of. Along your path don't forget that you're instructed not to invent your own XP. Apparently only a select few are permitted to invent, and the rest are merely allowed to get into the spirit of what they invented. Maybe the XP spirit existed before Ron, Kent and the others and they like you were doing XP subconsciously before they even considered formulating a methodology. Let's just hope that the spirit guides their hands as they continue to reveal XP to us day by day, by day.

  Taylor Cowan

  See
  http://www.xprogramming.com/xpmag/koreanintro.htm

  Posted by: tcowan on December 17, 2003 at 09:23 AM

• what works for me...
  I've found that "forced pauses" in the develop cycle help my overall design tremendously.

  We're a little heavy on the upfront documentation side, so I tend to write a very, very broad overall picture of what the design will look like. UML as required to illustrate the point, but if I don't need it, I don't do it.

  Then I do what I think will be 10% of the work. That generally reveals to me all kinds of tricky details that I didn't think of when I first started, and gives me an idea of how good my initial estimate was. (it is generally low).

  I then go back and document the tricky bits. Usually when I'm documenting that part, I come up with better designs to handle the tougher problems than I had when I was writing the code. Whether it's in the shower before going to work the next day, sitting in my car, whatever I always seem to get a better idea later. If I let the problem sit in the back of my mind for a day I seem to always come up with a better way of doing it later.

  On some occasions after I've left the code for a few days, I'm more willing to throw it all out to solve a bigger problem. I am more reluctant to do that with code I wrote that day.

  I tend to use UML quite a bit more when I go back a second time. I'm not sure why that is, but I think it's because the tougher problems need better tools. Could also be that I understand the problem domain better.

  
  

  Posted by: johnadams on December 18, 2003 at 06:41 AM

• .....
  First of all, identifying what this application is. Getting enough information to see the whole picture without much of details. It often helps to identify “class” or “type” of the application. There are several of them known to me and selecting one would “automatically” result in further partitioning of the system being designed. UML - only as a tool for documenting the process - can help here.

  Next is figuring out major components rather independent, which can be developed in teams without too much interaction. Thinking about marketing guys who will come to you any moment and may screw up all by requesting a new feature. How would this intervention affect the project? How to minimize the impact?

  …and jumping into any sort of concrete development methodology like XP only at small isolated peace of the system….
  

  Posted by: krage on December 18, 2003 at 07:53 AM

• Code Reuse
  Wether I am working on a design or coding the solution, I find it very helpful to see from others shoulders.
  The first thing I do whenever I have a new application to develop to search on google and yahoo with some broad search pharase. For example recently we were supposed to write a swing based java applet to show thumbnail images searching from the hard disk and then allow to select the images in a very user-friendly manner, finally to upload them securely on the server using SFTP.
  A google search on "Java Upload Applet" , "Java Thumnail Images" , "Java secure ftp" results in many intersting links. We could find some very good ideas about UI for thumbnails , selection , arrange, drag n drop etc. from couple of existing application. Similarly we also found some intersting open source application for Secure FTP upload.
  We idenfied the major components of the application and then started with two major components "Thumbnails" and "FTP" at the same time. Here usually I prefer again using some pre-existing similar code which I can find as Open-Source or in my personal repository. I usually focus on the infrastructure classes first , with a simple main method (like a unit test case) to call those infrastructure class methods. The class methods grow over a period of time. I do not start with the constructor instead I first identify the primary interface of the object for example in a ShortcutsPanel class I would first write setupShortcuts , the constructor(s) are added based on the requirements. I prefer having a default constructor preferably a private one if it can be singelton. I am not sure if this is right thing to do.
  On an average code (about 50 classes with 100 line per class) it takes me 3-5 revisions to produce a beta quality code. Af the second revision I generate a UML diagram from my classes and then do a redisign of the classes if needed. After the 3 revision I usually prefer a complete auditing of all the classes and run of unit tests.
  This is how my methodology works. As a matter of fact I have also used the same in a large scale application for enterprise network monitoring.
  Your comments are welcome.
  Thanks
  Ali Khan

  Posted by: himindz on December 21, 2003 at 04:20 AM

This work is licensed under a Creative Commons License.