3 ms·

I beg to differ. What has to be 'unlearned' is that Engineers think they have a clear vision of what they need to do ... but in reality they don't. This large

by jasmer 4y ago

I beg to differ. What has to be 'unlearned' is that Engineers think they have a clear vision of what they need to do ... but in reality they don't. This largely has to do with 'unknown unknowns', particularly in requirements. It's actually a much harder concept to learn/unlearn - because we are trained to design towards specs, towards a kind of perfection, to solve problems in which the conditions are contrived. Almost nothing in the academic world prepares people for having to build something whereupon the objectives are a bit fuzzy - especially when said objectives are not presented as fuzzy. It almost requires the 'experience of failure' to grasp that most things that can be incrementally built - should be. The process of building something, is actually a process of 'discovery'. I think that the only time 'prepping far ahead' becomes useful, is when Engineers are building on very foundational, learned knowledge derived from a relevant situation, in which case they are actually acting in an iterative fashion, leveraging knowledge from the previous 'situation' - but even then, I would not consider that for optimization, rather, just keeping a lid on arbitrary complexity. And finally, of course some things are reasonable. You probably are not going to build a high performance codec in Python.

trashtester 4y ago
Agree with almost everything above, except the first line. In military strategy there is the quote "Plans Are Worthless, But Planning Is Everything" [1]. I think the same goes for software design. To believe that one can do a complete design of some piece of software, and then implement it precisely as planned, is folly, just as for military plans. Still, it is imperative to do some deep thinking about the purpose of the software as one starts coding, especially about things like the purpose of the software (and what is NOT the purpose), design and design philosophy and expected challenges (including performance challenges) including ideas about how to find solutions to those challenges. Also, after starting to code, it's important to revisit these aspects. Is the purpose changing? If it is, is that good or bad? How do we define the new purpose? Are we making changes to the design? Why? Do we need to refine the design concepts? And so on. Just like for military strategy, this is an art more than a science. We have strong limitations dictated by what is possible, yet it is essential to have an overall idea of what direction we want to move in. Otherwise we, more likely than not, end up with a useless patchwork. [1] https://quoteinvestigator.com/2017/11/18/planning/ https://quoteinvestigator.com/2017/11/18/planning/
- agentultra 4y ago
  I think a part of this is that engineering concepts are not often introduced in a lot of CS courses. It is more often introduced in software engineering courses... of which there seem to be few? In my experience it's not well known that requirements are different than specifications and what those differences are. Knowing the difference makes understanding why planning is useful but "plans" are useless. Requirements state the desired properties of a system that affect our world. They are written from the perspective of humans interacting with a desired system to achieve some goal. It's useful to know that we need a system that does X so that we can Y. We need to ensure that Y eventually happens when the user initiates X. If the system cannot succeed at Y within Z minutes we need to notify the user so that they can initiate procedure J and halt the process manually. Requirements don't have to tell us how to implement such a system. They're more like the end state. It's the job of specifications to tell us, technically, how such a system operates. We, the developers building the system, don't have to write the full specifications up front. That's a bit of a mistake. Because the gap, as the GP points out, is quite large from the starting point and the end result. It's quite normal to start with the bare minimum specification and iterate towards an ideal one. As you learn about the problem space we can build more certainty about how such a system can be implemented. We can update the specifications, verify the code implements the specification, and hopefully in the end arrive at a system that fulfills our original requirements. It's rare that one can write the full, complete specification and leave it up to the developers to implement it.
- jasmer 4y ago
  Thanks for that comment, but one small thing - in the military it's really not 'planning' so much as it is 'training' (or 'preparing'). This actually makes the analogy a bit closer to startupland. The #1 factor in terms of predicting project outcomes is the 'quality of the people', so 'training' speaks to that. This is why I believe good early stage startups are so often focused on teams, not business models, because the later will change as the team orients dynamically towards 'something that works' and the analogy is right there for software as well. Embarrassingly, I'm working on a project now that would have been done 4x quicker were I to have known at the start what I do now! But that's how it works. This is quite a bit different than 'premature optimization' however ... but maybe it's related in terms of idioms and architecture, which are derived from experience. A good dev/architect can probably identify the 'roughly appropriate architecture' very quickly for something, which is the expression of a lot of built-in knowledge, and might encapsulate a lot of things. Aka: 'yeah we don't need protobuff for that or anything fancy, it's not worth it, just use json over http and you're good' etc.
