Page 1 of 1

Help Planning Applications

Posted: Sat Jul 01, 2006 3:02 am
by Starcraftmazter
I thought this to be the appropriate place to put this.

I need a bit of help with learning how to plan/design large or well...medium sized projects.
I have worked before on 2 things which were fairly big for me. A CMS and a filehost (I went out of my way on features and security for that one).

The problem which I always have is this:
Once I start the project, I have a fairly good idea of what it's going to look like, how it's going to work, etc. But during development I find that something needs to be drastically changed, or something is too hard, or that I left out something really important - which actually happens quite a bit, and due to this i have to recode hundreds of lines....and by the time I'm finished, although works, the project code looks very messy.

So currently I have a project ahead of me, making a support ticket system. In my true fashion, I wish to include a million features, but how do I go about making some kind of a structure, a plan - so that I don't trip over my ideas in a few weeks time?

So far I've started making classes which will contribute to this project, and I haven't done anything major.

So if anyone has any tips, or maybe guides I should look at, that would be great, thanks ;)

Posted: Sat Jul 01, 2006 11:13 am
by alex.barylski
there is no defacto standard...

Some people use UML others just notepad...

I personally sketch everything GUI out on paper first, having the visual I find helps tremendously in hammering out features, requirements, etc...

From here it's much easier to develop classes, API, etc...

There are a few well known design processes (?!?) the one which I find most appealing is the iterative design processes, where a project has many life cycles, in that you don't plan to much before actually programming...

Anyone who has worked on anything but the most trivial project will tell you...you can NEVER hammer out a solid design first time out...

Thus many have adapted this iterative design process where you plan a little develop a little, getting a better feel for the system...design and plan a little and develope a little more...

Refactoring code is a very *real* reality in anything complex...get used to it

Cheers :)

Posted: Sat Jul 01, 2006 11:56 am
by Christopher
Well ... Hockey is going to be annoyed at me mentioning the "smart people" in software development but yours is a classic case. These guys came across the same problems 50 years ago and have been thinking and writing about it ever since. You can try to solve this stuff on your own -- the problem is that software design is very counter intuitive. I do the same thing that you do and almost always do it wrong. Then I find some book or article and it invariably ends up that a best practice is to do it the opposite way. They solved most of this @#$% years ago but every young programmer insists on thinking that they can teach themselves.

Do yourself a huge favor and invest $200-$300 to make yourself a better programmer by buying some books. Here are a quick few (there are many, many more), but find ones that makes sense to you -- first.

Domain-Driven Design: Tackling Complexity in the Heart of Software
Patterns of Enterprise Application Architecture
Pragmatic Programmer
Code Complete
Design Patterns: Elements of Reusable Object-Oriented Software
Refactoring: Improving the Design of Existing Code
Head First Design Patterns


And you'll need to learn OOP not because it is better or for any of the other nonsense the flamers say. The reason you need to learn OOP is that no one writes or thinks about procedural/sturctured programmer anymore -- so you have little help. With OOP there are hundreds design books in the last 5 years on the latest methodologies and practices.

And finally you might want to try some Agile methologies. They are ways to deal with the fact that we are not as smart as we think we are and we really don't know as much about our projects as we think we do. They deal with the whole "I find that something needs to be drastically changed, or something is too hard, or that I left out something really important" part -- and believe me you are not alone. I have exactly the same problems.

Posted: Sat Jul 01, 2006 9:22 pm
by Starcraftmazter
Alright thanks guys, I'll look into some of those books.

Posted: Wed Jul 05, 2006 4:57 am
by Yossarian
And you'll need to learn OOP not because it is better or for any of the other nonsense the flamers say. The reason you need to learn OOP is that no one writes or thinks about procedural/sturctured programmer anymore -- so you have little help. With OOP there are hundreds design books in the last 5 years on the latest methodologies and practices.
The big revelation for me is that once you start to learn the lingo, then think in OOP you suddenly widen your vistas.

Its not just fellow PHPers you can get advice from. Using the shared taxonomy of patterns, suddenly you can make sense of Java, C# programmers experience.

You really do feel as though you are "standing on the shoulders of others".

For my money, this very approachable book really got me started: Head First Design Patterns, but as Arborint says, be prepared to spend time in bookshops flicking through what you need.

P

Posted: Thu Jul 06, 2006 3:38 am
by alvinphp
What you seem to be looking for is project planning. There is an entire field dedicated to this aspect of development (this is what I get paid to do). Like programming there are many methodologies you can use to help you properly plan your project. For the most part they call these methodologies System Development Life Cycles. Since it looks like you will be doing this project yourself you probably do not need a full SDLC. I would say creating a Use Case, Class Diagram, and ERD would help you see your project at a high level so you can see all the big parts. Another good idea, that Hockey mentioned, is to make a mock up first where you can see everything you are going to build before you start coding.

