If you were to accept a role as a full time web app developer responsible for creating a new application from scratch, how much of a defined specification and design would need and/or expect to start development?

What tools/software is even used for this (for web apps built with something like RoR)? I would expect a mockup/wireframe to be required, but what else is done in the design stage? What is the best method or process to convey the functionality of the application so that developers know what to translate into code.

I'm interested to hear from web app developers who have thought: "If I only had <this>, I could develop this so much quicker/easier/cleaner", or "I have no idea what this customer wants unless they document it in <thing>."

I'm not trying to start a philosophical debate, I am curious from the developers' perspective what is the "right" way to design web apps from scratch. There is probably a book somewhere that someone can tell me to RTFM, but I've only been able to find resources on learning actual coding and development, not the design phase.

closed as primarily opinion-based by Jim G., GrandmasterB, gnat, Aaronaught, ozz Oct 1 '13 at 10:55

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 2
    Enough to know what you are doing. – Robert Harvey Sep 28 '13 at 17:58

It depends.

My favorite project I did started off with the specification of "Make the knowledge base browse-able." Thats it. One sentence. I worked with the knowledge manager (who was responsible for the data and structure of the knowledge base), and a user interface guy. And we did it. Turned out to be a very successful project in part because the goal donor (same as gold owner in this case) didn't have any preconceptions of how the final thing worked - just that it worked and trusted us enough to let us make it.

On the other hand, there have been projects with many integration points between different teams where there were dozens of xsds floating around that specified every detail of the interface. The business came to us with mock ups of what they wanted and all the rules for how each field behaved and what was sent to the other systems. This worked too - and it was necessary. If any one team went off and did their own thing, it would have fallen like a house of cards once we tried to put it together. There were reams of paper that represented various versions of the specification.

Recently, one of the companies that subcontracts work to my current employer commented that they are very happy with us because they give us not much in the way of specifications and we do what they were thinking (our project managers must be telepathic).

There is no right answer, it depends completely on what the expectations of the client (be it another business uint in the company you work for, or an external client). The more they expect things and the less they trust you do to the right thing and accept what you give them, the more the work will need to specified.

One set of the approaches that was taken up to try to address this are the iterative methodologies. The idea with these is you build something in a short time period and then ask "is this what you were thinking?" Each iteration you add functionality or change it as the client asks. The most well known of these approaches is agile (which itself encompasses a range of methodologies).

As to books? There are dozens of them. Seriously, dozens. Maybe dozens of dozens if not more (there's no one book that we can tell you will solve that problem - just go into the project management section of a library or bookstore and start thumbing through them).

Not the answer you're looking for? Browse other questions tagged or ask your own question.