Pre-coding Planning

I'm about to undertake my first really large, potentially marketable project. I'm really excited about it and want to do this one right.

I'm hoping you can point me to some reliable, good resources for pre-coding planning. Perhaps you can give some of your own advice from experience as well.

Which classes should I work on in the beginning? Database stuff, utilities, controls, UI, other logic? How should I segment my time? What kind of information do I need to collect before I start? How should I layout my path?

I feel like I have the knowledge to write a reasonable program - I'm just not sure how to get started on a big project.

Long post short - What do I need to do before I even write a line of code?

Thanks for any and all responses.

Quote:

---

Originally Posted by nmadd

Long post short - What do I need to do before I even write a line of code?

---

If this is your first Analysis/Desging sort of task than i would like say only one thing which is very important to begin with:Listen to your customer/user/client thoroughly try to understand his requirement without even thinking if it's technically possible and not,Once you finish with them,sit down habe a cup of tea and start listing down all the point he said and try to arange them in one logical flow.Once this is done present your priliminary flow document to your client and asked them to verify "this is what you need?"

If answer is YES you have done half of the job :D

I always feel the data "models" the customers real-life office process - at least when you successfully design the tables it does.

The UI should not be a foundation but should instead run atop the business and data layers.

With that said the UI should be able to be replaced at any time - with a web-access, for instance - and the BL/DL should still function.

I might be data-centric - but in my opinion you start the design of the tables first. Don't complete them - just start them.

Then you envision the BL - how will you talk to the data - start that - don't complete it.

Then you envision the UI - probably all on paper/word/paint - whatever - next.

Keep running these 3 task lines along - with DL ahead, BL following and UI behind that.

I also am a strong believer in iterative programming - I actually don't believe you can avoid it. I've seen project manager types come along that think the spec can be done 100% and then the app developed to it - but I've never seen that work in reality.

With that said for every 4 steps forward on each of the 3 tasks lines lists - you take 1 step back. Be prepared for this.

Also - make sure the customer is ready to see prototypes. Make them aware from the start that it is iterative and you will bring demo's along for discussion. There is nothing better to put you back that 1 step then the user saying "no - it won't really work that way".

One thing that the other two have assumed is that this project actually has an identifiable customer base, but that isn't clear from your original post. I really like getting user feedback on the UI, which is where I believe the bulk of actual time will be spent. While I agree with the importance of getting the data structures right, the work there is all relatively similar from one project to the next. Sure, there are going to be differences in the data layers and business objects, just as there will be differences in the database, but UI design is where the vast majority of the creativity comes in, and it is really the most critical piece. You can have the most brilliant data model in the world, but if the interface is crap, nobody will use the program, and there is little standard about creating a truly good interface (some standards, but not so many).

On the other hand, this reinforces a point made by szlamany: The UI is an inherently fluid concept, which is why szlamany stated that it should be able to be replaced at any time. The goal is to get the user interacting with the data in as natural and intuitive a fashion as possible, which may well entail a web design, a standard windows form, or even a clever graphical interface. If the data is solid, you can start with a windows form using standard controls, then as you come to see a place where an interactive graphic would work better, you can change the UI to use the new interface without dealing with the data behind the scenes. The UI is a representation of the data, whether on web, windows, or holographic display, and thus it is a fluid concept with the goal being a non-quantifiable optimal user experience.

@SH - That was really very well said - excellent!

Thanks, it's a subject I dwell on. Perhaps more than I should.

Here is some good proof of what SH has said.

We've got a really mature enterprise app used by school districts. UI is in VB6 from 8 years ago.

2 years ago we added pocket PC access - same data - just served up a different way.

Last year we started creating asp.net pages. We have hundreds of what we call INFO DISPLAY stored procedures - users get grids of data returned to the VB6 program that they could sort on the columns - select grids for totals - kind of EXCEL like. Those are porting over to the asp.net pages with absolutely no change. So we are leveraging all that existing valuable T-SQL work in a new UI.

Great posts. Thanks a lot. Keep them coming.

Talking with the users is a tightrope walk - it sometimes backfires.

If they get too invested in thinking they are controlling the UI then they can't bend to what you deliver - which when all aspects - DB/BL - and user-interaction - are taken into account you sometimes are forced to use method-xyz.

Good example of this is colors - if you get the user group involved in color selection and you might never win. Colors are tough - backcolors too deep mean you are changing forecolors - certain combo's work and certain ones don't.

Another issue with customer interaction is getting too much feedback. We have a program that we need people to be using in remote locations. We aren't selling anything, and our structure is such that mandating that people use any particular tool simply won't work (nobody owns a stick big enough), so we are selling them on the concept. However, these are people who have been doing things a particular way for their entire careers, and while all the myriad ways (a subtle literature reference to an excellent short story) are similar, no two are identical. The programmer is currently at the point of adding little tweaks and features so that the program can match each individual style for each individual group (and even each individual individual), because otherwise they will simply choose not to play. Had we any leverage, it would have been possible to come up with a single acceptable interface, and have the groups adjust their process to the interface.

Making the user adjust to the interface might not seem very user friendly, but it is actually how nearly all software works. As long as the interface is easy to learn and intuitive enough, people will use it, even if it means some slight modifications to their actions. As a trivial example, I have a shopping list program for my PDA. Prior to this, my standard operating procedure was to look in the cupboards and see what I was missing, then go to the store and wander around the aisles trying to remember what I was there for. Invariably, I missed an item or two, but that was acceptable. By comparison, my father always made a list on a slip of scrap paper that he perpetually carried in his shirt pocket, a technique I used whenever some items were REALLY important. Once I made my shopping list program, I don't follow either pattern anymore. Now, instead of writing things on a sheet, then crossing them out, I select them from a list and pressing a button. To remove them, I also select them from a list and press a button. Of course, I could have maintained my familiar interface by requiring that I use the stylus to write the item on the screen and build the list that way. I could also maintain the familiar interface by detecting a 'cross-out' to remove items. However, I built an acceptable alternative and modified my behavior to the new interface, a fact that is made more simple because picking items in a listbox is easier than writing them out anyways.

So unless you are in a situation such as we are in, where the users have many different intractable and incompatible requirements coupled with a reluctance to change, then come up with a good interface, and from there consider all user requests based on whether they would make the interface easier in general, or easier for the few at the expense of the many.