5

I am to write a piece of software to a friend of my uncle's, but I don't exactly know all the elements that are needed to fulfil the user's needs, so I can't begin to formulate a design yet. Since the problem is kind of solvable (in a small, non practical scale) by spreadsheets, macros, forms and a database, I am doing exactly that, and in the process I am figuring out the elements that will have to somehow be present in my design.

I imagine there must be another way to do this, a formalized way to design your system based on the needs of the user without the middle step of emulating the user trying to solve their own problem via inferior means. If indeed there is such a thing, what is the name of such discipline/technique?

Thomas Owens
  • 79,623
  • 18
  • 192
  • 283
Davi
  • 161
  • 3
  • 4
    It sounds like you expect a cookie-cutter approach. There isn't one. – Robert Harvey Feb 11 '20 at 16:30
  • Yes. As a mere amateur programmer, I am not aware of how software engineering works. – Davi Feb 11 '20 at 16:35
  • 1
    There is no design method for overcoming lack of specifications or design goals. :) You can go through a story mapping exercise with the client and explore what they have in mind, or build a minimum viable product to limit the cost of building something different. – Martin K Feb 11 '20 at 20:57

5 Answers5

4

You actually aren't far off the mark. If your client cannot clearly say what he wants your best bet would be to 1. talk to him! 2. knock up a quick prototype 3. listen to what he says. Repeat until one of you has had enough,

This is actually known as Agile Software Development.

Nick Keighley
  • 754
  • 4
  • 7
  • So a back and forth of developing, presenting a result, and going back to the drawing board. I was reading about Agile since @mouviciel mentioned it in his reply. It seems great for a team, but for a lone coder, it would be better if I could figure out the best approach (or the closest thing to it) from scratch. – Davi Feb 11 '20 at 16:38
  • 2
    `This is actually known as Agile Software Development.` -- Well, more or less. What you described I would call "rapid prototyping." It is only one element of an Agile process. – Robert Harvey Feb 11 '20 at 17:13
2

Your way of doing things is formally called Prototyping.

With several iterations and discussions the formal name is Agile.

