PHP Developers Network

A community of PHP developers offering assistance, advice, discussion, and friendship.
 
Loading
It is currently Sun Nov 17, 2019 6:44 pm

All times are UTC - 5 hours




Post new topic Reply to topic  [ 24 posts ]  Go to page 1, 2  Next
Author Message
 Post subject: Speeding Up Work
PostPosted: Fri Jul 11, 2008 10:26 am 
Offline
Forum Contributor

Joined: Sun Jun 08, 2008 11:25 pm
Posts: 186
I've come to realize now that one of the fastest things I can do on a project is to draw up the XHTML/CSS stuff first, drawing out every page and admin page, before I even start work. Of course, if the client has a designer in mind, or can use who I recommend, that's great. But if they're cheap and cannot, then it's best if I start on every page.

I had this all wrong, really. I used to draw each part of the site as I went along, and then have these painful discoveries with the client where, once they visualized something, they would either have feature creep or explain that they messed up in the functional spec or were not clear enough or that I interpreted thing completely wrong. By drawing a UI all the way through and presenting it to the client, it makes the functional spec that much more clear.

At that point, building the site moves along much faster because it's just a matter of plugging in items into the backend database.


Top
 Profile  
 
 Post subject: Re: Speeding Up Work
PostPosted: Fri Jul 11, 2008 12:09 pm 
Offline
DevNet Master
User avatar

Joined: Tue May 24, 2005 6:01 pm
Posts: 3179
Location: UK


Top
 Profile  
 
 Post subject: Re: Speeding Up Work
PostPosted: Fri Jul 11, 2008 12:38 pm 
Offline
Jedi Mod
User avatar

Joined: Tue Dec 21, 2004 6:03 pm
Posts: 5263
Location: usrlab.com
The process I feel works to build a site quickest is:

1. Gather the requirements for the site. Sit down with the client (or not) and work through every section of the site writing down what it needs to do. Requirements should be simple - things like "List all the users with orderable columns, a search facility, and buttons to go to an edit page or delete the user" for an admin listing page.

2. Write the specification. Flesh out the requirements with more detail. List fields that will be required for each data element. Write down lists of field elements needed in each form in the site. That sort of thing. By the end of that you should be in a position to hand that spec over to someone who's never heard of the site before and they should be able to make a good stab at building it.

3. Design the database schema.

4. Copy a framework site if you have one*, else write the framework code.

5. Design the look of the site.

6. Build the admin systems.

7. Build the front end systems.

8. Walk through with the client noting any required changes, then revisit the code and change what's needed.

9. Testing, testing, testing.

10. Live!

Basically, my point is that if you get the requirements and spec down properly at the start then the rest will fall into place. The thing that slows development down is when the developer doesn't know exactly what's needed so they have to make it up themselves. That's where feature creep becomes a problem, and with a less experienced developer it's also where bad code starts to be produced because they're stressing over what to write rather than how to write it.

