I want to be a programmer's pinup girl.
August 1, 2006 2:45 PM Subscribe
I have applications galore mapped out in my head, and want to hire a coder to make them. Without coding knowledge, I want to be the dream client by submitting a GUI graphic and basic directives (like "initial screen displays these 6 buttons" "option for icon/text" "keep all screens no busier than 60% whitespace" "what problem is this app designed to solve?"). Can you supply/point me to such a developer/client questionnaire and free GUI template graphic maker? Please don't suggest I learn how myself right now -- I need these apps because I'm so overwhelmed with stuff to do! Thanks in advance.
If you're on a Mac and looking for a quick and dirty way to mock up interfaces I recommend OmniGraffle.
posted by sanitycheck at 2:52 PM on August 1, 2006
posted by sanitycheck at 2:52 PM on August 1, 2006
If you're using a PC, use MS-Visio and the Wireframe Stencils from Garrett Dimon. You can mock up a program very quickly and easily that way.
You could also do the same thing in Visual Studio .NET if you wanted to. It's an IDE, but you wouldn't actually have to do any programming, you'd just use the design view to drag and drop buttons and other controls.
posted by Hildago at 3:00 PM on August 1, 2006 [1 favorite]
You could also do the same thing in Visual Studio .NET if you wanted to. It's an IDE, but you wouldn't actually have to do any programming, you'd just use the design view to drag and drop buttons and other controls.
posted by Hildago at 3:00 PM on August 1, 2006 [1 favorite]
Response by poster: I'm on a PC unfortunately ... but thanks anyway!
What I am actually hoping for is that a developer might share with me the questionnaire given to prospective clients, I don't think my operating system would make a difference for that ... ?
And, Adamrice, re: "Also (and you probably know this) custom coding is a very expensive proposition." ...
Well, ok.
I did say I was looking to hire someone. I really meant I would be paying. I just wanted the templates of screenshots to be free, so that I could mark them correctly to give to the (paid) person for hire. Also, I think the simple applications might be cheaper than the more complex ones.
posted by thewhynotgirl at 3:06 PM on August 1, 2006
What I am actually hoping for is that a developer might share with me the questionnaire given to prospective clients, I don't think my operating system would make a difference for that ... ?
And, Adamrice, re: "Also (and you probably know this) custom coding is a very expensive proposition." ...
Well, ok.
I did say I was looking to hire someone. I really meant I would be paying. I just wanted the templates of screenshots to be free, so that I could mark them correctly to give to the (paid) person for hire. Also, I think the simple applications might be cheaper than the more complex ones.
posted by thewhynotgirl at 3:06 PM on August 1, 2006
Response by poster: Hildago, those look great! I believe they are just the thing for making the mock-up.
And, speaking of graphics, security and creativity -- yes, I do look at Mac features and drool ... but I have to be window-y for the next 3 years, so that's that ...
posted by thewhynotgirl at 3:19 PM on August 1, 2006
And, speaking of graphics, security and creativity -- yes, I do look at Mac features and drool ... but I have to be window-y for the next 3 years, so that's that ...
posted by thewhynotgirl at 3:19 PM on August 1, 2006
Depending on the complexity of the applications you are thinking about, you'll also need to give some thought to some Requirements documents - Business Requirements, which describe the business "problem" the application "solves"; and Functional Requirements (or Funcitonal Specifications), which describe, at an atomic level, how things should work. This includes behavior of things not seen on the screen (does work get saved when a user moves from one screen to the next? Is there context-sensitive help? etc), and how data behaves within the app (does it persist from one screen to the next). The Functional Reqs will also provide a traceable way to test the application, and ensure that any testing hits all the places where trouble may lurk.
It also strikes me that you may also want an Architecture document, to describe the technical structure of the application (is it thick/thin client? web-enabled? are there passwords, if so, how are they passed? where is the data held - in a database? if so, what kind (oracle, sql, etc) what kind of hardware is required...).
All of this is a long way of saying that there is more to a viable application than just screen shots.
posted by dbmcd at 3:23 PM on August 1, 2006
It also strikes me that you may also want an Architecture document, to describe the technical structure of the application (is it thick/thin client? web-enabled? are there passwords, if so, how are they passed? where is the data held - in a database? if so, what kind (oracle, sql, etc) what kind of hardware is required...).
All of this is a long way of saying that there is more to a viable application than just screen shots.
posted by dbmcd at 3:23 PM on August 1, 2006
(IAAC*) I'm going to second dbmcd in the requirements documents. UI mockups are all well and good, but are suprisingly little of the actual complexity of the application (although a good UI is pretty much a requirement for a app). As a developer myself, I'm currently dealing with a nightmare client that has no documentation, and a huge application they want me to work on.
Hildago mentioned Visual Studio .Net. There is currently a free version that you can download. As Hildago said, it's aimed at full development, but if you stick to design view, you could pretty easily mockup a simple interface.
The other thing that's nice from a client is to make sure they have a firm grasp of what they actually want from an application. Before submitting any UI or docs to a developer, make sure that you're not going to want to add a feature half way through. Feel free to email me (in the profile) about any of this stuff, I do custom applications fairly often, and if you have any specific questions, I'd be happy to answer them.
*I Am A (Software) Consultant
posted by KirTakat at 3:38 PM on August 1, 2006
Hildago mentioned Visual Studio .Net. There is currently a free version that you can download. As Hildago said, it's aimed at full development, but if you stick to design view, you could pretty easily mockup a simple interface.
The other thing that's nice from a client is to make sure they have a firm grasp of what they actually want from an application. Before submitting any UI or docs to a developer, make sure that you're not going to want to add a feature half way through. Feel free to email me (in the profile) about any of this stuff, I do custom applications fairly often, and if you have any specific questions, I'd be happy to answer them.
*I Am A (Software) Consultant
posted by KirTakat at 3:38 PM on August 1, 2006
*IAAPM - I should have been clearer that the Business Requirements fully lay out everything that the client wants the application to do. Once signed, they represent the agreed-upon scope of the project. Without clear, well-defined, detailed Business Requirements the dreaded Scope Creep is a given, and Functional Specifications are nearly impossible to derive/develop.
What KirTakat and I might be saying is: you may need a Business Analyst/consultant/Technical Writer to help out as well. Seldom is software developed with just the Designer and the Developer.
*I am a Project Manager
posted by dbmcd at 3:47 PM on August 1, 2006
What KirTakat and I might be saying is: you may need a Business Analyst/consultant/Technical Writer to help out as well. Seldom is software developed with just the Designer and the Developer.
*I am a Project Manager
posted by dbmcd at 3:47 PM on August 1, 2006
Yeah, write up a bunch of requirement documents rather than lay out the UI. Your programmer will want those anyway. I don't think you need to hire a tech writer to do it, but do make it complete.
(I Am A Software Engineer)
posted by cmonkey at 3:49 PM on August 1, 2006
(I Am A Software Engineer)
posted by cmonkey at 3:49 PM on August 1, 2006
Response by poster: dbmcd, those are what I would like a questionnaire for ... but slanted more toward a layman; for instance, I don't know enough to specify oracle, sql, vb, C+, etc ... but I could easily answer any pointed questions that would help a coder to determine what would be best for my needs along that line.
Assuming that such a person would be happy to have those answers at the onset of the request, I would like to be able to fill out such a questionnaire in preparation for making the request, but have not been able to find one online.
So what I've done is write:
* Here is the problem this application is to solve:
* Here is the way it solves the problem:
* Here is how I envision it working:
then I go on to describe what the user sees on each successive screen, what happens when I choose each option, what input or result is saved, where (i.e., program folder, subfolder text files, subfolder audio files, etc.), the visual representation of different features, and why the solution each option offers ... so the coder could see and/or make more realistic suggestions.
Problem is, I want to seem neither demanding nor neglectful ... maybe I'm assuming incorrectly where data folders should go, answering trivial specifics and neglecting more important ones.
A form that lists the generally important considerations (such as those you mention) that allow coders to more easily visualize and not have their time wasted would be so cool to have on hand. Graphic representation of GUI, as presented by me initially, would likely not even resemble the one the coder's experience dictates in final form.
If you are a coder --- feel free to shoot out questions you'd ask prospective clients; I'll put them into questionnaire form and upload the form to wherever anyone feels it might help out others -- also open to suggestions for that.
Thanks again :)
posted by thewhynotgirl at 3:53 PM on August 1, 2006
Assuming that such a person would be happy to have those answers at the onset of the request, I would like to be able to fill out such a questionnaire in preparation for making the request, but have not been able to find one online.
So what I've done is write:
* Here is the problem this application is to solve:
* Here is the way it solves the problem:
* Here is how I envision it working:
then I go on to describe what the user sees on each successive screen, what happens when I choose each option, what input or result is saved, where (i.e., program folder, subfolder text files, subfolder audio files, etc.), the visual representation of different features, and why the solution each option offers ... so the coder could see and/or make more realistic suggestions.
Problem is, I want to seem neither demanding nor neglectful ... maybe I'm assuming incorrectly where data folders should go, answering trivial specifics and neglecting more important ones.
A form that lists the generally important considerations (such as those you mention) that allow coders to more easily visualize and not have their time wasted would be so cool to have on hand. Graphic representation of GUI, as presented by me initially, would likely not even resemble the one the coder's experience dictates in final form.
If you are a coder --- feel free to shoot out questions you'd ask prospective clients; I'll put them into questionnaire form and upload the form to wherever anyone feels it might help out others -- also open to suggestions for that.
Thanks again :)
posted by thewhynotgirl at 3:53 PM on August 1, 2006
thewhynotgirl writes "What I am actually hoping for is that a developer might share with me the questionnaire given to prospective clients, "
There's no questionnaire; it's more like a Socratic dialog. The developer asks a bunch of questions, almost as if he's trying to trip you up.
He's looking for assumptions you take for granted, and inconsistencies in your plan that you're not yourself aware of. He'll ask you to go through your business process step-by-step, explaining what you do, or would do, without the benefit of a computer. He'll concentrate especially on "corner cases", areas where rules overlap or come to an end.
Here’s a brief example: client says he wants to count new and old customers per week over several years. Developer asks, what's a week? (Seems obvious; isn't. Is a week seven days or five business days, etc.) Developer asks, when does the first week of the year begin? (January 1, or the first Sunday of January, or the first Monday of January; all are accepted and contradictory definitions). What's a new customer? If Harvey is a new customer on Monday, and he comes in on Tuesday, that's two transactions, one new customer transaction, one existing customer transaction, and one unique customer. For that week, Harvey is considered both a new customer and an existing one. Is that what you really want, the developer asks.
And so forth. Good developers and designers notice possible inconsistancies and plan ahead for them, hammering away with increasingly detailed questions about minutia. Bad ones assume your assumptions match theirs. So a good developer is both more expensive and takes longer to question you than a bad one, leading some naive clients to think bad developers are good -- until they see the product, and end up paying for numerous change orders.
Anyone who hands you a standard questionairre is giving you a standard off-the-shelf product, not doing real custom design.
posted by orthogonality at 4:02 PM on August 1, 2006 [2 favorites]
There's no questionnaire; it's more like a Socratic dialog. The developer asks a bunch of questions, almost as if he's trying to trip you up.
He's looking for assumptions you take for granted, and inconsistencies in your plan that you're not yourself aware of. He'll ask you to go through your business process step-by-step, explaining what you do, or would do, without the benefit of a computer. He'll concentrate especially on "corner cases", areas where rules overlap or come to an end.
Here’s a brief example: client says he wants to count new and old customers per week over several years. Developer asks, what's a week? (Seems obvious; isn't. Is a week seven days or five business days, etc.) Developer asks, when does the first week of the year begin? (January 1, or the first Sunday of January, or the first Monday of January; all are accepted and contradictory definitions). What's a new customer? If Harvey is a new customer on Monday, and he comes in on Tuesday, that's two transactions, one new customer transaction, one existing customer transaction, and one unique customer. For that week, Harvey is considered both a new customer and an existing one. Is that what you really want, the developer asks.
And so forth. Good developers and designers notice possible inconsistancies and plan ahead for them, hammering away with increasingly detailed questions about minutia. Bad ones assume your assumptions match theirs. So a good developer is both more expensive and takes longer to question you than a bad one, leading some naive clients to think bad developers are good -- until they see the product, and end up paying for numerous change orders.
Anyone who hands you a standard questionairre is giving you a standard off-the-shelf product, not doing real custom design.
posted by orthogonality at 4:02 PM on August 1, 2006 [2 favorites]
Orthogonality's comment above is worth reading again, I think.
posted by Hildago at 4:25 PM on August 1, 2006
posted by Hildago at 4:25 PM on August 1, 2006
I am a programmer. Personally, I'd love to work with a client like you, who is interested in learning how best to work with me.
My advice is to work on fleshing out what it will do, what the rules you want to follow, and what you want it to look like.
One thing I really like as a programmer is a really good graphic mockup. You'd be surprised how many hidden expectations those things bring to light. Most GUI layouts I've seen were done in Illustrator or Photoshop. Visio is less common for me, but I am not a Windows person.
Some things you mentioned you might want to specify, such as the language or the database used for the program, are probably not something you should be choosing. Pick someone you can work with, and let them choose the best tools (the best ones they know anyway) for the job. Few things are more annoying than having all your choices dictated by someone who doesn't really understand what he is asking for.
Oracle, for example. Unless you have a clear, pressing, urgent need, steer well clear! You will inflate your end price by many many thousands of dollars, and your app probably wont be any faster or more secure.
Back onto the positive ideas, another really important tip is to ask the developer to tell you what parts of what you've asked for are the expensive/time-consuming parts, and on the other hand what are the easy parts. There is a shocking lack of correlation between what a client thinks should be hard and what is actually difficult. Some little throwaway feature you just think would be "nice to have", might cost you a week of development. On the other hand, some things you were reluctant to ask for might be easy as pie.
One last tip, if you allow people to use "trendy" languages or frameworks to build it, you may get a more eager developer. That's a good thing, since it might then be underbid, or else just given high priority since it is more fun.
For example, in my case, I'd bid a Python/Django app at 30% less per hour than a comparable Java app. I dislike working with Java and so I charge more for it.
posted by Invoke at 4:34 PM on August 1, 2006
My advice is to work on fleshing out what it will do, what the rules you want to follow, and what you want it to look like.
One thing I really like as a programmer is a really good graphic mockup. You'd be surprised how many hidden expectations those things bring to light. Most GUI layouts I've seen were done in Illustrator or Photoshop. Visio is less common for me, but I am not a Windows person.
Some things you mentioned you might want to specify, such as the language or the database used for the program, are probably not something you should be choosing. Pick someone you can work with, and let them choose the best tools (the best ones they know anyway) for the job. Few things are more annoying than having all your choices dictated by someone who doesn't really understand what he is asking for.
Oracle, for example. Unless you have a clear, pressing, urgent need, steer well clear! You will inflate your end price by many many thousands of dollars, and your app probably wont be any faster or more secure.
Back onto the positive ideas, another really important tip is to ask the developer to tell you what parts of what you've asked for are the expensive/time-consuming parts, and on the other hand what are the easy parts. There is a shocking lack of correlation between what a client thinks should be hard and what is actually difficult. Some little throwaway feature you just think would be "nice to have", might cost you a week of development. On the other hand, some things you were reluctant to ask for might be easy as pie.
One last tip, if you allow people to use "trendy" languages or frameworks to build it, you may get a more eager developer. That's a good thing, since it might then be underbid, or else just given high priority since it is more fun.
For example, in my case, I'd bid a Python/Django app at 30% less per hour than a comparable Java app. I dislike working with Java and so I charge more for it.
posted by Invoke at 4:34 PM on August 1, 2006
If you are a coder --- feel free to shoot out questions you'd ask prospective clients
Who will be using the application?
How much experience does this person or persons have with:
-the business where this application will be used;
-the computer it will be used on;
-similar applications that already exist.
Will this application ever need to handle more than one user at a time?
Does this application need to perform updates in real time?
Does this application need to work online?
Will this application ever need to be ported to another platform?
Does this application generate data? If so, how must it be stored? For how long? Must it be manipulated and/or formatted in some way?
What kind of failsafes, redundancies, security and/or uptime does this application need to have?
These are just a few thoughts of the top of my head.
For more ideas, you might google for terms like "request for proposal" or "proposal format" or somesuch. I have this link saved. It's actually advice on writing a RFP for creating a web site, but it should give you some ideas.
posted by SuperSquirrel at 4:35 PM on August 1, 2006
Who will be using the application?
How much experience does this person or persons have with:
-the business where this application will be used;
-the computer it will be used on;
-similar applications that already exist.
Will this application ever need to handle more than one user at a time?
Does this application need to perform updates in real time?
Does this application need to work online?
Will this application ever need to be ported to another platform?
Does this application generate data? If so, how must it be stored? For how long? Must it be manipulated and/or formatted in some way?
What kind of failsafes, redundancies, security and/or uptime does this application need to have?
These are just a few thoughts of the top of my head.
For more ideas, you might google for terms like "request for proposal" or "proposal format" or somesuch. I have this link saved. It's actually advice on writing a RFP for creating a web site, but it should give you some ideas.
posted by SuperSquirrel at 4:35 PM on August 1, 2006
Orthongonality has it (partly) right - be careful though, because some developers love developing/designing for "edge cases" (the .02% of the use cases that might, someday, somehow, cause problems). A good application designs for the other 98% of "normal" business.
Architecture decisions are generally mutually agreed-upon; you should know what the best practices are in the industry/area that you are designing for; in other words, don't design for Oracle/unix when your competition is Java/web-enabled, with a SQL back-end.
Something else to consider is that both Usablity and Testing should be consulted/used from the very beginning. Usability specialists (and this includes many Tech Writers, they are often passionate user advocates) can point out a clunky/unusable interface quickly, and can suggest small tweaks that are technically feasible that can vastly improve the user experience. These folks are worth their pay because you, your client, and the developer will be FAR too familiar with the application to 'see' these problems.
Anyhoo, as Barbie might say "application design/development is hard!"
Good luck!
posted by dbmcd at 4:38 PM on August 1, 2006
Architecture decisions are generally mutually agreed-upon; you should know what the best practices are in the industry/area that you are designing for; in other words, don't design for Oracle/unix when your competition is Java/web-enabled, with a SQL back-end.
Something else to consider is that both Usablity and Testing should be consulted/used from the very beginning. Usability specialists (and this includes many Tech Writers, they are often passionate user advocates) can point out a clunky/unusable interface quickly, and can suggest small tweaks that are technically feasible that can vastly improve the user experience. These folks are worth their pay because you, your client, and the developer will be FAR too familiar with the application to 'see' these problems.
Anyhoo, as Barbie might say "application design/development is hard!"
Good luck!
posted by dbmcd at 4:38 PM on August 1, 2006
Response by poster: orthogonality: Aha! So that explains why everyone kept telling me I had to be specific, but not what things I had to be specific about; now I get it. Thanks for such a clear explanation -- as well as a gold mine of right-thinking prompts. And yet I cannot help thinking that it would be helpful to you for us to use, and view, the specifics so many have mentioned above as 'conversation starters'?
Maybe I should rephrase my question, then:
Okay. Dear IAAC's, IAAPM's, IAASE's and IAAWEIR*'s --
When I first come to you, to see if you and I might work together to craft an application, what would I bring that would make me a dream client? Besides the limo full of gold bullion, that is :)
Thank you.
*(I Am A Whatever Else Is Related)
posted by thewhynotgirl at 4:41 PM on August 1, 2006
Maybe I should rephrase my question, then:
Okay. Dear IAAC's, IAAPM's, IAASE's and IAAWEIR*'s --
When I first come to you, to see if you and I might work together to craft an application, what would I bring that would make me a dream client? Besides the limo full of gold bullion, that is :)
Thank you.
*(I Am A Whatever Else Is Related)
posted by thewhynotgirl at 4:41 PM on August 1, 2006
what would I bring that would make me a dream client?
An understanding there is no such thing and that what you are looking for is more art than science. The thing is, the person you hire is as much responsible for a dream project as you are. In fact, it's more like a 90/10 split. If the documentation's tight and there are no changes during the course of the project, it really doesn't matter if you're a dream or a nightmare client.
Of course, the documentation's always moth-ridden and there are always changes. Bring an open mind. That's about it.
posted by yerfatma at 5:47 PM on August 1, 2006
An understanding there is no such thing and that what you are looking for is more art than science. The thing is, the person you hire is as much responsible for a dream project as you are. In fact, it's more like a 90/10 split. If the documentation's tight and there are no changes during the course of the project, it really doesn't matter if you're a dream or a nightmare client.
Of course, the documentation's always moth-ridden and there are always changes. Bring an open mind. That's about it.
posted by yerfatma at 5:47 PM on August 1, 2006
thewhynotgirl writes "When I first come to you, to see if you and I might work together to craft an application, what would I bring that would make me a dream client? B"
Clear expectations, and an idea of the difference between business rules, constraints, and implementation decisions.
A business rule has nothing to do with the programming per se, but is essential to how you do business. Example: invoices are always sent out two weeks prior to the invoice due date. (Expected refinement of requirement: two business weeks, or two whole weeks? Necessary corner case question: what is the policy for holidays? Necessary follow-up question: what days does your business consider holidays? Good developer's follow-up: is your business, or do you expect in to become, international? What days will you consider holidays in other countries? Really good developer follow-up: how will you handle inter-country invoices, when each country has different holidays?)
(dbmcd rightly warns it's possible to get bogged down in minutia; the really good follow-up assumes a large enough volume of inter-country invoices to make considering the question worth the cost of considering it.)
A constraint is usually a minimum requirement. This should be communicated to the developer (and agreed to contractually), but it's not about programming per se. Example: we need to be able to process at least 10,000 transactions a day. We expect a minimum up-time of X hours per year. Etc.
An implementation decision is something that should generally be left to the technical staff (but not necessarily to the application programmer). It's something that doesn't affect what the business rules or constraints are, but affects how the program meets those requirements (and often, how easily requirements can latter be modified). This can include anything from choice of programming languages, database platforms, algorithms, etc. While it should be left to technical staff to develop alternatives, TCO (Total Cost of Ownership) can depend on these implementation decisions, so sign-off at least on larger ones, should be gotten from the appropriate business staff.
For example, the holidays question above. There are a variety of solutions to it. One would be to never include holidays in the calculation, and compensatorily send out invoices a week earlier. Another would be to build a flexible database of holidays, so that new holidays for new countries could be added easily, possibly by non-technical staff. (And indeed, that's my default preference, and I can already "see" the database tables and views I'd use to implement it.) A very very bad way to go about it would be to hard-code holidays in the app. Worse would be to hard-code holidays into the user interface portion of the app.
So how to deal with holidays is a business decision (do we deal with holidays, if so, which ones in which countries), a constraint (we must deal with holidays) and an implementation decisions (how do we represent holidays in our app) while the question, "what balance between easy to implement and flexible to add to" is a constraint, based on business rules, which is answer by an implementation decision.
As such, it travels up and down the "chain of command" -- the client analyst says, "here's our policy". If the business doesn't have an existing policy for holidays, and the developer is smart enough to ask about holidays, the question has to travel up to the business's policy makers, be decided on, travel back to the analyst, back to the developer for question refinements, then go to the developer for an implantation decision.
If you have a clear understanding of what you want, and clear understand of both the overlap of and dissimilarities among business rules, constraints, and implementation decisions, it makes working with you a joy. (And ultimately, it's cheaper for you.)
So my advice would be, have a clear idea of what you want, war-game it, play-act it, do as much as you can do to reify it without actually programming it, and discover any hidden assumptions in the model, before bringing it to a developer. But don’t do too much of that: you can end up with a requirements doc that doesn’t reflect the actual business rules. (I’ve been given those, and oh boy!) But also note, a good developer will work with you to do exactly that. A really good developer will do his best to guide you to do what you need to do to be a good client.
posted by orthogonality at 6:15 PM on August 1, 2006
Clear expectations, and an idea of the difference between business rules, constraints, and implementation decisions.
A business rule has nothing to do with the programming per se, but is essential to how you do business. Example: invoices are always sent out two weeks prior to the invoice due date. (Expected refinement of requirement: two business weeks, or two whole weeks? Necessary corner case question: what is the policy for holidays? Necessary follow-up question: what days does your business consider holidays? Good developer's follow-up: is your business, or do you expect in to become, international? What days will you consider holidays in other countries? Really good developer follow-up: how will you handle inter-country invoices, when each country has different holidays?)
(dbmcd rightly warns it's possible to get bogged down in minutia; the really good follow-up assumes a large enough volume of inter-country invoices to make considering the question worth the cost of considering it.)
A constraint is usually a minimum requirement. This should be communicated to the developer (and agreed to contractually), but it's not about programming per se. Example: we need to be able to process at least 10,000 transactions a day. We expect a minimum up-time of X hours per year. Etc.
An implementation decision is something that should generally be left to the technical staff (but not necessarily to the application programmer). It's something that doesn't affect what the business rules or constraints are, but affects how the program meets those requirements (and often, how easily requirements can latter be modified). This can include anything from choice of programming languages, database platforms, algorithms, etc. While it should be left to technical staff to develop alternatives, TCO (Total Cost of Ownership) can depend on these implementation decisions, so sign-off at least on larger ones, should be gotten from the appropriate business staff.
For example, the holidays question above. There are a variety of solutions to it. One would be to never include holidays in the calculation, and compensatorily send out invoices a week earlier. Another would be to build a flexible database of holidays, so that new holidays for new countries could be added easily, possibly by non-technical staff. (And indeed, that's my default preference, and I can already "see" the database tables and views I'd use to implement it.) A very very bad way to go about it would be to hard-code holidays in the app. Worse would be to hard-code holidays into the user interface portion of the app.
So how to deal with holidays is a business decision (do we deal with holidays, if so, which ones in which countries), a constraint (we must deal with holidays) and an implementation decisions (how do we represent holidays in our app) while the question, "what balance between easy to implement and flexible to add to" is a constraint, based on business rules, which is answer by an implementation decision.
As such, it travels up and down the "chain of command" -- the client analyst says, "here's our policy". If the business doesn't have an existing policy for holidays, and the developer is smart enough to ask about holidays, the question has to travel up to the business's policy makers, be decided on, travel back to the analyst, back to the developer for question refinements, then go to the developer for an implantation decision.
If you have a clear understanding of what you want, and clear understand of both the overlap of and dissimilarities among business rules, constraints, and implementation decisions, it makes working with you a joy. (And ultimately, it's cheaper for you.)
So my advice would be, have a clear idea of what you want, war-game it, play-act it, do as much as you can do to reify it without actually programming it, and discover any hidden assumptions in the model, before bringing it to a developer. But don’t do too much of that: you can end up with a requirements doc that doesn’t reflect the actual business rules. (I’ve been given those, and oh boy!) But also note, a good developer will work with you to do exactly that. A really good developer will do his best to guide you to do what you need to do to be a good client.
posted by orthogonality at 6:15 PM on August 1, 2006
One other thing that is vital to making a business application development process actually work is to have your subject matter experts provide a vocabulary and perhaps even a taxonomy of critical terms at the outset. Example: There is no such cost as a "true" cost, according to FASB. There are:
These are things that make professional coders the small minded, suspicious, anal retentive, gloomy people you see before you in project kickoff meetings. Your business people and subject matter experts need to be able to do the math, literally, at an example level, for each process they want coded, and provide that example, and a limited range of test data that support their case example, as part of the functional specification.
From the outset, you need to give thought to acceptance and implementation, and have clear, low level test and acceptance criteria. "Fit for the business purpose describe in functional spec document A" is not an acceptance criteria. "Able to complete without error and within linear processing time, a cost rollup complete with variance posting to general ledger for all cost types and cost type changes on the test data set of inventory item numbers." might be.
posted by paulsc at 7:10 PM on August 1, 2006
- Average costs
- Standard costs
- Unit costs
- and probably 50 other obscure cost systems
These are things that make professional coders the small minded, suspicious, anal retentive, gloomy people you see before you in project kickoff meetings. Your business people and subject matter experts need to be able to do the math, literally, at an example level, for each process they want coded, and provide that example, and a limited range of test data that support their case example, as part of the functional specification.
From the outset, you need to give thought to acceptance and implementation, and have clear, low level test and acceptance criteria. "Fit for the business purpose describe in functional spec document A" is not an acceptance criteria. "Able to complete without error and within linear processing time, a cost rollup complete with variance posting to general ledger for all cost types and cost type changes on the test data set of inventory item numbers." might be.
posted by paulsc at 7:10 PM on August 1, 2006
I'm a little confused - do you want these applications for your personal use, or do you think they're a good business proposition and think that by releasing them you can make money?
Respect your programmer's expertise. It's important that you find people whose judgement about technical issues you trust. And once you trust them, feel free to ask about their decisions, but don't insist on a particular technology. I'm working with a client now that's doing that, and it's incredibly aggravating because it looks like they're going to insist that I WAY overcomplicate a system for the sake of internal politics and I'm pretty tempted to walk away because it's just not worth the trouble.
Also, I think it will be a smoother process if you're flexible about the whole design. There are things that experts in the software industry know about designing software that you probably won't have thought about. If you're prepared for your vision for the application to change throughout the process, it will work out better. Hopefully you'll be able to find people that respect your design intent without talking down to you about "how real applications are designed" or whatever, but that are also experienced enough to give you thoughtful feedback about what you want to do.
Also, I wouldn't spend so much time with requirements documents. What you want is going to change as soon as you start seeing prototypes - and rightly so, design is a fundamentally iterative process, and it would be foolish to expect that you can accurately spec out a product before building a prototype. I'd recommend finding a shop that's comfortable with iterative processes and trust them to talk you through it, build incremental prototypes, test out the experience with you, and evolve the product. I know it might feel like you know exactly what you want, but from experience, I can tell you the odds are pretty small that what finally comes out will be the same as what's in your head now. I also find that something feels designed and fleshed out in my head, but when I go to draw it or code it I discover all kinds of issues I never thought about. Don't get discouraged! I think this is normal, and is probably why requirements documents are so popular - they make you realize this before you go talk to people. The problem with them is that you then feel like you should keep them updated well after they've served their procedural role of getting you to think about details.
Good luck!
I'm also really curious about what kinds of apps you're looking for. Maybe a one sentence description of what you're thinking about? It might help scope this discussion.
posted by heresiarch at 9:16 PM on August 1, 2006 [1 favorite]
Respect your programmer's expertise. It's important that you find people whose judgement about technical issues you trust. And once you trust them, feel free to ask about their decisions, but don't insist on a particular technology. I'm working with a client now that's doing that, and it's incredibly aggravating because it looks like they're going to insist that I WAY overcomplicate a system for the sake of internal politics and I'm pretty tempted to walk away because it's just not worth the trouble.
Also, I think it will be a smoother process if you're flexible about the whole design. There are things that experts in the software industry know about designing software that you probably won't have thought about. If you're prepared for your vision for the application to change throughout the process, it will work out better. Hopefully you'll be able to find people that respect your design intent without talking down to you about "how real applications are designed" or whatever, but that are also experienced enough to give you thoughtful feedback about what you want to do.
Also, I wouldn't spend so much time with requirements documents. What you want is going to change as soon as you start seeing prototypes - and rightly so, design is a fundamentally iterative process, and it would be foolish to expect that you can accurately spec out a product before building a prototype. I'd recommend finding a shop that's comfortable with iterative processes and trust them to talk you through it, build incremental prototypes, test out the experience with you, and evolve the product. I know it might feel like you know exactly what you want, but from experience, I can tell you the odds are pretty small that what finally comes out will be the same as what's in your head now. I also find that something feels designed and fleshed out in my head, but when I go to draw it or code it I discover all kinds of issues I never thought about. Don't get discouraged! I think this is normal, and is probably why requirements documents are so popular - they make you realize this before you go talk to people. The problem with them is that you then feel like you should keep them updated well after they've served their procedural role of getting you to think about details.
Good luck!
I'm also really curious about what kinds of apps you're looking for. Maybe a one sentence description of what you're thinking about? It might help scope this discussion.
posted by heresiarch at 9:16 PM on August 1, 2006 [1 favorite]
I worked as a contract programmer for many years, and I don't have anything fundamentally new to add, mostly I echo what orthogonality et al. have mentioned.
One of the most important skills of a contract coder, about as important as the ability to write code, is the ability to extract a workable specification and design from the client. The client never knows up-front exactly what they want; it's always necessary to talk with them and separate out the threads of requirements, specifications, crackpot ideas, genius insights into the product, possible-but-impractical features, and so on, and then to boil it all down to something that can be implemented. What makes a dream client is, basically, the willingness and ability to engage in that dialogue. Oh, and loads of cash.
In addition to the other things, I would say to go ahead with the mockups and walkthroughs you've described. It's OK if they're in Visio, MacPaint, or in pencil-and-paper. (Avoid cocktail napkins, though: the ink bleeds too much, and they fall apart too quickly from handling.) These initial sketches may or may not actually be translated into the final product, but they will give the developer insight into what you're trying to do, and why. But bring any requirements-level documentation you can, as well. And remember that all of that is just a starting point.
All this assumes that you find a good developer, of course: one who will spend time up-front making sure that you're asking for something which you can use, and which can be implemented with an amount of effort that you can afford. A bad developer will happily take your UI mockups and implement them without questions, and you'll only find out after deployment that they don't actually do what you want. (Meanwhile, the developer was thinking, "Man, why did they arrange the UI like this? It'll be impossible for the user to do XYZ... oh well, it's what the client asked for!")
(As dbmcd points out, bad developers also come in another flavor: people who get bogged down in irrelevant detail and planning perfect responses for unlikely events. I'm personally of the school of thought that, at the design stage, the corner cases are the important things to examine, and that once you get those right, the large structures will fall naturally into place. But you still need to know when to declare some problems out-of-scope or sweep them under the rug. I think that just comes from experience.)
posted by hattifattener at 1:17 AM on August 2, 2006
One of the most important skills of a contract coder, about as important as the ability to write code, is the ability to extract a workable specification and design from the client. The client never knows up-front exactly what they want; it's always necessary to talk with them and separate out the threads of requirements, specifications, crackpot ideas, genius insights into the product, possible-but-impractical features, and so on, and then to boil it all down to something that can be implemented. What makes a dream client is, basically, the willingness and ability to engage in that dialogue. Oh, and loads of cash.
In addition to the other things, I would say to go ahead with the mockups and walkthroughs you've described. It's OK if they're in Visio, MacPaint, or in pencil-and-paper. (Avoid cocktail napkins, though: the ink bleeds too much, and they fall apart too quickly from handling.) These initial sketches may or may not actually be translated into the final product, but they will give the developer insight into what you're trying to do, and why. But bring any requirements-level documentation you can, as well. And remember that all of that is just a starting point.
All this assumes that you find a good developer, of course: one who will spend time up-front making sure that you're asking for something which you can use, and which can be implemented with an amount of effort that you can afford. A bad developer will happily take your UI mockups and implement them without questions, and you'll only find out after deployment that they don't actually do what you want. (Meanwhile, the developer was thinking, "Man, why did they arrange the UI like this? It'll be impossible for the user to do XYZ... oh well, it's what the client asked for!")
(As dbmcd points out, bad developers also come in another flavor: people who get bogged down in irrelevant detail and planning perfect responses for unlikely events. I'm personally of the school of thought that, at the design stage, the corner cases are the important things to examine, and that once you get those right, the large structures will fall naturally into place. But you still need to know when to declare some problems out-of-scope or sweep them under the rug. I think that just comes from experience.)
posted by hattifattener at 1:17 AM on August 2, 2006
(Avoid cocktail napkins, though: the ink bleeds too much, and they fall apart too quickly from handling.)
The backs of used paper plates should be avoided too, as they tend to get stinky while sitting with the other piles of paper all over the programmer's desk. I mean, just sayin'...
A bad developer will happily take your UI mockups and implement them without questions, and you'll only find out after deployment that they don't actually do what you want.
Just as a bad client who has a 'vision' of how they want their application to work will INSIST that the UI work a certain way. Willingness to engage in the dialogue and allow the programmer to have some input is very important. Don't forget that you're not just paying the coder for their ability to translate ideas into machine-readable form; you're also paying them for their experience and knowledge of what works and what doesn't work. Some coders have no (or worse, bad) ideas in this realm -- but many of the ones that are *good* will help you massage your ideas into a format that requires less manual user input and is more intuitive, both of which will help make your applications more effective.
Try to figure out if your programmer is a kinesthetic, visual, or auditory learner. I'm kinesthetic/visual, and I *always* generate process flow graphics in Visio or OmniGraffle before I get started with something. Spending that couple of hours diagramming or outlining has literally saved me years of programming time, because it helped me find areas where neither the client or I had an understanding of what actually happened inside of the black box that was specced. You need to completely remove the whole 'WGIMHWGO" aspect of project parts. WGIMWGO is an auto mechanic's slang word - Wire Goes In, Magic Happens, Wire Goes Out.
One thing that is CONSTANTLY going to frustrate you with contract coders is their lack of time management skills, and them feeling they need to kiss your ass and agree to your deadlines even though they're not feasible. I've worked with twenty or so coders on various projects in languages I didn't know well, and only one of them produced code that worked very well in a timely manner. Make sure that you're using some sort of project management tool that gets updated on a daily (or more frequent) basis so that you can track their progress. If you don't track their progress, you'll never see things get done, because they have other contracts breathing down their neck. If you sit on them too hard, they rush and you get shite code out of them. A balance is required, but my best advice is to work with them in something like Basecamp where you can help them break the project down into little itty bitty tiny teensy bits and be able to check each one off.
* I am also a contract coder; PHP, Javascript and Python are my tools of choice.
posted by SpecialK at 7:29 AM on August 2, 2006
The backs of used paper plates should be avoided too, as they tend to get stinky while sitting with the other piles of paper all over the programmer's desk. I mean, just sayin'...
A bad developer will happily take your UI mockups and implement them without questions, and you'll only find out after deployment that they don't actually do what you want.
Just as a bad client who has a 'vision' of how they want their application to work will INSIST that the UI work a certain way. Willingness to engage in the dialogue and allow the programmer to have some input is very important. Don't forget that you're not just paying the coder for their ability to translate ideas into machine-readable form; you're also paying them for their experience and knowledge of what works and what doesn't work. Some coders have no (or worse, bad) ideas in this realm -- but many of the ones that are *good* will help you massage your ideas into a format that requires less manual user input and is more intuitive, both of which will help make your applications more effective.
Try to figure out if your programmer is a kinesthetic, visual, or auditory learner. I'm kinesthetic/visual, and I *always* generate process flow graphics in Visio or OmniGraffle before I get started with something. Spending that couple of hours diagramming or outlining has literally saved me years of programming time, because it helped me find areas where neither the client or I had an understanding of what actually happened inside of the black box that was specced. You need to completely remove the whole 'WGIMHWGO" aspect of project parts. WGIMWGO is an auto mechanic's slang word - Wire Goes In, Magic Happens, Wire Goes Out.
One thing that is CONSTANTLY going to frustrate you with contract coders is their lack of time management skills, and them feeling they need to kiss your ass and agree to your deadlines even though they're not feasible. I've worked with twenty or so coders on various projects in languages I didn't know well, and only one of them produced code that worked very well in a timely manner. Make sure that you're using some sort of project management tool that gets updated on a daily (or more frequent) basis so that you can track their progress. If you don't track their progress, you'll never see things get done, because they have other contracts breathing down their neck. If you sit on them too hard, they rush and you get shite code out of them. A balance is required, but my best advice is to work with them in something like Basecamp where you can help them break the project down into little itty bitty tiny teensy bits and be able to check each one off.
* I am also a contract coder; PHP, Javascript and Python are my tools of choice.
posted by SpecialK at 7:29 AM on August 2, 2006
I haven't seen anyone here, so far, clearly delineate the differences between a systems analyst, a designer/architect, and a coder.
The first two are often combined, particularly on smaller projects, but combining the first two with the third can be dangerous -- there are *lots* of really great programmers out there who can't design their way out of a paper bag.
The job of that first guy, the analyst, is to ask all those questions you want on a piece of paper, whynot; the problem is, as people have pointed out, that the questions nest: the things you ask later depend a lot on the answers you get to earlier questions.
And their experience. A lot of the silly questions I ask someone when starting in on the design of their software are based on stupid things I've seen happen on earlier projects.
There may be some expert-system work going on in the systems analysis field -- I don't follow it formally -- but I don't think you can reasonably boil it down to one questionnaire.
Thank ghod; it's one of the few things I'm any good at. :-)
posted by baylink at 4:07 PM on August 2, 2006
The first two are often combined, particularly on smaller projects, but combining the first two with the third can be dangerous -- there are *lots* of really great programmers out there who can't design their way out of a paper bag.
The job of that first guy, the analyst, is to ask all those questions you want on a piece of paper, whynot; the problem is, as people have pointed out, that the questions nest: the things you ask later depend a lot on the answers you get to earlier questions.
And their experience. A lot of the silly questions I ask someone when starting in on the design of their software are based on stupid things I've seen happen on earlier projects.
There may be some expert-system work going on in the systems analysis field -- I don't follow it formally -- but I don't think you can reasonably boil it down to one questionnaire.
Thank ghod; it's one of the few things I'm any good at. :-)
posted by baylink at 4:07 PM on August 2, 2006
baylink: This is going off topic, but I take issue with your statement that combining "the first two with the third can be dangerous".
On the contrary, having an architect or analyst who DOESN'T code is far more dangerous, as they are only dealing in abstractions and "the happy path" and aren't grounded in the day to day realities of the project. All architects should code to some degree, or at least have an experienced coding background and be able to drop into "heads down" mode if needed. Coding leads to changes in design, into new insights into the system and often into better ways of doing things, which is why coding IS design and design and coding should be done together, incrementally.
For more on that whole debate, I highly recommend any of the books on agile or XP, or the essays of Jack Reeves, particularly What is Software Design?.
posted by rsanheim at 8:53 PM on August 2, 2006
On the contrary, having an architect or analyst who DOESN'T code is far more dangerous, as they are only dealing in abstractions and "the happy path" and aren't grounded in the day to day realities of the project. All architects should code to some degree, or at least have an experienced coding background and be able to drop into "heads down" mode if needed. Coding leads to changes in design, into new insights into the system and often into better ways of doing things, which is why coding IS design and design and coding should be done together, incrementally.
For more on that whole debate, I highly recommend any of the books on agile or XP, or the essays of Jack Reeves, particularly What is Software Design?.
posted by rsanheim at 8:53 PM on August 2, 2006
I think I'll take a stab at the original question. (aside: Mefi - where are all the agile developers?) (I am a programmer/software engineer/whatever, I've done full-time and contract work in java, php, javascript, ruby, etc...)
First off all, what you, pinupgirl, should provide your contractor: your ideas about how you envision your application, and who the primary user(s) are. If you can bring the end user to the programmer for direct meetings, all the better. Like some have stated already, a good developer will talk to you, and try to separate what you really need from what you really want. A good developer should have a working prototype (a very limited version of the system) of your app within the first week, if not by the end of the first or second day.
Provide the contractor:
* sketches and ideas
* notes and high level documents describing the app (don't sweat the details!)
* a clear explanation of the problem the app should solve
* examples of apps that you've used and would like to emulate
* the smallest, most basic system you could imagine providing to the user to get feedback
Don't worry about
* overly detailed outlines or specs - all this will change anyways
* mocked-up screens
* architecture documents
* "scope creep"
Your programmer should tell you, honestly and up front:
* what their rate will be, either hourly or per iteration (iterations should be small, may a week or 2)
* how often they will meet with you (it should be often!)
* their prior experience doing apps in the same domain
* their honest opinions on what you are asking for, particularly if you are asking for things that might be overkill or just add complexity w/o benefit
A good agile developer will not give you a fixed, contractual price - he'll agree to work on the system until you're reasonably happy with. Obviously, there may be upper limits or practical limits, but until he/she is actually in the code for awhile, they won't really have an accurate estimate. The reason for this is that software gets very complex, very fast - and what used to be called "scope creep" is really just _change_. Change happens, and its to you and your application's advantage if you can roll with it and incorporate change as quickly as possible.
A fundamental fact about software is that once you actually start coding it, you realize your initial ideas and designs were way off, and maybe even the problem you thought you were solving isn't the main problem at all. Thats why its crucial to get working code as soon as possible, and to get the feedback cycle turned around very rapidly. The good news is that this is very possible now with languages and frameworks like Ruby, Python, Rails, and Django.
On more practical concerns: competitive rates vary widely by location and by talent. Someone local can meet with you more often, face to face, which can be a big plus. Look for people who are skilled in open source and agile development, and have fun!
(also recommended reading for customers and clients alike: the Agile Manifesto)
posted by rsanheim at 9:17 PM on August 2, 2006
First off all, what you, pinupgirl, should provide your contractor: your ideas about how you envision your application, and who the primary user(s) are. If you can bring the end user to the programmer for direct meetings, all the better. Like some have stated already, a good developer will talk to you, and try to separate what you really need from what you really want. A good developer should have a working prototype (a very limited version of the system) of your app within the first week, if not by the end of the first or second day.
Provide the contractor:
* sketches and ideas
* notes and high level documents describing the app (don't sweat the details!)
* a clear explanation of the problem the app should solve
* examples of apps that you've used and would like to emulate
* the smallest, most basic system you could imagine providing to the user to get feedback
Don't worry about
* overly detailed outlines or specs - all this will change anyways
* mocked-up screens
* architecture documents
* "scope creep"
Your programmer should tell you, honestly and up front:
* what their rate will be, either hourly or per iteration (iterations should be small, may a week or 2)
* how often they will meet with you (it should be often!)
* their prior experience doing apps in the same domain
* their honest opinions on what you are asking for, particularly if you are asking for things that might be overkill or just add complexity w/o benefit
A good agile developer will not give you a fixed, contractual price - he'll agree to work on the system until you're reasonably happy with. Obviously, there may be upper limits or practical limits, but until he/she is actually in the code for awhile, they won't really have an accurate estimate. The reason for this is that software gets very complex, very fast - and what used to be called "scope creep" is really just _change_. Change happens, and its to you and your application's advantage if you can roll with it and incorporate change as quickly as possible.
A fundamental fact about software is that once you actually start coding it, you realize your initial ideas and designs were way off, and maybe even the problem you thought you were solving isn't the main problem at all. Thats why its crucial to get working code as soon as possible, and to get the feedback cycle turned around very rapidly. The good news is that this is very possible now with languages and frameworks like Ruby, Python, Rails, and Django.
On more practical concerns: competitive rates vary widely by location and by talent. Someone local can meet with you more often, face to face, which can be a big plus. Look for people who are skilled in open source and agile development, and have fun!
(also recommended reading for customers and clients alike: the Agile Manifesto)
posted by rsanheim at 9:17 PM on August 2, 2006
Response by poster: Thank you for all the additional responses -- I have not had time to return. You have no idea how helpful this has all been (already)! I will be back at (hopefully) 4-5 pm CST today with app details and feedback to your comments.
posted by thewhynotgirl at 7:50 AM on August 3, 2006
posted by thewhynotgirl at 7:50 AM on August 3, 2006
This thread is closed to new comments.
Also (and you probably know this) custom coding is a very expensive proposition.
posted by adamrice at 2:50 PM on August 1, 2006