Speeding Up Work

Express the business side of your digital lives. Share your experiences and/or your comments regarding a business or organization.

No advertising.

Moderator: General Moderators

jack_indigo
Forum Contributor
Posts: 186
Joined: Sun Jun 08, 2008 11:25 pm

Speeding Up Work

Post by jack_indigo »

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.
User avatar
Ollie Saunders
DevNet Master
Posts: 3179
Joined: Tue May 24, 2005 6:01 pm
Location: UK

Re: Speeding Up Work

Post by Ollie Saunders »

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 think by creating all the pages in HTML/CSS you run the risk of having to change them later, this risk gets worse as more pages are required so it doesn't scale.

What I would recommend instead is paper prototyping http://www.alistapart.com/articles/paperprototyping and you can do this with the client, in their office.
User avatar
onion2k
Jedi Mod
Posts: 5263
Joined: Tue Dec 21, 2004 5:03 pm
Location: usrlab.com

Re: Speeding Up Work

Post by onion2k »

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.
User avatar
Ollie Saunders
DevNet Master
Posts: 3179
Joined: Tue May 24, 2005 6:01 pm
Location: UK

Re: Speeding Up Work

Post by Ollie Saunders »

Sounds like the waterfall methodology, onion2k. There are better things like agile and scrum.
User avatar
onion2k
Jedi Mod
Posts: 5263
Joined: Tue Dec 21, 2004 5:03 pm
Location: usrlab.com

Re: Speeding Up Work

Post by onion2k »

Ollie Saunders wrote:Sounds like the waterfall methodology, onion2k. There are better things like agile and scrum.
What I posted is a system for developing the site. The development of the code (points 6, 7 and 8) can be any methodology you fancy. In all development methodologies where there's a client involved you really need a spec to start with, that's all I'm driving at.
User avatar
Ollie Saunders
DevNet Master
Posts: 3179
Joined: Tue May 24, 2005 6:01 pm
Location: UK

Re: Speeding Up Work

Post by Ollie Saunders »

Methodologies are for software projects, not all aspects of software projects are code. Agile and Scrum could easily be applied to how you handle all of those points.
In all development methodologies where there's a client involved you really need a spec to start with, that's all I'm driving at.
A lot of people say this, and yes I do understand this is what clients want. However it isn't in their best interest so I don't completely believe that they can never be convinced to use an agile approach. But then again I'm not generally prepared to work with tools or methodology when I know better is available and I understand this bothers other people less.
User avatar
Eran
DevNet Master
Posts: 3549
Joined: Fri Jan 18, 2008 12:36 am
Location: Israel, ME

Re: Speeding Up Work

Post by Eran »

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.
User avatar
onion2k
Jedi Mod
Posts: 5263
Joined: Tue Dec 21, 2004 5:03 pm
Location: usrlab.com

Re: Speeding Up Work

Post by onion2k »

Ollie Saunders wrote:
In all development methodologies where there's a client involved you really need a spec to start with, that's all I'm driving at.
A lot of people say this, and yes I do understand this is what clients want. However it isn't in their best interest so I don't completely believe that they can never be convinced to use an agile approach.
Absolutely it's not in the client's best interest - it's in our best interest. Unless you're in the enviable position where the client is paying by the day or by the hour rather than a fixed price for the whole project it's in your interest to lock down the clients expectation at the beginning, otherwise you'll end up giving them a whole raft of things that you hadn't considered at the start, and hadn't built into the project cost.

This is an interesting point actually - if you don't spec a site at the beginning how do you estimate the cost?
User avatar
Ollie Saunders
DevNet Master
Posts: 3179
Joined: Tue May 24, 2005 6:01 pm
Location: UK

Re: Speeding Up Work

Post by Ollie Saunders »

Absolutely it's not in the client's best interest - it's in our best interest
How so?

Agile addresses the fact that neither you or the client really know what is required from software in order to satisfy a business goal and allows both you and the client to see the effectiveness of early assumptions as early as possible and adapt them as necessary (client's interest). It also addresses issues of business change (client's interest) and makes productive development sustainable (client's interest).

On smaller projects the risk of business change is small and sustainability is less of an issue simply because it's a smaller code-base that will take less time to produce. But unless you have a very well defined basis for the project like... "Our competitor has this tool. Here's a printout of the kinds of reports it produces. Could you make this for us?" you will find specifications to lead you down the path of implementing the wrong (or not quite as good as it should have been) solution. I'm talking about web applications and functionality here not web sites with a bit of PHP stuck in to manage some content; those are a different ball game and primarily a web design and information architecture concern not a software development one.
Unless you're in the enviable position where the client is paying by the day or by the hour rather than a fixed price for the whole project it's in your interest to lock down the clients expectation at the beginning, otherwise you'll end up giving them a whole raft of things that you hadn't considered at the start, and hadn't built into the project cost.
Yes, absolutely. But is billing per iteration really so unattainable? You have all the benefits of Agile, no contract locking in either side, less money up-front is better for their cash flow and the developer is forced to continuously deliver valuable functionality. If clients are still uncomfortable with that you could always price each bit of functionality.
This is an interesting point actually - if you don't spec a site at the beginning how do you estimate the cost?
Well you still have to provide some kind of estimate so you might was well write a spec when you start in order to make a decent pitch. The difference is once you've got the work you'll throw that spec away and ask the client "OK...what is the absolutely most important piece of functionality you need?" and go from there.
User avatar
onion2k
Jedi Mod
Posts: 5263
Joined: Tue Dec 21, 2004 5:03 pm
Location: usrlab.com

Re: Speeding Up Work

Post by onion2k »

Ollie Saunders wrote:The difference is once you've got the work you'll throw that spec away and ask the client "OK...what is the absolutely most important piece of functionality you need?" and go from there.
I'd wager a significant amount of money that all of my clients would answer that with "I don't know". :lol:
User avatar
Ollie Saunders
DevNet Master
Posts: 3179
Joined: Tue May 24, 2005 6:01 pm
Location: UK

Re: Speeding Up Work

Post by Ollie Saunders »

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.
User avatar
Christopher
Site Administrator
Posts: 13595
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Re: Speeding Up Work

Post by Christopher »

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)
User avatar
Ollie Saunders
DevNet Master
Posts: 3179
Joined: Tue May 24, 2005 6:01 pm
Location: UK