mouviciel
  • 15,473
  • 1
  • 37
  • 64
  • That seems very interesting. From what I gather, there is no reason to study agile beyond its principles for a lone developer like myself. This [article] (https://www.itworld.com/article/2714022/can-a-lone-developer-use-agile-.html) seems to disagree with me, but to take on the challenge of learning about an entire toolset when I will only be able to use a few of those tools doesn't seem worth the effort. In any case, I'm glad to know to solving this problem is valid and even has a formal name. – Davi Feb 11 '20 at 16:33
2

Matching "customer" expectations is a multi-parametric unsolvable problem with no closed-form analytical solution, for many reasons, of which one should be enough (as it makes all the difference in the world). Customers (i.e. users) usually have no idea of what they want.

Joel Spolsky practically hits this nail on its head pretty hard:

If there’s one thing every junior consultant needs to have injected into their head with a heavy duty 2500 RPM DeWalt Drill, it’s this: Customers Don’t Know What They Want. Stop Expecting Customers to Know What They Want. It’s just never going to happen. Get over it.

As Joel carries on to explain, when you go to an expert designer (of anything, e.g. an architect, but just as much a software engineer), you go to them because they know better. So you have to work your way around this first of all.

The point is that you have to try to provide some alternatives, dig somewhat deep into the customer's problem and try to "understand" their needs, feel them and try to apply the best of your knowledge to meet their needs. Customers sometimes make an important mistake, they put their expectations over their needs. They don't do that mistake on purpose, but you need to keep that in mind. The reason for that is, somewhat obviously, that expectations are primarily shaped based on past experience and can be (and usually is) very subjective, but needs are usually objective and stem from real-world problems, the pragmatic difficulty of which is almost always hard to argue against.

You have to be your customer's "ally" down the interaction road. Unfortunately, this includes, more often than not, you explaining to your customer what they need. So you have to get into your customers' "world", understand their needs and actively shape their expectations into a result that helps them achieve what they want.

Beyond this "philosophical" chatter, the only useful advice you can get is that you have to spend quality time with your client. Ask, ask, and ask again. Gather all the details, prepare a few reasonably chosen alternatives, demonstrate the pros and cons of each and communicate them clearly to your client.

Vector Zita
  • 2,372
  • 8
  • 19
  • That seems ideal, but I don't think all the customers understand that, and it is my fault for lacking the experience: I should have explained it. This one for example, told me the problem and is waiting a solution. From the start, I was expecting that my first draft wouldn't meet his expectations 100%, and I am willing to give the project a 2nd and 3rd go, to fine tune the details. From what you said, it will probably take much more than just that, and I better start checking with him, the sooner the better (even if neither of us had anticipated a need for that). I'll do better next time. – Davi Feb 11 '20 at 17:35
  • 1
    Don't worry, experience builds with time. The strong points here are to involve your customer at some points along the way and have some alternatives at hand. It will not take much more because you have to be clear that the intended purpose of the solution is to primarily **solve** the problem at hand, rather than look beautiful. This should usually be the primary focus and if you feel that the interaction starts travelling in other directions (e.g. becomes too _stylistic_), make sure to remind this to your customer. – Vector Zita Feb 11 '20 at 17:40
  • 1
    @Davi, many customers *think* they know what they want, until they get it in their hands and go "but that is not what I wanted". Agile methods address this by early on giving the customer something that does a little bit of what they asked for (well enough to not have serious quality issues), to let them discover what they really want by playing around with it. – Bart van Ingen Schenau Feb 12 '20 at 11:31
  • 1
    Despite the "cliché" of it, you really need to put yourself into your customer's shoes and think about it for a while. Soon enough, it becomes clear. You would not know what exactly you want either. Part of becoming a good programmer is to learn to be more precise with respect to "what you want"! Because your customers are rarely programmers, you can expect that they will have not trained specifically for that... – Vector Zita Feb 12 '20 at 17:04
1

I believe you are looking for the term Requirements engineering. Do not confuse with a phase of the joke※ software methodology known as waterfall (1956).

Iterative and incremental development is just the Deming Cycle (1959) with some software specific considerations. See also Continual improvement process (1951). It is the way software engineering should have taken, as more mature engineering diciplines did.

And yes, Agile says you should do that (principles 1 through 3 of the Agile manifesto). And I agree that following the Agile principles is a good idea for your project. Do not confuse with Scrum (1986).

※: If you read the waterfall paper, it is all about how it goes wrong.

Theraot
  • 8,921
  • 2
  • 25
  • 35
  • From what little I learned today, this _interactive and incremental development_ seems to be a nice combination of Agile and the Waterfall Model (explained in the article about Requirements Engineering). Even though it is also better fit for a team (one of its principles is that the teams should be working on different phases of the iteration), a lone coder would benefit greatly from a good first pass through phase 1: **Inception.** I think some introductory classes on Requirements Engineering could be good for me. I'll see if I can find some well reviewed online course on that. Thank you. – Davi Feb 11 '20 at 18:31
  • 1
    @Davi you can rotate, like the Deming cycle. As you have seen, you should not try to get all the requirements up front. You just need enough to design, implement and test (not necessarily in that order, see [TDD](https://en.wikipedia.org/wiki/Test-driven_development)) a prototype. Then you do another iteration, where you increment on what you have. Please note I'm not suggesting to follow [RUP](https://en.wikipedia.org/wiki/Rational_Unified_Process) either. – Theraot Feb 11 '20 at 19:11
  • 2
    Ironically, the waterfall paper is a critique of the linear waterfall project management: it advocated already in 1970 the need to iterate (see fig 3 and 4 page 330), and prefigured incremental development (see chapter "do it twice", and fig.7 p.334 where a prototype is build ant the early experience is used to improve the final development). It was relatively advanced on its time considering the taylorism that still reigned in the majority of factories and programming projects. So I advise you to read the paper before criticizing it... – Christophe Feb 11 '20 at 19:36
  • 1
    @Christophe: Yeah. Every time I've ever seen the word "waterfall" mentioned in a discussion like this, it was a complete strawman used to make everyone who doesn't agree with agile dogmas look stupid. I've yet to see historical evidence of "waterfall" being used in industrial software development. – Christian Hackl Feb 12 '20 at 11:03
  • I assure you Waterfall *was* used in industrial software development! – Nick Keighley Feb 13 '20 at 14:46
1

You have found the nicest way to do it: discuss with the customer, build something, discuss and change it until the solution is clear. Basically, whenever the problem can be solved solo, do it like you did.

When challenges get more complex and more people need to get involved, an agile variant is to discuss with the customer, write down some user stories, let the team perform a sprint for a first version, present it to the customer, take note of more user stories, and go on for the next sprint, until the product is finished.

When it gets really complicated, then you'd better go for user story mapping or use-case 2.0: you discuss in a workshop to get the big picture, and then cut in it into a couple of initial user-stories or use-case-slices and add new ones on the flow whenever needed. Stories or slices are processed in sprints as above; you simply need more sprints to do the work. Note that each iteration delivers, presents, discusses (early feed-back from user is the key, just as when you discuss with your uncle).

Sometimes it is really complicated, but you need to have a good product concept before you start. For example if you want venture capital to finance the team that you'll recruit. In this case, you could start with a design sprint. Read Jeff Knapp's book: you can apply it whether you want to build software, robots, AirBnB (spoiler alert on the book). Note that design sprints are about product design (main features, look & feel,...): once you have hired a team, just go back to one of the approach above.

Now, to complete de picture: If you are working for a huge organization, or if your software is only a small part of a much larger endeavour, you might have to start, drafting a software requirement specification and follow the V-model to design the system, the components, and all the corresponding tests. This works well in some very demanding domains like sending some satellite in the outer space or robot on mars. But in many other domains, this more traditional approach bears some risks. Requirements might take you an awful lot of time to write. Your users might approve it despite they do not grasp at all what you're meaning (or they understand something else). In the end, the delivered product might not be what the user expected, or might no longer fit the user requirements that evolved in the meantime.

Christophe
  • 74,672
  • 10
  • 115
  • 187
  • 2
    I should have joined this community a long time ago. Through just this one question I am discovering an entire world beyond coding. As a programmer, my perspective of the object of my work has been vastly expanded. This entire thread is filled of links to concepts that are entirely new to someone who had been confined between the source and the compiled binary for so long. As you can see from my original question, my prototype was born from the notion of "emulating how someone without programming skills would solve the problem". I didn't know a thing about concepts such as _user-stories._ – Davi Feb 11 '20 at 21:30
  • 1
    "*...an agile variant is to discuss with the customer, write down some user stories, let the team perform a sprint...*". No, that is a *scrum* variant. The OP is already describing an agile approach. Agile != user stories and sprints. In the context of this question, being agile means "*Customer collaboration over contract negotiation*" and "*Responding to change over following a plan*". – David Arno Feb 12 '20 at 13:18
  • 1
    @DavidArno I have written “**an** agile” and used scrum as an example. Scrum being an agile approach among other I think that it’s not wrong. I would have understood your reaction if I had written “**the** agile variant”. In the example I used user stories and in subsequent postings I widen up with other requirement gathering tools. Note that OP did not ask at all about agile, and not knowing how he reached a working solution I did not claim that he used an agile approach. Note also that prototyping is not agile because a prototype is generally thrown away. Your DV is unjustified. – Christophe Feb 12 '20 at 13:30