3 ms·

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 i

by 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.

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.