View Single Post
Old 05-19-2010, 06:52 AM  
Un4given
Registered User
 
Un4given's Avatar
 
Join Date: Jan 2008
Posts: 16

Quote:
Originally Posted by BestXXXPorn View Post
No disrespect but I completely disagree with your assessment of software design being research. It should never be research... Many of the problems you've listed as being an "always prevalent issue" just simply aren't the case with solid developers and project managers that know how to scope a project correctly.

Everything you've written seems to assume there's this giant missing gap between the ones asking for a piece of software and the ones developing the piece of software. I've seen RFPs come through tighter than a frogs ass with wireframes already completed. They know what they want and they get exactly what they want delivered. It's also REALLY easy to cost those as everything is practically taken care of...

It is the lead developer's job to acquire all domain knowledge of a business and completely understand what the end goal of the software is before ever even writing a requirements doc (if a well done one isn't provided with the RFP). I have specialized in high end complex systems for the past 11 years. I've written four systems which have been multiple year projects. As a result, I don't have a big portfolio of sites but I'm very good at what I do...

The main problem arises when a client asks for an application to do x, y, z... If the dev company doesn't have someone that is experienced and really knows what they're doing, they're going to start building a system which does x, y, z. What they SHOULD be doing is the aforementioned; learn the business. When I build even a medium sized system I travel to the place of business. I sit down with someone from every level of the ORG and I start asking questions. I start with simple ones:

What do you expect this system to do?
What would make your job a HUNDRED times easier for you?

You would be amazed at how excited the whole company gets that they're getting a hand in "creating" this software that's going to make their lives easier. Then I'll sit and watch them work for a while performing their daily tasks that would interface with this proposed system. I tell them, "hey, now's your chance to vent about all the shit you hate about your current process". In the first 5 minutes you'll get to hear things you never would have thought to put in the system and learn ways to design the UI in such a manner that you're genuinely increasing their productivity. This understanding is CRUX to building a system which works best for the client.

After the first pass I go back and wire frame out the entire site. Then I go back to the business and show them around, get people's opinions, and make revisions if necessary.

Notice this is all the research part you talked about... but it certainly doesn't touch my dev team until ALL the research is done. You don't start coding until you know exactly what you're building. This process, for larger projects, can take well over a month, easy.

After it's all complete and has client approval I draft the requirements for the development team, lay the framework, and the coding begins. I've always delivered a product that has never needed revisions to core pieces of functionality or flow of information. There is no research involved during coding, only execution.


I can name 5 web development companies off the top of my head that I've had personal experience with that do things this way... None of them are in the adult space. The going rate for development in the adult space is a fraction of what these guys cost. There is a 1:1 correlation there ;) You get what you pay for. That's not to say there aren't plenty of main stream web development companies who don't do this and will charge the same price however :P

In a nutshell; the majority of issues you're describing are all communication problems and inexperienced developer/project manager problems. Perhaps because you're a consultant aiming to alleviate these exact problems? Was this an informative post or a sales pitch? I gather it's a little bit of both but some of the information is quite misleading IMO

PS: Post both parts together next time, makes it easier :P
This article is about what makes developing software different from other
forms of building. It does not propose solutions, which would come later
after discussing different methodologies and design principles.

That is when you beat your chest and make your sales pitch.
Un4given is offline   Share thread on Digg Share thread on Twitter Share thread on Reddit Share thread on Facebook Reply With Quote