3 ms·

> Building arbitrary scale SaaS data services, complex cryptographic platforms, more recently AI stuff, all are replete with unknowns. I think we can all agree

by epups 3y ago

> Building arbitrary scale SaaS data services, complex cryptographic platforms, more recently AI stuff, all are replete with unknowns. I think we can all agree that the vast majority of software work does not belong to the categories above, and is therefore relatively predictable.

fnordpiglet 3y ago
I don’t think I agree, I think most software is written in the context of megacorps, and it’s mostly complex business logic. Further, an awful lot of developers work in government, military, scientific, big tech, and a bunch of very technical software development endeavors. I think some work that can nominally be called software, which I classified as mostly graphic design and related plumbing in my response is relatively predictable. My web design folks claim they’re very productive in scrum, mostly because it’s mostly about pinning down customer requirements and churning out known patterns. This is not something you get a degree in computer science to do, and I don’t really consider it software development. Likewise, setting up SAP integrations or Salesforce integrations isn’t really software development. It’s something like it - but there’s no development of software - just configuration of already written software to customize it to a context. I’m sure we can disagree here, but I would note we don’t all agree.
- epups 3y ago
  Sorry but your entire point sounds like a no true scotsman to me. The work of developing useful software which most people get paid to do is, in fact, relatively predictable. Maybe we are all truly peasants who do inferior work that you don't dare classify as software, maybe what you do is truly groundbreaking (I already accepted that as a valid exception), or maybe you have been working with people who just suck at estimates.
  - fnordpiglet 3y ago
    I’m not saying design based work isn’t real work or has no value. But I don’t consider it software development in the way I don’t consider magazine layout software development, even though it’s complex and difficult work. But it’s fairly rote and mechanical, and doesn’t require any software development. For instance I consider developing react to be software development. I consider making a chat system in react software development. I do not consider making a brand layout using a web framework to be software development. As an example, generally in business you classify software development as R&D for accounting purposes. It’s speculative, has uncertain payout, uncertain development times. Website creation on the other hand can’t be treated as R&D. It’s capitalized under a different amortization schedule. I’m sorry if it sounds like I’m making some qualitative distinction in terms of value or whatever. That isn’t my point. My point is when we discuss software development and software engineering they are about development of software. I think most people can distinguish between front end web development, and say, developing a web development framework as distinctly different pursuits with very different characters in terms of skill sets, riskiness, predictability. You can adopt an expansive view, but you took issue with my statement without taking into consideration my measure.
- Scarblac 3y ago
  In my experience pinning down user requirements (and then getting feedback on your understanding of their needs, and iterating on that) is one of the most important parts of software development, not just in "web design". It's also the hardest part of "complex business logic", and the main subject of books like Domain Driven Development. And it's the hardest part to estimate. To make estimates you must first get the requirements clear, but that's a major part of what you were trying to estimate.
  - fnordpiglet 3y ago
    I agree, and that needs to be done in both cases. A complex business logic system has an awful lot of unknowns because it’s never been built before. While systems that talk to similar problems might have, businesses are highly complex in themselves and even the users usually can’t articulate how things actually should work or why. They usually can only explain what they like or dislike about the small part they do in their job. That’s much harder than a brand managed layout rendering. Edit: the hardest business logic is actually brownfield development - where the users who knew why don’t exist any more, and the developers who figured it out have moved on. I think these are the hardest to predict efforts with the least management margin of error for prediction mistakes. It also, IMO distinguishes between a good engineer and a great one. A good engineer can write code. A great one can improve code that been improved by hundreds of different people over decades.

by epups 3y ago

fnordpiglet 3y ago

I don’t think I agree, I think most software is written in the context of megacorps, and it’s mostly complex business logic. Further, an awful lot of developers work in government, military, scientific, big tech, and a bunch of very technical software development endeavors. I think some work that can nominally be called software, which I classified as mostly graphic design and related plumbing in my response is relatively predictable. My web design folks claim they’re very productive in scrum, mostly because it’s mostly about pinning down customer requirements and churning out known patterns. This is not something you get a degree in computer science to do, and I don’t really consider it software development. Likewise, setting up SAP integrations or Salesforce integrations isn’t really software development. It’s something like it - but there’s no development of software - just configuration of already written software to customize it to a context. I’m sure we can disagree here, but I would note we don’t all agree.

epups 3y ago
Sorry but your entire point sounds like a no true scotsman to me. The work of developing useful software which most people get paid to do is, in fact, relatively predictable. Maybe we are all truly peasants who do inferior work that you don't dare classify as software, maybe what you do is truly groundbreaking (I already accepted that as a valid exception), or maybe you have been working with people who just suck at estimates.
- fnordpiglet 3y ago
  I’m not saying design based work isn’t real work or has no value. But I don’t consider it software development in the way I don’t consider magazine layout software development, even though it’s complex and difficult work. But it’s fairly rote and mechanical, and doesn’t require any software development. For instance I consider developing react to be software development. I consider making a chat system in react software development. I do not consider making a brand layout using a web framework to be software development. As an example, generally in business you classify software development as R&D for accounting purposes. It’s speculative, has uncertain payout, uncertain development times. Website creation on the other hand can’t be treated as R&D. It’s capitalized under a different amortization schedule. I’m sorry if it sounds like I’m making some qualitative distinction in terms of value or whatever. That isn’t my point. My point is when we discuss software development and software engineering they are about development of software. I think most people can distinguish between front end web development, and say, developing a web development framework as distinctly different pursuits with very different characters in terms of skill sets, riskiness, predictability. You can adopt an expansive view, but you took issue with my statement without taking into consideration my measure.
Scarblac 3y ago
In my experience pinning down user requirements (and then getting feedback on your understanding of their needs, and iterating on that) is one of the most important parts of software development, not just in "web design". It's also the hardest part of "complex business logic", and the main subject of books like Domain Driven Development. And it's the hardest part to estimate. To make estimates you must first get the requirements clear, but that's a major part of what you were trying to estimate.
- fnordpiglet 3y ago
  I agree, and that needs to be done in both cases. A complex business logic system has an awful lot of unknowns because it’s never been built before. While systems that talk to similar problems might have, businesses are highly complex in themselves and even the users usually can’t articulate how things actually should work or why. They usually can only explain what they like or dislike about the small part they do in their job. That’s much harder than a brand managed layout rendering. Edit: the hardest business logic is actually brownfield development - where the users who knew why don’t exist any more, and the developers who figured it out have moved on. I think these are the hardest to predict efforts with the least management margin of error for prediction mistakes. It also, IMO distinguishes between a good engineer and a great one. A good engineer can write code. A great one can improve code that been improved by hundreds of different people over decades.