Planning before building

pohopo

What do you think about planning your project before coding? Like first determining what tables you need and their relationships and writing down what functions your project will require. Is this just a waste of time and you should just jump straight into coding, or should their be some planning first?

thorpe

Is this just a waste of time and you should just jump straight into coding, or should their be some planning first?

If you dont plan ahead you will nearly allways run into dead ends you'll know you could have avoided if you'd done things differently.

A good plan of attack will help you see these dead ends before you get there.

UML is your friend.

pohopo

And when I say planning it could be very small planning if you use Agile type methodology where your project is more of a nugget/milestone so you really don't need a lot of planning.

FatStratCat

Whenever I sent a project to a programmer I always included a blcok diagram / flow chart, with an attached listing of all functions I wanted, and what I expected them to accomplish.

It took me time to do it, but I always got what I wanted out of the project in the end. It probably saved him some time programming, too. He rarely had questions and his demos were mostly finished products except for the makeup and jewlry. 🙂

Elizabeth

I always map out a project beforehand so I can see how things relate to each other - kind of like writing an outline to a book or like fatstratcat said, a flow chart. I would equate NOT doing it to driving without a map or a destination-- how do you know where you're going and when you've gotten there?

Now that's not to say things won't be changed along the way, and your end result may look nothing like your original plan. But imho you have to have a starting point of some kind.

dalecosp

It depends on the quality you expect to have in your code. If you don't care about anything so long as it works, it's a tad easier to just jump in. However, many times you'll look back and wish that it was "prettier" when you're finished, or the "feeping creaturism" sneaks in ("gee, I could've added X to that"), or you've got to maintain the code in a changing environment. Then, you may wish you'd planned it better.

Of course, if there's more than one person involved, then you'd better plan, for sure.

The first thing to be planned is the plan ;-)

After the plan's done, then what? It's all about what you learned in making the plan. It depends highly on what the plan requires. Probably the database should be planned first, unless you're very good at database abstraction (which you should be, or try to become), in which case the database should be planned first 😃. This has been proven to me in designing an online clothing shop, which I ranted about some time ago (and stand by, beware, etc.) --- v4 <5?> is in the planning stage, and my company has got this contract again after a failed 'in house' build.

Everytime the clothing store owners said, "oh, and BTW, we've got these $foo and they have another quality $bar and dimension $baz", my last plan went out the window.

Online "communities" may be even more difficult, unless you're already a well-established participant in said community and know many facets of its organization. But's it's all about the data. If you can gather enough information, the plan comes fairly easily, and the coding is just about problem solving in some programmatic idiom.

Ah, I'll shut up now. I mean to actually write some code today....

Jason_Batten

Planning helps to get you excited. It is like coding foreplay.

dalecosp

Jason Batten wrote:
Planning helps to get you excited. It is like coding foreplay.

Which must be why E said, "I always..." while I said, "if you're going solo, who cares?" 😉

Elizabeth

Wow, another perfectly reasonable thread gone straight to the gutter! Rock on, EL!

dalecosp

I guess we didn't plan on that, did we?

pohopo

Elizabeth wrote:
Wow, another perfectly reasonable thread gone straight to the gutter! Rock on, EL!

It is all good. I was just venting because I was talking to people that seem to think project planning was not very important.

MarkR

The amount of design work you want to do is up to you. Don't design the database schema beforehand, it will always change, you'll just waste time.

But you MUST do a thorough requirements analysis. Don't just invent features because your client says they seem like a good idea. Don't put in extra features unless you determine that they're necessary.

Although you don't need to know in advance HOW you're going to build it, it is absolutely VITAL to know WHAT you're going to build.

IMHO most business analysts etc are just a waste of oxygen (or at least all the ones I've met seemed to be).

Mark

pohopo

I think you should create the database schema beforehand. I always felt that if you can't create what you are about to code on paper first how can you do do the real thing. And if you are making that many schema changes during development then I would say the project requirements were very poor to start with. In my experience it is much easier to make changes during project planning versus trying to do it halfway through the project (or milestone if you are doing the project in phases).

And sadly most business system analysts don't know what they are doing, but if you do get one that does what he/she is supposed to do then they can make a significant difference to the project. They make sure what is being built is what is actually needed by the business.

MarkR

pohopo wrote:
And if you are making that many schema changes during development then I would say the project requirements were very poor to start with.

I would argue that a database schema is part of the IMPLEMENTATION of an application. Therefore it's nothing to do with the requirements analysis.

In my experience it is much easier to make changes during project planning versus trying to do it halfway through the project (or milestone if you are doing the project in phases).

Maybe so, but if you do a lot of upfront design, in my experience, most of it will be wrong in some way.

This work will be partially or entirely wasted, and you'll end up with a load of obsolete documentation which will serve to confuse new developers

Mark

dalecosp

MarkR wrote:
I would argue that a database schema is part of the IMPLEMENTATION of an application. Therefore it's nothing to do with the requirements analysis.

But, if the nature, quantity, dynamics, and type differences of the data to be handled are not thoroughly analyzed, then you can't go anywhere at all.

Sounds like a question of semantics, perhaps? I would agree that the actual creation of the database (schema and the real-time implementation) happens after the planning, but if you make your quote and/or timelines based on analyzed requirements that don't consider data characteristics (quantity, nature, dynamics, etc.), then you're asking for more feeping creaturism down the road....

My $0.02. FWIW, I can't even pretend to be an "expert" ....

pohopo

MarkR wrote:
I would argue that a database schema is part of the IMPLEMENTATION of an application. Therefore it's nothing to do with the requirements analysis.

IMHO, the database schema is very important in the requirement analysis. Besides helping to size the project (as Dalecosp mentioned) it helps me to better visualize the project as a whole. Many times I find improvements schema that I put in place before coding starts. And it takes so little time to create the schema. A day or so which is nothing in larger projects.

MarkR wrote:
Maybe so, but if you do a lot of upfront design, in my experience, most of it will be wrong in some way.

You have had some bad experiences, the upstream work I have seen for projects are exactly what we build. Before coding starts we require a lock down of requirements. If those requirements change we go through a change control process to approve the changes. And, in my experience, there are very little change controls because we usually get it right the first time.

As I said earlier, you have had bad luck with project managers/business analysts. I am sure you have built many great things that worked perfectly only for the business analyst to tell you they needed the to work another way or they must have some other feature and you shoot back that they never mentioned this in the beginning and now it is going to take 6 weeks to add the feature that would of taken 3 days had you known up front.