I only wish my boss would come around to my point of view. :(

* A framework in this case is a library of code that you use on every site... a standard directory structure with all the right bits of code you need like Swiftmailer, ADODB Lite, Smarty, jQuery, a standard constants file, includes file or autoloader that loads everything, standard HTML header and closing footer.. with an empty images directory, content directory, etc etc. All empty but ready to be filled in with the details of the latest site you're building.


Top
 Profile  
 
 Post subject: Re: Speeding Up Work
PostPosted: Fri Jul 11, 2008 1:10 pm 
Offline
DevNet Master
User avatar

Joined: Tue May 24, 2005 6:01 pm
Posts: 3179
Location: UK
Sounds like the waterfall methodology, onion2k. There are better things like agile and scrum.


Top
 Profile  
 
 Post subject: Re: Speeding Up Work
PostPosted: Fri Jul 11, 2008 2:03 pm 
Offline
Jedi Mod
User avatar

Joined: Tue Dec 21, 2004 6:03 pm
Posts: 5263
Location: usrlab.com


Top
 Profile  
 
 Post subject: Re: Speeding Up Work
PostPosted: Fri Jul 11, 2008 7:16 pm 
Offline
DevNet Master
User avatar

Joined: Tue May 24, 2005 6:01 pm
Posts: 3179
Location: UK


Top
 Profile  
 
 Post subject: Re: Speeding Up Work
PostPosted: Fri Jul 11, 2008 7:28 pm 
Offline
DevNet Master
User avatar

Joined: Fri Jan 18, 2008 1:36 am
Posts: 3549
Location: Israel, ME
I agree with onion on the general process. What with typical website development time being between a few days to a few weeks, using agile methods is not relevant unless you can / want to be in daily / hourly contact with the client.

On larger projects I would agree that agile methods are the way to go, as specs have a way of changing constantly over time.


Top
 Profile  
 
 Post subject: Re: Speeding Up Work
PostPosted: Sat Jul 12, 2008 4:40 am 
Offline
Jedi Mod
User avatar

Joined: Tue Dec 21, 2004 6:03 pm
Posts: 5263
Location: usrlab.com


Top
 Profile  
 
 Post subject: Re: Speeding Up Work
PostPosted: Sat Jul 12, 2008 11:52 am 
Offline
DevNet Master
User avatar

Joined: Tue May 24, 2005 6:01 pm
Posts: 3179
Location: UK


Top
 Profile  
 
 Post subject: Re: Speeding Up Work
PostPosted: Sat Jul 12, 2008 12:30 pm 
Offline
Jedi Mod
User avatar

Joined: Tue Dec 21, 2004 6:03 pm
Posts: 5263
Location: usrlab.com


Top
 Profile  
 
 Post subject: Re: Speeding Up Work
PostPosted: Sat Jul 12, 2008 3:33 pm 
Offline
DevNet Master
User avatar

Joined: Tue May 24, 2005 6:01 pm
Posts: 3179
Location: UK
Well they should know what is important to their business and the problems they need to solve. Even if they can't decide what the absolute most important thing is they can probably put them in some kind of order of priority and that is all that is necessary.


Top
 Profile  
 
 Post subject: Re: Speeding Up Work
PostPosted: Sat Jul 12, 2008 6:16 pm 
Offline
Site Administrator
User avatar

Joined: Wed Aug 25, 2004 7:54 pm
Posts: 13592
Location: New York, NY, US
I agree with onion that there needs to be some structure to the entire process when you have actual businesses involved. This is mainly because the non-technical parts of the business need to be able to think about the project with some kind of familiar reference. The project needs management from multiple areas, so familiar management methods makes sense.

However, I really agree with Ollie that it is important to focus on what is important and what is actually known as you work through the entire process. I think it is actually easier than you might think. I tend to winnow it down by finding the things that 1) every agrees on, and 2) people will take responsibility for the decision. Projects are often a bunch of people/depts dumb ideas assembled together into what looks like a coherent whole. We always find the truth later. (It is interesting that this is often because the business rules of the company are actually broken, but are made to work by some human system specific to that business they have implemented to work around the broken rules.)

In answer to onion's comment that his clients would not be able to answer the question "what is most important" -- that's why they hired you. You need to listen to what they are saying, not necessarily what they say. I think one of the most important things is to listen for the Ubiquitous Language of the group. Then you can use terms that are understood, define terms that are not defined, and find new terms when there is disagreement within the group. If you can talk really about then you can do it well.

And I want to emphasize the "really" in some of these Agile ideas. There is a different in thinking you know something and really understanding it. There is a difference between talking about the project and really communicating project ideas.

I just did a project the last couple weeks. I only did back-end work. The communication was mainly between the designer and the client. It did not go that smoothly (at least from my POV) because the designer did not focus first on: the known stuff, the common stuff and the basic stuff. And they implemented some things early in the process that the client said they wanted, even though it was obvious they would be problematic or not work. The designer thought is was really important to "plan the whole thing out" and I think this project once again showed what a bad idea that is...

_________________
(#10850)


Top
 Profile  
 
 Post subject: Re: Speeding Up Work
PostPosted: Sat Jul 12, 2008 7:46 pm 
Offline
DevNet Master
User avatar

Joined: Tue May 24, 2005 6:01 pm
Posts: 3179
Location: UK


Top
 Profile  
 
 Post subject: Re: Speeding Up Work
PostPosted: Sun Jul 13, 2008 1:18 pm 
Offline
Site Administrator
User avatar

Joined: Wed Aug 25, 2004 7:54 pm
Posts: 13592
Location: New York, NY, US

_________________
(#10850)


Top
 Profile  
 
 Post subject: Re: Speeding Up Work
PostPosted: Mon Jul 14, 2008 3:22 pm 
Offline
Forum Contributor

Joined: Sat May 03, 2008 8:43 am
Posts: 268
What's often done and comes close to what's described in the first post is using a .

You have the requirements before you and you start creating a site structure with html:
-CSS at this stage is minimal as in this stage visuals don't matter
-not all pages are needed, eg one of a series of similar pages (a blog post is an example)
-functionality is non-existent, forms do not work
-lots of lorem ipsum text

The idea is to give the customer a feel for how he can click through the site and what will be on it. Once that is as wished, you can start implementing functionality.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 24 posts ]  Go to page 1, 2  Next

All times are UTC - 5 hours


Who is online

Users browsing this forum: No registered users and 3 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Jump to:  
Powered by phpBB® Forum Software © phpBB Group