Koshkin 4y ago
> This largely has to do with 'unknown unknowns' What has been much, much more worrisome in my practice, is ‘unknown knowns’ which is something developers should know but do not. Poor design and engineering skills, low level of professionalism is what keeps plaguing software industry. (Remarkably, most other industries, those that have to deal with material things, do not suffer from this - not on this scale anyway.)

by jasmer 4y ago

trashtester 4y ago

Agree with almost everything above, except the first line. In military strategy there is the quote "Plans Are Worthless, But Planning Is Everything" [1]. I think the same goes for software design. To believe that one can do a complete design of some piece of software, and then implement it precisely as planned, is folly, just as for military plans. Still, it is imperative to do some deep thinking about the purpose of the software as one starts coding, especially about things like the purpose of the software (and what is NOT the purpose), design and design philosophy and expected challenges (including performance challenges) including ideas about how to find solutions to those challenges. Also, after starting to code, it's important to revisit these aspects. Is the purpose changing? If it is, is that good or bad? How do we define the new purpose? Are we making changes to the design? Why? Do we need to refine the design concepts? And so on. Just like for military strategy, this is an art more than a science. We have strong limitations dictated by what is possible, yet it is essential to have an overall idea of what direction we want to move in. Otherwise we, more likely than not, end up with a useless patchwork. [1] https://quoteinvestigator.com/2017/11/18/planning/ https://quoteinvestigator.com/2017/11/18/planning/

agentultra 4y ago
I think a part of this is that engineering concepts are not often introduced in a lot of CS courses. It is more often introduced in software engineering courses... of which there seem to be few? In my experience it's not well known that requirements are different than specifications and what those differences are. Knowing the difference makes understanding why planning is useful but "plans" are useless. Requirements state the desired properties of a system that affect our world. They are written from the perspective of humans interacting with a desired system to achieve some goal. It's useful to know that we need a system that does X so that we can Y. We need to ensure that Y eventually happens when the user initiates X. If the system cannot succeed at Y within Z minutes we need to notify the user so that they can initiate procedure J and halt the process manually. Requirements don't have to tell us how to implement such a system. They're more like the end state. It's the job of specifications to tell us, technically, how such a system operates. We, the developers building the system, don't have to write the full specifications up front. That's a bit of a mistake. Because the gap, as the GP points out, is quite large from the starting point and the end result. It's quite normal to start with the bare minimum specification and iterate towards an ideal one. As you learn about the problem space we can build more certainty about how such a system can be implemented. We can update the specifications, verify the code implements the specification, and hopefully in the end arrive at a system that fulfills our original requirements. It's rare that one can write the full, complete specification and leave it up to the developers to implement it.
jasmer 4y ago
Thanks for that comment, but one small thing - in the military it's really not 'planning' so much as it is 'training' (or 'preparing'). This actually makes the analogy a bit closer to startupland. The #1 factor in terms of predicting project outcomes is the 'quality of the people', so 'training' speaks to that. This is why I believe good early stage startups are so often focused on teams, not business models, because the later will change as the team orients dynamically towards 'something that works' and the analogy is right there for software as well. Embarrassingly, I'm working on a project now that would have been done 4x quicker were I to have known at the start what I do now! But that's how it works. This is quite a bit different than 'premature optimization' however ... but maybe it's related in terms of idioms and architecture, which are derived from experience. A good dev/architect can probably identify the 'roughly appropriate architecture' very quickly for something, which is the expression of a lot of built-in knowledge, and might encapsulate a lot of things. Aka: 'yeah we don't need protobuff for that or anything fancy, it's not worth it, just use json over http and you're good' etc.

Koshkin 4y ago

> This largely has to do with 'unknown unknowns' What has been much, much more worrisome in my practice, is ‘unknown knowns’ which is something developers should know but do not. Poor design and engineering skills, low level of professionalism is what keeps plaguing software industry. (Remarkably, most other industries, those that have to deal with material things, do not suffer from this - not on this scale anyway.)