Re: Speeding Up Work

Post by Ollie Saunders »

arborint wrote:I agree with onion that there needs to be some structure to the entire process when you have actual businesses involved.
I'm not quite sure what you are saying here. I don't think you are suggesting that agile is unstructured. Structure to me means planning and something methodical. Obviously structure is a good thing, we just need the right kind of structure and the right amount.
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.
Absolutely but I don't think the concept of an iterative, adaptive workflow is particularly technical. The practise of programming, data and user interaction is complex; it is these things that we have to communicate analogously. But to understand agile all you really need to know are a couple of truths about the nature of software development (the client doesn't even need to understand why these are the case, just accept them) and then you can explain how agile works to cope with the implications of these truths. I certainly feel that I could explain the reasons why agile is better than the waterfall methodology to my parents and they would understand. It's just business.
However, I really agree with Ollie that it is important to focus on what is important and what is actually known
Sure, we try to find out what is known but very often people know very little. We develop software based on assumptions. We assume that x interface will speed things up that y employ understands z term and there are so many of these you can't possibly go round asking everybody and testing whether they are true or not, you just have to implement them and observe the result: inspect and adapt. It gets rid of a lot of analysis, discussion and politics.
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.
That's probably a good approach considering how reluctant people are to stick their heads out. If that are willing it's got to be a safe bet.
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.
Yes, this way nobody is responsible if it should fail. This indicates a negative corporate culture though, one that expects to fail, one that prefers damage limitation over working to ensuring success, one where employees compete to achieve rather than work together.
(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.)
What do you mean by this?
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.
It is your responsibility as much as it is the client's. Neither of you can do it alone. But the beatify of agile is that you don't have to get it right first time, there's lots of opportunity for correction so you don't have to come into the business like an arrogant management consultant and attempt to find all the worms under the stones and really nail things down in specs you just have to use a bit of intuition.
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.
I might be missing something but I would say this is a side point to our discussion. I definitely agree though. Good terminology can save so much time and prevent many misunderstandings.
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.
If you can get real business people together and write user stories with them you'll quickly find out what is known and what isn't.
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.
Can you tell us more? What did he miss? What was the project?
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.
I would be interested to know what those things were.
User avatar
Christopher
Site Administrator
Posts: 13595
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Re: Speeding Up Work

Post by Christopher »

Ollie Saunders wrote:
(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.)
What do you mean by this?
I find very often (almost always with e-commerce) that companies have implemented a system that includes several steps that require a person with specific knowledge of business is required to make that step work. Most often they don't know that they have these steps until they try to automate the system. At that point they realize that no one can really explain the rules at that point because they are often workarounds of failings several other places. It is usually obvious to an outsider what they problems are. Because the website automates business process, the question becomes whether to model the madness or change the business practices. Accounting systems are probably the most frequent offender and I often need to implement manual steps in the process. Often I just implement an improved system that key people agree to and the company uses it as a reason to upgrade their internal processes -- so it can be a good thing. But it should be a red flag to developers because you will meet resistance whenever change is required.
Ollie Saunders wrote:
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.
I might be missing something but I would say this is a side point to our discussion. I definitely agree though. Good terminology can save so much time and prevent many misunderstandings.
The idea of Ubiquitous Language takes the idea of terminology to the next step. You try to see out the ways that the business talks about the domain and use that language throughout the project. Conversely, you also need to educate non-technical people with technical terms critical to the project.
Ollie Saunders wrote:
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.
Can you tell us more? What did he miss? What was the project?
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.
I would be interested to know what those things were.
One example I can think of is that there were two main areas of the site: a public area and a private area for resellers. The two areas were defined by different groups (marketing and support) and it each designed its own main menu items. The designer, who was the interface with the client, thinking in 2D terms happily designed the site as everyone requested. It went through a couple reviews and everyone was happy with the design.

When I was brought on-board, one of the first things I noticed was that there was no way to navigate between the public and private areas. Because programmers tend to think of a site as an interconnected 3D space that you navigate through -- I noticed the problem. Two solutions were proposed. I recommended one and let the designer know that while the other fixed some things, it would cause problems specifically with the registration process. Because they could not visualize the registration problem, they chose the other solution (which looked better to them). We implemented it and when it became clear that it would not meet a key need, we changed it for the third time.

That kind of thing is pretty common on projects. The most important thing from my point-of-view of course it that I get paid for all the work. Not a problem on time-and-materials, but if fixed-bid then you need to size up the client properly. In the example above there were actually two clients: the designer and the company.
(#10850)
koen.h
Forum Contributor
Posts: 268
Joined: Sat May 03, 2008 8:43 am

Re: Speeding Up Work

Post by koen.h »

What's often done and comes close to what's described in the first post is using a wireframe.

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.
Post Reply