6 ms·

No, the correctness is in the eye of a spec. Now, whether companies formally define their specs is a different story. Many startups don't. With that said, if M

by Denzel 9y ago

No, the correctness is in the eye of a spec. Now, whether companies formally define their specs is a different story. Many startups don't. With that said, if Microsoft Word meets the given spec, then it's correct. One way to prove this correctness is with testing. This is the case for bridges as well. If I hand a spec to an engineering firm requesting a bridge from A to B at any given price. Well then, there's a lot of bridges that satisfy those constraints. Just because many software companies today don't choose to formally specify a spec and prove a programs correctness upon delivery doesn't mean it's a special snowflake. It just means those teams are immature. Sometimes software development doesn't require a mature team. Like most decisions, there's a cost and timing tradeoff.

stale2002 9y ago
The problem with this line of thinking is that the problems that matter are not related to 100% implementing the spec correctly. The problems that matter are in the design of the spec to begin with. The important part is picking the CORRECT business requirements, NOT in implementing those business requirements correctly. And do you know what the best way is to test whether you got the spec right? You deploy and see if the feature gets traction. The "spec" that matters is the success of the business. And building a product, and releasing it, is the way to formally test if your feature is "correct" according to the spec that is The Market.
- jolux 9y ago
  >The important part is picking the CORRECT business requirements, NOT in implementing those business requirements correctly. It's both, though. You also can't tell if you've implemented them correctly if you don't have a formal spec.
  - sbov 9y ago
    Your notion of correct does not apply to everyone: for many of my projects, the implementation that goes against the spec but has higher traction is implemented correctly, and the implementation that follows the spec but has lower traction is implemented incorrectly. The spec is just someone's idea of what will have the highest traction - it doesn't make code that follows it correct.
    - Denzel 9y ago
      No, you just don't understand the definition of correctness as it relates to software. Correctness -- like safety -- is formally defined. You might want to look it up.
  - stale2002 9y ago
    Not really. If I make a mistake building my web app, then it will either not matter, or someone will notice the bug in production. And then when someone notices the bug in production, it can be fixed. If nobody notices it, then I guess it wasn't very important to begin with and can be left "broken". Implementation bugs are the EASY part, and don't matter a lot of the time. Or here is a better scenario. Lets say I am writing a feature, and I think of a way to implement the feature much quicker, but isn't 100% "correct" according to the spec. The quick and dirty, but "incorrect" way to implement it may actually be a better thing to do, because now I can spend my time working on other stuff that is more important. Purposefully doing the "incorrect" thing according to spec, may actually be the right decision.
- Denzel 9y ago
  Uhm... I was responding to a conversation about software engineering not product development. The two are orthogonal. You just described the responsibility of a product manager, and finding product-market fit. None of which requires software development. Software development may help but product management certainly doesn't require it.
  - stale2002 9y ago
    This is not at all the case. Product development skills are extremely important for a software engineer to have, especially at smaller companies, because a lot of the time the person making these product decisions IS the engineer. During my engineering career, most of the time my boss gives me a general goal for a product or feature that needs to be built. And then I take that general idea for a product, and make all the product decisions about what to build and how to build it MYSELF. At smaller companies there may be NO product manager. Or maybe the product manager is only making very high level decisions, and isn't really involved in every little nitty gritty detail about the product. You the engineer have to make the product decisions. And you have to balance those product decisions against tradeoffs, such as how long would it take to build, how high quality it is, and other software engineering design tradeoffs. Product design and software engineering are very closely related, and any good senior engineer should be competent at both. Software engineering makes you better at product design, and vice versa.
    - Denzel 9y ago
      Like I said: A may help B or B may help A, does not imply B requires A. Where A = software development; B = product management. Yes, most startups don't formally define their spec. That's what I've said. Managing the spec and ensuring product-market fit falls under the domain of a product manager. So, that's great, you did software development and product management. You wore many hats... like most people do in startups. Doesn't negate the fact that you were a software engineer taking on additional responsibilities. Trust me, when you work on a team with a clear separation between product management and software engineering and you have a great product manager... it is pure bliss. The only company I've ever felt that technical nirvana with was Google. My god they know what they're doing when it comes to software engineering and separation of responsibilities. At least the team I was on did.
