Ask YC: best development/project process? | Hacker News Reader

Ask YC: best development/project process?

2 pointsmodoc5 comments

Yes, I know there is no "best" process.

I'm in the position of needing to define the project life-cycle and development process for a new development practice being built within a medium-sized consulting company that has until recently focused on branding/marketing. I've made pages and pages of notes, and have looked a number of development methodologies, but I was hoping to tap into the experience and intelligence here.

Here are the relevant guidelines:

The clients are all external companies, mostly large, paying for expensive projects (therefore scope, meeting dates, quality, etc...) are all critical.

Most of the projects will be ground-up implementations of large, complex, Java-based web applications.

The project teams are distributed across multiple states, and may include off-shore resources at times.

The project teams will typically have a mix of experienced architect/tech-lead individuals and inexperienced people fresh out of training.

My current thoughts: Due to the external clients, it's important to document and lock down the scope, budget, timeframe, etc... as much as possible. So start out with a waterfall-ish process, with a series of steps, with hard gates, sign-offs, etc...

Break down the development into small feature based iterations. Have the architect design the approach for the first iteration (class skeletons, some commented psuedo-code, arch approach docs).

Do iteration based, scrum-style development, with daily time-boxed con-calls, using GreenHopper+Jira for task management, scrum cards, etc...

Formal test plans and test phases.

Anyhow, I'd LOVE to hear your thoughts, experiences, etc... about project process, development cycle process, tools to support it, etc.... Thanks!

one of the worst things about large projects is the number of developers/teams. if you have too many people, things go wrong and if you don't have enough, projects fall behind. so there is a art to this to create that balance.

Also as a developer, I would apply some programming principles to project management. for example design-by-contract where you create interfaces that define interaction with a group of classes, etc. So you divide groups/people by function, ie UI, back-end, integration, etc. then each group would define what they need from the other groups and what they would be able to produce. you can then develop some process based on those requirements. I think the person doing integration with have the most input into this. he/she has to deal with static pages and at the same time with server side code. so its really an interface himself

Another thing I don't like about large groups is QA. I would not have them at all. perhaps one person that would give demo of the on going project to the clients. if he can give the demo without running to problem and the clients are happy with what they see then you have a QA.

one other note, create a sub group of a select few that really understand and have a good vision of the results. they should meet and review/audit everything and catch design errors before it becomes too late.

and finally don't manage things employees in a company. think in terms of a research project in a univercity. with lead developers as staff and everyone else as students. you can use you imagination as to how this would effect every aspect of your project.

PS: I've also worked on ATG in the past but now I'm working on tomcat and other open source.

Thanks for your insight. We'd probably have one team per project, with hopefully the right number of people on each team, staffed based on the LOEs we build during the architecture design phase. Dev team size would probably be 3-6, plus creative, mgmt, qa, etc...

I like the idea of the research project paradigm, as long as we remember the stricter timelines and higher consequences of failure:)

I have to disagree with the QA thing though. It's important to test every flow, in every major browser, on every major OS. It's also important to see what happens when you leave this field blank and submit the form, or put in bad data here, or use the back button and try to do something again. When you're delivering a multi-million dollar project, it can't go out the door and break on IE6 or Firefox, or break whenever someone enters a zip code that doesn't exist.

PS: there are TONS of really really high buck ATG contracts available all over the US right now. If you're interested I know a ton of companies who are dying to find an experienced ATG dev (back end or front end), so feel free to email me.

Thanks but I quit my last job few months ago so that I could work full time on my own project.

on the QA I guess what I was trying to get to was to not let your developers rely too much on QA team to catch the errors.

"it's important to document and lock down the scope, budget, timeframe"

In order to do any of these, you must first lock down the "big fat what". Analysis. Functional specification. Specs. Whatever you want to call it. Putting any kind of rigorous or formal framework on a project with "fuzzy specs" is a disaster waiting to happen.

Get really, really good at defining EXACTLY WHAT the end product will be. Don't fall into the trap of saying, "That's close enough, after the next prototype we'll know more." That kind of thinking works well in a product business, but not in a service business.

"Give me six hours to chop down a tree and I will spend the first four sharpening the axe." - Abraham Lincoln

I totally agree! Defining what the client wants and exactly how it will be delivered is crucial.

Reply on news.ycombinator.com