While I do have experience tearing apart open source projects, & making them do what I need them to, or adding our own desired functionality, I've never created a project from scratch that interfaces with a MySql database.

So at Pen-to-Paper time, how do you determine the projects' (& in this specific situation, the database) needs before typing the 1st code block?

Wow. What a great question to ask, but what a quest to learn the answer. I've been writing code for 10 years (professionally for~6), and frankly, I don't think I can give a complete answer. First off, you need to sit down and think about what the requirements for your software are. Use phrases that start with verbs. Then look at the requirements you have, and eliminate half of them, because they are probably just "nice-to-haves" and will only get in the way of what is actually required (if you don't believe me now, once you do this a few times you'll learn :-) After that, take each requirement, and knock it down into tasks to accomplish that. You may start to see a recurring theme (i.e. requirement A, B, and D all require a database connection), so you can start to see a hierarchy of tasks to complete your job. Along the way, you may run into a few issues, and you'll want to sit down and figure out what the tasks are to fix those issues (and probably break those down into even more tasks).

The basic idea is that you need to turn your project into a giant lego project. When you look on the outside of a Lego project, and you see this giant spacecraft or whatever, it can look quite daunting. Honestly, I'm not experienced enough with Legos to re-create that. However, there are instructions inside that have you put it all together in small pieces, eventually bringing it all together. Software is just like that. Start with small pieces, independent of each other, and then start piecing them together. Keep splitting your tasks into pieces until you get tasks you can complete in a reasonable amount of time.

Requirements are a must, in my school the one thing I did learn about was preparing for a project. Spend as much time as needed on getting these right. Then there is the design process...this is still on paper. I would google UML, Unified Modeling Language. These concepts are not hard to grasp if you are an experienced programmer, there is a lot of software out there that can assit you with making these and pen and paper are not so bad either.

Once you have your requirments broken into tasks you can then give them high level design by using UML. Making notes of tables you will need as they come to you.

Your high level should just be like class diagrams, what classes you will need, then get deeper and start naming your functions or methods. Basically you start with a skeleton and gradually fill it in.

Once you have all but your actual code I would plan out the database, draw it out using ERD or enitity relationship diagrams...

The integrity of your database is VERY IMPORTANT you can have a perfect program, but if the DB is jacked up, you might as well throw your code away.

Once you have your database in place and a nice detailed, well thought out skeleton of your system, you can simply fill in your code.

I was taught that you spend 80% planning and 20% coding. Doing this will prevent crappy hacks. I haven't personally got to test this out, I work on a system that is already in place, so this is the best practice...in theroy

We hire BAs to do that crap. They talk to the customers and then "translate" the customers requirements into business requirements (BREQs) and then create Requirements documents for us developers to read. Sounds great doesn't it? Would be if the BAs, in their attempt to "translate", didn't end up convoluting, twisting, and completely misrepresenting the customer's requirements. And on top of that, most of the time the customer has no idea what they really want. It's not arrogance, but experience that makes me say that. This is why it's important to check back the with the customer at frequent intervals (with demos if possible) to make sure they haven't changed their minds (and they will).

So, yeah, I did have a point here somewhere. Oh right...just to concur with my colleagues, req's are important. You'll hear that in any software engineering class worth a damn. What you might not hear, however, (and something to keep in mind) is that requirements are a moving target. And the only thing that can help that is frequent contact with the customer.

First I decide and set in stone the scope of the project, how many people does it affect, whats it going to be used for, etc. Then, at work I have 3 white boards in my office and I start writing diagrams of processes, tables, databases,etc, and figure decide how they relate to one another. If its a large project, I break each large process down like this to see the internals of each large process, then gradually work my way outward until I have the relationships for all items in the application.

From there I sit, usually with pen & paper or Visio,and prioritize each task/process from 1 to 5, 1 being the highest and 5 being the lowest. From there I start the development, usually UI first (general idea for UI is first drawn on white board). Once I get to the processes I first make them work independently of anything (I always use NUnit for my unit testing). Once I have all the tasks complete for a process, I then make them work together. Once that is done I move on to another task (in prioritized order) until all processes and tasks are completed.

Doing it in this fashion I know all an thorough unit testing is done on the application before the application reaches the QA department.

Those are just my tidbits, not saying its a religion and has to be followed

Generally speaking:

1. Business Requirements Document
2. System Requirements Specifications.
3. System Design Specifications (can be a combined analysis and design doc for smaller projects). this should include input from all systems that have a stake in the solution, to ensure proper integration.
4. Test Case Documentation.
5. Systems integration Plan.
6. System Functional Testing Plan (including defect resolution).
7. Normalization plan (including resolution of defects that were launched into production).

IMPORTANT: A defined process to deal with change requests. Scope creep is the #1 killer of all projects.

Or I just kind of wing it after sketching a picture of Bender the robot on a cocktail napkin.

Zzzzzz such formalized people. I prefer the "what do I need this thing to do?" approach. Culminating in the final step... being completely overwhelmed by the project and fixing things on the fly <<nodding assertively>>. Your requirements only dictate the type of database (flat file, hierarchy, relational, etc.) you'll need as there aren't that many to choose from and of course there is the SQL standard to which they adhere. More important is the database management which requires a lot of forethought. You don't want to be losing time accessing the database when you don't need to, caching certain queries can be good, etc. Those are elements concerning the code of the software interfacing with the database. Not the database itself.

@Amadeus: scope creep gets snipers killed <<nodding assertively yet again>>

That is why I said "in theroy" because in "theroy communisum works" (Homer Simpson)
And yes I was told that requierments are ever changing...which is why software engineering is so challanging. It sounded to me like he was going to do this project for him alone...so in theroy you would be able to prevent the requirements from changing...but now that I think about it...you are not even safe from yourself.

Just out of curiosity...what do those BA's make to do that?

This post has been edited by supersssweety: 30 Nov, 2007 - 07:25 PM

I think it would depend on the shop. Depending on expertise, we pay BAs anywhere between 55K and 85K/year.

If this is truly how you look and think about the planning and execution of a new product, as a former PM y0ou would be the type of developer I would not hire at all, and I'm truly not trying to be rude but things have evolved, and I would rather spend 2 weeks planning to save a week of coding. Its not the Throw enough code at it and it'll work days anymore. More & more companies are moving to the Agile Software Development Methodology (such as the company I work for) and Im all for that methodology in software development.

JMHO though

Well, now, easy. I was asking how each person gets ready for their own project. Maybe he doesn't work professionally, maybe he does contract work. I'm just looking for pointers on a project that, well, is overwhelming at 1st =-)

Thank you all for that input!

I just pick a feature and start typing. When I'm bored with it, I start working on another piece. As time passes, it all comes together nicely.

I've spent countless hours planning projects and laying out software on paper, but (for me at least) it's proven to be a waste of time. By the time the project's done, it's changed so far from what it was on paper. On paper, there's just no way to think of everything. So, I just plant seeds and let the software grow.

Of course, when dealing with clients, it's impossible to avoid at least some illusion of premeditation.