Spec-driven or outcome-driven development?
-
Generally speaking, would you prefer, and why?
[1] to be given a set of specifications, such as a list of things to do, like creating a database table, API, class, page/widget, etc. in order to implement a new feature that's designed to solve a problem
Example: add a many/many relation to users/companies, an API that adds/removes users from companies, and a page that does the same; also edit login such that, if they have multiple companies, they select which one afters successful login
[2] to be tasked with accomplishing an outcome
Example: users work for multiple companies, and we'd like to admins to be able to associate a user with a company (instead of having users be part of a company), and let users select the company they will use at log-in time
-
Generally, outcome driven, but if I'm unfamiliar with the context then more details are better. It also depends on being able to talk to stakeholders to run ideas past them and confirm my initial idea matches what's needed.
Going by "this is exactly what you need to do step by step" can miss edge cases, because whoever came up with the steps isn't someone who spends all day every day dealing with the code and testing their assumptions. It also has the risk of going out of the window as soon as an assumption changes, or any actual agile development is attempted. Feedback and iteration doesn't really work with a pre defined set of tasks
-
To me, this is 'how much design work do you consider to be part of your job'.
[1] would be 'the technical design has already been written'. I get the impression low-skill offshore teams often work on this level.
[2] implies there is no technical design yet, and not necessarily a full functional design either. As @Jaloopa indicated this may mean stakeholder interviews are required to iron out details.I definitely prefer to be involved in the whole chain, whether I write the functional and technical design myself or am tangentially involved. I certainly at least want to know what we're wanting a change to accomplish.
Whether the designs ever get written on paper or are only discussed verbally and/or in bug comments is orthogonal to that.
-
@PleegWat said in Spec-driven or outcome-driven development?:
To me, this is 'how much design work do you consider to be part of your job'.
Or how much your job description decrees it to be part of your job, for that matter.***
Difficult to say. Solutions designed by me so far have been terrible. They more or less of work, but then so does the entire industry, for very approximate definitions of "work" (so approximate as to include "don't work", in case I need to explain). Therefore I might prefer if a proper systems engineer with domain knowledge and relevant experience handed me well-designed specifics, which I could implement without having to resort to getting creative, and perhaps the world would be a tiny bit better place.
The keyword is "well-designed", however. So far I'm inclined to believe that systems designed by others, including industry professionals of {{years}} years, aren't all that good either. And I'm still amazed by that unfortunate discovery. People digging the most obscure and complex topics, able to talk about them at length, and somehow what they eventually produce is only a different kind of shit. What gives!?
Poorly applicable proverbial hammers to nails, "we've always been falling down this particular set of stairs", homeopathic standards, temporary APIs that have turned into legacy before the first delivery, not future-proof to even smallest changes even with all the clever interfaces, MVVM, M&Ms and MCMCXVII, but most often utterly ridiculous Complicator's Gloves.
I get twitchy if I see obvious
s and disproportionalities of effort, even though I'm often wrong on what constitutes such, and even if I get it right, my own and better solution usually escapes me.
-
I don't have a universal answer, either, but in case (1) I would definitely need to be able to give feedback to the designer and clarify/refine/fix the requirements.
-
@apapadimoulis said in Spec-driven or outcome-driven development?:
Generally speaking, would you prefer, and why?
[1], if only to avoid endless back-and-forth about how the feature should look like exactly. With the caveat that writing the spec in the first place is probably my responsibility too. Agile is overrated, waterfall just got some bad press.
You can say that's the same as [2] except with an approval stage between speccing and coding.
-
B works better the more access I have to the real authority who does acceptance testing, so I can pepper them with questions about edge cases.
A works best in scenarios where someone else senior to me interfaces with the acceptance test authority, and I need to go to them with questions that maybe get relayed.
I've been on a more than a few projects where option B was implemented as:
Here's the problem explained in two sentences. You have no access to more information than that, because the customer doesn't know what they want. Go implement your solution, then write some requirements so we can send it to the customer.
-
@PleegWat said in Spec-driven or outcome-driven development?:
full functional design
Heh. Something that you can't really do without putting working software in front of users and discovering edge cases. And then over time they'll find more and more.
-
Definitely outcome-driven for me because the design part is the fun part.
I think in general you get better results if requirements come to the development team at that level. You need someone involved with the design who also understands the technical side, so you can design something that does what the user (or at least the stakeholder, who's supposed to represent users) wants but also does it in a technically sensible way.
It does require that the developers are allowed to talk to the stakeholder so they can ask questions about edge cases and so on though. But honestly if a spec arrives as [1] it never has them covered anyway, and you just end up asking the questions of someone who doesn't know or doesn't understand the question.
-
The horriblest time was back when our only stakeholder was a PM whose response to any question would be "You know what I want, just go build it."
He also liked presenting his projects using functional designs which were word documents containing nothing but a title and a series of MS paint mockups.
-
@apapadimoulis Working by myself, I want an outcome. Working on a team, I want a specification.
I have enough experience to design something that can adapt to changes. I do not trust others to be capable of or willing to do the same.
-
@apapadimoulis said in Spec-driven or outcome-driven development?:
Generally speaking, would you prefer, and why?
Spec-driven is much easier, and outcome-driven is much more interesting.
-
Definitely the outcome-driven one. Spec-driven means that the real programming part is done by someone else. Unless I am the one that writes the spec... but I don't like "programming in word" and I don't understand people who actually like it.
-
@Kamil-Podlesak said in Spec-driven or outcome-driven development?:
Unless I am the one that writes the spec... but I don't like "programming in word" and I don't understand people who actually like it.
If I'm doing the project solo, sure. If it's a team effort, I do prefer establishing interfaces and DB layouts beforehand.
-
It kind of feels like a false dichotomy here. A good spec will explain the needed outcome, and as much of the technical details as are necessary to paint a clear picture, because sometimes that's just the best way to communicate a technical idea. (And sometimes the person writing the spec has a better idea of the big picture than the person implementing the spec, and knows that certain details have to be done specifically this way so that some other piece will work.)
Laying out all the details in the spec is stifling, of course, but that's not how most specs actually work.
-
Outcome driven all the way. After having several projects be delivered spec perfect to the customer only to have them rejected because the customer (who approved the bloody spec) didn't understand what they wanted/what they were going to get/changed their mind/etc..., I have given up on spec-driven. I am sure there are places where it can work, but I have had WAY more success with outcome driven.
-
Spec driven would be okay, I guess, provided I can say "feature is to spec, not my problem if the spec is wrong".
In the real world, I work to outcome. I got a catchphrase: "What is it you want to accomplish?" Amazing how much easier your job becomes when you know what the user wants.
-
@GOG said in Spec-driven or outcome-driven development?:
Spec driven would be okay, I guess, provided I can say "feature is to spec, not my problem if the spec is wrong".
In the real world, I work to outcome. I got a catchphrase: "What is it you want to accomplish?" Amazing how much easier your job becomes when you know what the user wants.
That relies on the user knowing what they want.
-
@Benjamin-Hall said in Spec-driven or outcome-driven development?:
@GOG said in Spec-driven or outcome-driven development?:
Spec driven would be okay, I guess, provided I can say "feature is to spec, not my problem if the spec is wrong".
In the real world, I work to outcome. I got a catchphrase: "What is it you want to accomplish?" Amazing how much easier your job becomes when you know what the user wants.
That relies on the user knowing what they want.
If they don't know, why are they asking you to build it?
-
@Benjamin-Hall They generally know. The trick is coaxing the right answer out of them. "I want the program to do this" is the wrong answer. "I want to use the program to do achieve this practical outcome" is the right one. A lot of the time it translates to "you actually want the program to do that".
-
@Mason_Wheeler said in Spec-driven or outcome-driven development?:
@Benjamin-Hall said in Spec-driven or outcome-driven development?:
@GOG said in Spec-driven or outcome-driven development?:
Spec driven would be okay, I guess, provided I can say "feature is to spec, not my problem if the spec is wrong".
In the real world, I work to outcome. I got a catchphrase: "What is it you want to accomplish?" Amazing how much easier your job becomes when you know what the user wants.
That relies on the user knowing what they want.
If they don't know, why are they asking you to build it?
Make me a website. Make it blue.
It's not just a wry joke. I've seen it in real life when I made a scheduling app for a school with a
schedule. What do we want it to do? Let us schedule things. Beyond that? 
-
@Mason_Wheeler said in Spec-driven or outcome-driven development?:
If they don't know, why are they asking you to build it?
At least in my experience, it isn't so much the customer not knowing what they want. But rather, coaxing what the customer wants out of them. They have this amorphous idea in their heads and it can be difficult to get them to articulate it. I often found that what the user wanted was magic, but giving them just a competent workflow usually proved near enough to magic to satisfy them.
-
@Dragoon The Five Whys technique works fairly well here.
-
@Mason_Wheeler said in Spec-driven or outcome-driven development?:
@Benjamin-Hall said in Spec-driven or outcome-driven development?:
@GOG said in Spec-driven or outcome-driven development?:
Spec driven would be okay, I guess, provided I can say "feature is to spec, not my problem if the spec is wrong".
In the real world, I work to outcome. I got a catchphrase: "What is it you want to accomplish?" Amazing how much easier your job becomes when you know what the user wants.
That relies on the user knowing what they want.
If they don't know, why are they asking you to build it?
Exactly because they don't know. If they knew, they wouldn't need you. That's how every other industry works - why should programming be any different?
-
Oh, there are certainly tactics to help get to what they want.
The one that I favored was a quick prototype that they could tell me the myriad of ways that I did it wrong. They could never tell you that they wanted the interface blue, but make it obnoxious orange and immediately "That orange is a bit much, how about we try [subtle shade of blue]"
-
@Gąska said in Spec-driven or outcome-driven development?:
@Mason_Wheeler said in Spec-driven or outcome-driven development?:
@Benjamin-Hall said in Spec-driven or outcome-driven development?:
@GOG said in Spec-driven or outcome-driven development?:
Spec driven would be okay, I guess, provided I can say "feature is to spec, not my problem if the spec is wrong".
In the real world, I work to outcome. I got a catchphrase: "What is it you want to accomplish?" Amazing how much easier your job becomes when you know what the user wants.
That relies on the user knowing what they want.
If they don't know, why are they asking you to build it?
Exactly because they don't know. If they knew, they wouldn't need you. That's how every other industry works - why should programming be any different?
I know exactly what sort of car I want and what kind of house I want to live in. Doesn't mean I'm going to go build either one of those myself; I have neither the skills nor the resources to do so.
-
@Mason_Wheeler said in Spec-driven or outcome-driven development?:
@Gąska said in Spec-driven or outcome-driven development?:
@Mason_Wheeler said in Spec-driven or outcome-driven development?:
@Benjamin-Hall said in Spec-driven or outcome-driven development?:
@GOG said in Spec-driven or outcome-driven development?:
Spec driven would be okay, I guess, provided I can say "feature is to spec, not my problem if the spec is wrong".
In the real world, I work to outcome. I got a catchphrase: "What is it you want to accomplish?" Amazing how much easier your job becomes when you know what the user wants.
That relies on the user knowing what they want.
If they don't know, why are they asking you to build it?
Exactly because they don't know. If they knew, they wouldn't need you. That's how every other industry works - why should programming be any different?
I know exactly what sort of car I want and what kind of house I want to live in.Do you know how much you want the wheels turn? Do you know how strong you want the suspension springs to be? Do you know the exact wheelbase? Number, size and offsets of cylinders? Can you list all the electrical circuits you want in your car?
Do you know how deep you want your house foundation to go? Do you know which walls should be load-bearing? How thick the ceiling should be? Where should the vents be and how should they be connected? How should the water pipes, gas pipes, and electrical wires go and how thick they should be? And so on and so on and so on.
You think you know what you want but actually you don't know shit. The only difference between those and software is that now it's you on the other side of things - it's you who has to figure out all that for the customer, not someone else figuring it out for you.
-
The hard part of spec gathering and design is identifying three related but often very different things:
- What the user has asked for
- What the user wants
- What the user needs
-
-
I think it's useful to have a spec you can follow, but that you should also dare to ask "Do you really want this?" if the spec has dubious aspects or edge cases.
-
@Grunnen I'd go a step further. A spec is as much a product of software engineering as code. And all software engineering practices should be applied to it as well. Don't do everything at once - work in many small iterations. Don't be afraid of change. Test it. Validate it. Review it. Always improve it. If something doesn't make sense, change it. If something could be done better, change it. Make the end users of spec - ie. software developers - active participants of specification process.
But most important of all - HAVE THE SPEC IN THE FIRST PLACE. I've been at my current job for over 3 years and I've yet to see any specification. Believe me, you really don't want that to happen.
-
@Gąska said in Spec-driven or outcome-driven development?:
@Grunnen I'd go a step further. A spec is as much a product of software engineering as code. And all software engineering practices should be applied to it as well. Don't do everything at once - work in many small iterations. Don't be afraid of change. Test it. Validate it. Review it. Always improve it. If something doesn't make sense, change it. If something could be done better, change it. Make the end users of spec - ie. software developers - active participants of specification process.
But most important of all - HAVE THE SPEC IN THE FIRST PLACE. I've been at my current job for over 3 years and I've yet to see any specification. Believe me, you really don't want that to happen.
Yeah. An evolving, iterative, humble (with respect to change) spec is great. Not having a spec is horrible.
Not software, but I asked my former head of school "how do we know if we're doing a good job. How do we know what's working and what's not, before we just change things to stay "on trend""? His answer was so evasive it made me lose a lot of trust in him and his oversight. It was clear that he was just chasing trends, not actually measuring and responding to actual feedback.
-
I like coming up with solutions quite a bit more than implementing things.
I'd rather write a 20 page document explaining the design goals and trade-offs of a Content Management System than a single WordPress plugin.
-
IME, you need both a spec (as made by a domain-knowledgable analyst) and an outcome (as specified by the client). Then you know if the spec matches the outcome, and you also can/should challenge both spec/outcome with the appropriate person(s) if/when you get edge cases or even propose alternate scenarios.
-
@Gąska For us it often works like this: the customer sends us a Change Request, our the senior software engineers write an Analysis (including cost estimation) and send it back to the customer. Sometimes the customer will say that our Analysis is wrong. Sometimes the customer will modify their Change Request based on our Analysis. And of course we sometimes get the go-ahead for implementation. I like this process quite much.
(There is also an official Requirements document, but sometimes they can't update it before the start of implementation. But it should just reflect the latest Change Request anyway.)
I also have some experience with public tenders. There you have the Invitation to Tender (how they see it), you write the Offer (what you recommend), but that process is not very iterative and as soon as the contract is awarded everything is pretty much cast into concrete. It's of course a bit sad if, at the end of the trajectory, the product complies with the contract but the customer says "This is not really what makes us happy".
-
@Benjamin-Hall said in Spec-driven or outcome-driven development?:
That relies on the user knowing what they want.
And the user being included in the discussion. I believe that's why so many projects where I work fail.
-
@Benjamin-Hall said in Spec-driven or outcome-driven development?:
Not software, but I asked my former head of school "how do we know if we're doing a good job. How do we know what's working and what's not, before we just change things to stay "on trend""? His answer was so evasive it made me lose a lot of trust in him and his oversight. It was clear that he was just chasing trends, not actually measuring and responding to actual feedback.
There's a 
thread about that.
-
@anonymous234 said in Spec-driven or outcome-driven development?:
than a single WordPress plugin.
I mean, i'm pretty sure that being a surprise demonstratee at one of @error's parties is preferable to writing a WordPress plugin
-
@izzion said in Spec-driven or outcome-driven development?:
@anonymous234 said in Spec-driven or outcome-driven development?:
than a single WordPress plugin.
I mean, i'm pretty sure that being a surprise demonstratee at one of @error's parties is preferable to writing a WordPress plugin
Don't knock it til you try it.
-
@Grunnen said in Spec-driven or outcome-driven development?:
For us it often works like this: the customer sends us a Change Request, our the senior software engineers write an Analysis (including cost estimation) and send it back to the customer. Sometimes the customer will say that our Analysis is wrong. Sometimes the customer will modify their Change Request based on our Analysis. And of course we sometimes get the go-ahead for implementation. I like this process quite much.
(There is also an official Requirements document, but sometimes they can't update it before the start of implementation. But it should just reflect the latest Change Request anyway.)
I also have some experience with public tenders. There you have the Invitation to Tender (how they see it), you write the Offer (what you recommend), but that process is not very iterative and as soon as the contract is awarded everything is pretty much cast into concrete. It's of course a bit sad if, at the end of the trajectory, the product complies with the contract but the customer says "This is not really what makes us happy".
That's the closest to Waterfall that I've ever heard of a place working.
-
@error said in Spec-driven or outcome-driven development?:
@izzion said in Spec-driven or outcome-driven development?:
@anonymous234 said in Spec-driven or outcome-driven development?:
than a single WordPress plugin.
I mean, i'm pretty sure that being a surprise demonstratee at one of @error's parties is preferable to writing a WordPress plugin
Don't knock it til you try it.
If prefer to live on in blissful ignorance. WordPress sounds awful.
-
@dkf said in Spec-driven or outcome-driven development?:
That's the closest to Waterfall that I've ever heard of a place working.
Considered the nature of our software, I think that's not a bad thing.
The real annoyance is that the 'official' procedure is textbook Waterfall, where each finished Change Request should result in a modified Product Requirements Document, transformed into a Functional Specification, detailed in a Technical Specification and finally implemented in code.
That's unworkable, so the Product Requirements Document, the Functional Specification and Technical Specification are usually written as an afterthought and no-one ever seems to read them, but it still takes a lot of effort.
-
@izzion said in Spec-driven or outcome-driven development?:
I mean, i'm pretty sure that being a surprise demonstratee at one of @error's parties is preferable to writing a WordPress plugin
I've had to get involved with a WP plugin/theme combo and it's a bit messy, but it's really not that bad.