akvadrako 9y ago
But software is the spec. In many cases, if you can formally specify what a function should do, you have already written it.
- saltedmd5 9y ago
  "But software is the spec." This whole discussion can be replaced with this sentence.
  - Jtsummers 9y ago
    There are very, very few languages (or few applications of every language) where we can honestly say "software is the spec". Please tell me, what is the specification of this code so that we can verify and validate it: (defun f (x y) (* x y)) Is the specification: `f` shall return the product of two numbers? Perhaps. Perhaps it was supposed to be addition. Perhaps it was only supposed to apply to integers. If the above spec is correct, is the code correct? Maybe. It doesn't react well when given non-numeric values. Is that a problem? I don't know, the code doesn't explain who is responsible for validating input and who is responsible for handling errors. A specification is a hybrid prose/formal document that would give us all that information (if it had any value). The code above is not a specification, it is an implementation. No different than a gear or a cog or a lever in mechanical engineering. It is a thing which does some work. We can examine it and see what it does. But we cannot, by observation or execution, determine why without greater context. That context is the specification. The software is an artifact, one among many, which (hopefully) satisfies a specification.
- Denzel 9y ago
  You're misunderstanding what I mean by spec. A spec is made up of a list of requirements. This list of requirements can be considered constraints on processes, performance, features, limitations, whatever. Whatever makes sense in the world of the specifier. For example, I can have a requirement that says: "The program shall generate a set of weekly time schedules that are maximally preferable, based upon each students' preferences, for all students at a given location while taking into account resource constraints re: room availability and teacher availability." Of course, this isn't specified to the level of detail I'd put in a real spec, but it serves as an example. There's many ways to solve this requirement, i.e., there are many different programs that satisfy this spec. There are two solutions that may stand out: (1) a brute-force approach, and (2) a convex optimization approach. Since I've not explicitly defined a speed of execution requirement in this spec, then a brute-force approach may make sense... even if it runs for 5 days. In the real-world, you'd confirm this undefined assumption. If instead my spec said this needs to complete within a day, then maybe the convex approach would make more sense. However, you'd first seek more definition in the spec, i.e., how many students are we generating schedules for? If it's only 10, maybe brute-force, if it's 20k, then convex. So on and so forth. Now, the interesting part comes when you create the end-to-end (E2E) and acceptance tests. These tests should be the first thing you write because they follow directly from the spec. They will stand up the program as if it's running in production and drive it as such to test whether it adheres to the spec. Once all your E2E and acceptance tests are passing, and we've eatablished that your tests cover the spec completely, then we can mark the program as correct with respect to the spec. There are many different software designs that satisfy a spec. The software is not the spec.

by Denzel 9y ago

stale2002 9y ago

The problem with this line of thinking is that the problems that matter are not related to 100% implementing the spec correctly. The problems that matter are in the design of the spec to begin with. The important part is picking the CORRECT business requirements, NOT in implementing those business requirements correctly. And do you know what the best way is to test whether you got the spec right? You deploy and see if the feature gets traction. The "spec" that matters is the success of the business. And building a product, and releasing it, is the way to formally test if your feature is "correct" according to the spec that is The Market.

jolux 9y ago
>The important part is picking the CORRECT business requirements, NOT in implementing those business requirements correctly. It's both, though. You also can't tell if you've implemented them correctly if you don't have a formal spec.
- sbov 9y ago
  Your notion of correct does not apply to everyone: for many of my projects, the implementation that goes against the spec but has higher traction is implemented correctly, and the implementation that follows the spec but has lower traction is implemented incorrectly. The spec is just someone's idea of what will have the highest traction - it doesn't make code that follows it correct.
  - Denzel 9y ago
    No, you just don't understand the definition of correctness as it relates to software. Correctness -- like safety -- is formally defined. You might want to look it up.
- stale2002 9y ago
  Not really. If I make a mistake building my web app, then it will either not matter, or someone will notice the bug in production. And then when someone notices the bug in production, it can be fixed. If nobody notices it, then I guess it wasn't very important to begin with and can be left "broken". Implementation bugs are the EASY part, and don't matter a lot of the time. Or here is a better scenario. Lets say I am writing a feature, and I think of a way to implement the feature much quicker, but isn't 100% "correct" according to the spec. The quick and dirty, but "incorrect" way to implement it may actually be a better thing to do, because now I can spend my time working on other stuff that is more important. Purposefully doing the "incorrect" thing according to spec, may actually be the right decision.
