-1

I will start to work on a software application for two people that haven't had any programming experience at all or knowledge of computer science concepts whatsoever. The project will require building a full-stack app for a business of theirs.

We've already had a few conversations and dozens of mails exchanged. The calls are unbelievably long (which is fine since I'll get paid for the project), but I noticed that most of their communication consists of incoherent computer words and sentences that do not really mean anything. I feel like they've picked a few words here and there, and just drop them in order to sound competent (which clearly sounds very funny, if not silly).

In every mail I try to be as specific as I can, literally breaking down the programming process in the simplest way possible. However, I keep getting suggestions and tech buzzwords dropped all over the place from their side which is really frustrating.

Can someone recommend a good strategy for dealing with laymen customers that try to get involved in the software process? I will get paid for the project - not much, but still it's something. However, I would like to know a good strategy to draw the line between who is the developer and who is the customer without offending or pushing them back.

1

Your customers are good at running their business (or at least I hope so). You are good at writing software (or at least I hope so :-) So you shouldn't tell them how to run their business, and they shouldn't tell you how to design and write the software. You know better than they do how to design software, user interfaces, and so on.

For non-developers, the design phase is very difficult. So instead of leaving the design to them, you first should get at a very high level an overview what this software is supposed to do for them. You take that in, then you create a high level design of the software's functions. You return that, then they can see where your high level design doesn't match their needs, and you fix it. You end up with a high level design that the business people could never have created on their own.

Then you take each component and create a more refined design, and go through the same steps. And that should get you to the point where you know what the software you are going to write needs to achieve. At this point we have not talked about anything computerish. What you have now could be turned into an instruction manual for a new employee.

At this point you can design what data you need, how it is connected and so on. And then you can start designing user interfaces, which they can check. Now we know that you can create a user interface with the tools your system provides, or we can do it the hard way by tweaking everything. And we know that you can do anything, but it costs time and money. So the checking should be about things that are missing ("we need a shipping address for each customer") not the design ("This shouldn't be a standard button but a fancy button that I designed myself and that animates a little truck to indicate the shipping process"). I'm sure you can animate that little truck, but it costs time and money and you don't do that before all functionality is there.

You need to keep the whole process under control, because you know how to do this. Any wishes that delay the product, you agree that you will refuse them because you have the control how the project is run.

If they absolutely want fancy design changes, then you can hire a junior developer who does these things but doesn't get close to the core of the project. So you don't get delayed.

One thing: No screen designs at the start. At most they get a notebook with pages of handdrawn designs so there is no room for complaints that the software doesn't match the screen designs that were pulled from thin air in the first place.

  • Very good answers and strategies, thank you all! I think this one gets as closest as possible to the real dev-client communication. – birdybird03 Feb 24 '18 at 18:54
4

Are they asking you to execute on their terms and buzzwords? Do they want you to blockchain them some machine learning integrated API recursive full stack frameworks? Or does it seem like they want to use the terms to sound smart but ultimately they will leave the technical decisions to you?

Maybe don't worry too much about their use of words they don't understand, so long as they aren't expecting you to use what they are suggesting.

Make sure you have a contract that states you as the dev are the one who makes technical choices. They may eventually see the light and realize their mistakes. Or maybe not. Whatever you do make sure to protect yourself and your time with a contract.

You can always appeal to their wallet as well. Bleeding edge tech is cool to talk about but expensive to implement. Are they willing to fork out extra bucks for bragging rights about their application? If not, maybe mention they could always implement their social media event driven neural networks with dynamic backtracking cloud crypto currency algorithms at a later date.

CS concepts are hard and educating them may be a big time sink with little actual benefit. Just make sure if you deliver working code that does what they want and meets the project specs you get paid for it. They can have ideas and use buzzwords galore. Just make sure it doesn't affect your bank account.

3

Don't talk about the software process.

It is frustrating to me when customers think they can design better than I can. They will skip functional requirements and go straight to functional design. You get some users that are just not capable of a functional requirement - it is too abstract for them.

Try to get them to talk about the requirements.

  • Start with a simple scope. Just a couple paragraphs.
  • Outline the requirements. If they start to get crazy pull out the scope document.
  • Data design. They don't need know 3NF. What is the data and what are the relationships.
  • Detailed design. This is where you start to lead out more.

They are frustrated as they want to see screens up front. In my experience that never goes well. But if that is all they can understand and are paying by the hour then OK.

I don't want to piss UX people off but they can come up with designs that are difficult to code and are brittle. I have written custom controls for just a tweak compared to controls that come with the framework.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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