And, like programming, the process of project planning has many flavors, is constantly being improved upon, and past Best Practices are continually being challenged.

Hope this helps.

Posted: Thu Jul 06, 2006 11:43 am
by Nathaniel
alvinphp wrote:What you seem to be looking for is project planning. There is an entire field dedicated to this aspect of development (this is what I get paid to do). Like programming there are many methodologies you can use to help you properly plan your project. For the most part they call these methodologies System Development Life Cycles. Since it looks like you will be doing this project yourself you probably do not need a full SDLC. I would say creating a Use Case, Class Diagram, and ERD would help you see your project at a high level so you can see all the big parts. Another good idea, that Hockey mentioned, is to make a mock up first where you can see everything you are going to build before you start coding.
To me, he seems to understand that he has to outline the major parts. I think his problem is not understanding how to refactor.
The problem which I always have is this:
Once I start the project, I have a fairly good idea of what it's going to look like, how it's going to work, etc. But during development I find that something needs to be drastically changed, or something is too hard, or that I left out something really important - which actually happens quite a bit, and due to this i have to recode hundreds of lines....and by the time I'm finished, although works, the project code looks very messy.
I used to be in the same mess. For me, it was a two-step solution:
1. Download SimpleTest, and learn how to use it. It sounded dumb to me at first, but now I just love it. It may take a while, give it time. You'll thank yourself for it later.
2. Buy Refactoring, by Martin Fowler. Amazon has it for $42. I just got it yesterday, and boy is it pretty. Useful, too. I already went through my current project to use Introduce Null Object. :D (/me is giddy about new book)

A lot of your problem is solved with experience, but with the experts to guide you along, and by making the plunge to test driven design (SimpleTest), you will gain experience much, much faster. :)

- Nathaniel

Posted: Thu Jul 06, 2006 12:56 pm
by Christopher
Nathaniel wrote:To me, he seems to understand that he has to outline the major parts. I think his problem is not understanding how to refactor.
The problem which I always have is this:
Once I start the project, I have a fairly good idea of what it's going to look like, how it's going to work, etc. But during development I find that something needs to be drastically changed, or something is too hard, or that I left out something really important - which actually happens quite a bit, and due to this i have to recode hundreds of lines....and by the time I'm finished, although works, the project code looks very messy.
By the sound of the changes required it sounds more like a design issue. Refactoring can help improve code, but if the interfaces were not designed well they you are beyond Refactoring and back to Redesign. I think your suggestion of heading down a semi-TDD route is good advice (and that book is excellent!)

Posted: Thu Jul 06, 2006 3:10 pm
by Nathaniel
arborint wrote:By the sound of the changes required it sounds more like a design issue. Refactoring can help improve code, but if the interfaces were not designed well they you are beyond Refactoring and back to Redesign. I think your suggestion of heading down a semi-TDD route is good advice (and that book is excellent!)
True. My first comment was poorly worded. But the TDD route, with some practice, should take care of many of the interface issues, right?

Posted: Thu Jul 06, 2006 6:09 pm
by Christopher
Nathaniel wrote:But the TDD route, with some practice, should take care of many of the interface issues, right?
Yes, and the Refactoring book was a great suggestion. One of the goals of TDD is to focus you on the things you actually have enough information to design and build. Once you build one thing then you know more and therefore can design and build more. That helps get the interfaces right. Another side effect of TDD is that you tend not to build unnecessary things as well.

Posted: Fri Jul 07, 2006 3:42 am
by Maugrim_The_Reaper
2. Buy Refactoring, by Martin Fowler. Amazon has it for $42. I just got it yesterday, and boy is it pretty. Useful, too. I already went through my current project to use Introduce Null Object. Very Happy (/me is giddy about new book)
The next best book after whichever Patterns volume you go with... There are few books that seem to open a big door in your mind and suddenly let you see things so much clearly - but this is one. If reading Refactoring doesn't make you a better programmer then you're a lost cause...:). In combination with TDD it's lethal.

Posted: Fri Jul 07, 2006 9:10 am
by Ambush Commander
On a different tack, this link gives some interesting suggestions: http://www.joelonsoftware.com/articles/ ... 00043.html . It's directed to the more general problem of better code, but a lot of the things it recommends will also improve design.

I've also been experimenting with design by writing copious amounts of notes. You'll want to understand fully the entire system, including the gritty details, before writing a single speck of code.

Spend time finding good names for objects too.

This by no means belittles the significance of the books recommended. Read them. :-D

Posted: Mon Aug 07, 2006 11:50 pm
by Luke
article wrote:A score of 12 is perfect, 11 is tolerable, but 10 or lower and you've got serious problems. The truth is that most software organizations are running with a score of 2 or 3, and they need serious help, because companies like Microsoft run at 12 full-time.
I may be mistaken, but to my knowlede, Microsoft run at more like an 8.

(sorry if this is a bump... is a month too old to post?)