Denzel 9y ago
Uhm... I was responding to a conversation about software engineering not product development. The two are orthogonal. You just described the responsibility of a product manager, and finding product-market fit. None of which requires software development. Software development may help but product management certainly doesn't require it.
- stale2002 9y ago
  This is not at all the case. Product development skills are extremely important for a software engineer to have, especially at smaller companies, because a lot of the time the person making these product decisions IS the engineer. During my engineering career, most of the time my boss gives me a general goal for a product or feature that needs to be built. And then I take that general idea for a product, and make all the product decisions about what to build and how to build it MYSELF. At smaller companies there may be NO product manager. Or maybe the product manager is only making very high level decisions, and isn't really involved in every little nitty gritty detail about the product. You the engineer have to make the product decisions. And you have to balance those product decisions against tradeoffs, such as how long would it take to build, how high quality it is, and other software engineering design tradeoffs. Product design and software engineering are very closely related, and any good senior engineer should be competent at both. Software engineering makes you better at product design, and vice versa.
  - Denzel 9y ago
    Like I said: A may help B or B may help A, does not imply B requires A. Where A = software development; B = product management. Yes, most startups don't formally define their spec. That's what I've said. Managing the spec and ensuring product-market fit falls under the domain of a product manager. So, that's great, you did software development and product management. You wore many hats... like most people do in startups. Doesn't negate the fact that you were a software engineer taking on additional responsibilities. Trust me, when you work on a team with a clear separation between product management and software engineering and you have a great product manager... it is pure bliss. The only company I've ever felt that technical nirvana with was Google. My god they know what they're doing when it comes to software engineering and separation of responsibilities. At least the team I was on did.

akvadrako 9y ago

But software is the spec. In many cases, if you can formally specify what a function should do, you have already written it.

saltedmd5 9y ago
"But software is the spec." This whole discussion can be replaced with this sentence.
- Jtsummers 9y ago
  There are very, very few languages (or few applications of every language) where we can honestly say "software is the spec". Please tell me, what is the specification of this code so that we can verify and validate it: (defun f (x y) (* x y)) Is the specification: `f` shall return the product of two numbers? Perhaps. Perhaps it was supposed to be addition. Perhaps it was only supposed to apply to integers. If the above spec is correct, is the code correct? Maybe. It doesn't react well when given non-numeric values. Is that a problem? I don't know, the code doesn't explain who is responsible for validating input and who is responsible for handling errors. A specification is a hybrid prose/formal document that would give us all that information (if it had any value). The code above is not a specification, it is an implementation. No different than a gear or a cog or a lever in mechanical engineering. It is a thing which does some work. We can examine it and see what it does. But we cannot, by observation or execution, determine why without greater context. That context is the specification. The software is an artifact, one among many, which (hopefully) satisfies a specification.
Denzel 9y ago
You're misunderstanding what I mean by spec. A spec is made up of a list of requirements. This list of requirements can be considered constraints on processes, performance, features, limitations, whatever. Whatever makes sense in the world of the specifier. For example, I can have a requirement that says: "The program shall generate a set of weekly time schedules that are maximally preferable, based upon each students' preferences, for all students at a given location while taking into account resource constraints re: room availability and teacher availability." Of course, this isn't specified to the level of detail I'd put in a real spec, but it serves as an example. There's many ways to solve this requirement, i.e., there are many different programs that satisfy this spec. There are two solutions that may stand out: (1) a brute-force approach, and (2) a convex optimization approach. Since I've not explicitly defined a speed of execution requirement in this spec, then a brute-force approach may make sense... even if it runs for 5 days. In the real-world, you'd confirm this undefined assumption. If instead my spec said this needs to complete within a day, then maybe the convex approach would make more sense. However, you'd first seek more definition in the spec, i.e., how many students are we generating schedules for? If it's only 10, maybe brute-force, if it's 20k, then convex. So on and so forth. Now, the interesting part comes when you create the end-to-end (E2E) and acceptance tests. These tests should be the first thing you write because they follow directly from the spec. They will stand up the program as if it's running in production and drive it as such to test whether it adheres to the spec. Once all your E2E and acceptance tests are passing, and we've eatablished that your tests cover the spec completely, then we can mark the program as correct with respect to the spec. There are many different software designs that satisfy a spec. The software is not the spec.