3 ms·

I read somewhere a quote that stuck with me: "No tool is ever going to free us from the burden of clarifying our ideas." And that's how I view my job as a soft

I read somewhere a quote that stuck with me: "No tool is ever going to free us from the burden of clarifying our ideas." And that's how I view my job as a software developer: clarifying ideas. Any "No Code" tool is still going to either force you to clarify your ideas, or have a large amount of assumptions. "Idea People" and "Business" don't like that, so they'll probably end up delegating the use of "No Code" tools to programmers of some sort.

worldsayshi 7y ago
There are plenty of tools that help us in clarifying our ideas though. Take mathematical notation for example. Or music notation. Or a CAD program. All are examples of domain specific tools that allow the user to specify their intention in a non-ambiguous way. And they also allow the user to think about and experiment with the problem space. I think what we need is something akin to this. The "business logic" that we are talking about here is to me a non-infinite domain. It should be possible to boil it down into a domain specific tool that is more helpful than a general purpose programming language.
- taneq 7y ago
  They all help, yes, but you still have to know what you’re trying to achieve.
- bitcuration 7y ago
  Business domain vs. Math., that's an interesting comparison. The problem is that business domain is exact an "infinite domain", in comparing with Math. Or to say that the competitive nature of business is very much reliant on its ability to break its domain boundary. Again, not so much in the case of Math.
  - marcosdumay 7y ago
    > Again, not so much in the case of Math. I will resonantly disagree here. Math is successful exactly because each time it had a rule that was problematic, people just extended it. And the success of modern (20th+ century) Math is caused exactly by the fact that we got an inifinitely extensible language, so nobody has to ever break it again anymore.
- matthewowen 7y ago
  some sort of "common business-oriented language"?
- jimbokun 7y ago
  > Take mathematical notation for example. Or music notation. Or a CAD program. Or programming languages.
Angostura 7y ago
I rather disagree. I work at a large non-profit. I'm not a coder, but I'm IT literate, and know enough about database design to not do absolutely stupid things. I'm happy to document processes enjoy clarifying ideas. We use Sharepoint. In many many respects Sharepoint is detestable garbage, but I have managed to create some really quite complex automated workflows which are saving people in the organisation a lot of time, using Sharepoint Designer (no coding). It's documented, fairly robust and I wouldn't have been able to write it in a conventional language.
- logicIsTruth 7y ago
  Eh, the automation I've done between python, vba, and SharePoint (language/markup) has convinced me anything is possible.
- emilecantin 7y ago
  > I'm not a coder, but I'm IT literate I'd say you're at least some kind of coder. My point is that there will always be room in an organization for people like us, who aren't afraid to go down and use our tools to the fullest extent, to save "people in the organization" enormous amounts of time. These tools can be code or something else, but the point is clarifying ideas. The exact tool you use doesn't matter. "No Code" is not an existential threat to developers, it's just another programming language.
_pmf_ 7y ago
Stateflow enables better communication with domain experts at automotive OEMs than any other formal or non formal specification language I know. So I'd count this as "plus No Code".
jhjjhj 7y ago
could it have been https://www.xkcd.com/568/ https://www.xkcd.com/568/
cr0sh 7y ago
Part of it is "clarifying ideas". But I think there's another important part: Clarifying processes I'd wager that the vast majority of businesses have no idea how their internal processes actually operate, what steps they take, what steps are already automated, what steps are not automated but could be, and what steps don't seem like steps but are actually super-important parts of the overall process. I'm not an expert in the domain, but a few employers ago I worked for a company that was heavily involved in Six Sigma. Yes, it was a management buzzword. In many cases it was probably being used wrong. Or was being applied in a manner orthogonal to the problem. Or...any number of other things. But one thing we studied in our "off time" (the company was a focused membership organization - we had magazines, conferences, everything) was how to apply 6S to our own business (you'd think that would have been done from the beginning - you'd be wrong). One thing we looked into, and attempted to understand and apply, was business process mapping. That is - everything (and more) that I noted above - in various forms of flow-charting and other process mapping diagram systems, mostly done by hand, as it was easier for multiple people to see the processes and reason about them. Once we had things relatively "tacked down", we would convert those over to an electronic form. It was an interesting exercise, and we never completely finished it before I moved on (the company went belly up soon after I left, as I was the only SWE left - it wasn't a large business). But we did notice in the exercise some interesting things: 1. If your business process flowchart looks messy, and can't be "untangled" - there are problems with your process. 2. Similar to #1 - if the flowchart looks unbalanced, even after untangling, there may be issues with the process as a whole. 3. Process flow lines that cross should be avoided; usually this is just a result of how things are arranged, but if you re-arrange things and still find a lot of criss-crossing lines, and can't make them not cross - again, issues may be there. 4. Soft processes are real processes - and trips things up. These are things where you might do something "out of the loop" or talk to somebody about something - but it doesn't seem like a real part of the process - but if it weren't done - the whole thing would break. Usually, these kinds of things aren't uncovered until one or another party leaves, either permanently or while "on vacation". Sometimes, the issue doesn't appear until some automation is put in that leaves that soft-process out, or unintentionally goes around it - then it can stick out like a sore thumb. Identifying these processes - and they can be difficult to identify, as sometimes even the person doing it doesn't know they do it, as you talk to them about their role in the overall process. You have to watch them do it. This last one - there's a story I once read, I'll condense it as best as possible: A woman brings her car into the shop complaining that the vehicle isn't running well after driving it a while. She gets in it to go to work, and at first it's ok, but within a mile or so it doesn't run very well. She doesn't know what is wrong. The mechanic looks at it, starts it up, it seems like it runs well. He tries it in the morning, everything is ok. He calls the owner and she comes into the shop and gets her car, but returns the next day complaining that it is still running strange. The mechanic asks if he can take a ride with her, to show him the problem. She says sure, they get inside the car, and as he sits down in the passenger seat, he sees her pull out the choke and hang her purse on it. It turns out that her previous car had a special pull out "hook" for just that purpose, and she didn't know. After the mechanic explained the problem, she had no idea, but the problem was fixed. No charge. Ok - showing my age a bit there, and it's a somewhat contrived story - but the point is there: A process can be so ingrained for a single individual (or even within an automated process) that it is forgotten that it is needed (or shouldn't be done - depending on the situation) that it is overlooked when automation, or even just "process mapping" is done. This can lead to interesting problems - and sometimes they can be hard to understand unless you are "in the driver's seat" so to speak. So, that's also part of the job of a software engineer - figuring out these processes. The problem is for many if not most companies, they don't even know what their processes are, because they never actually planned them. More often than not, they mostly grew organically, and evolved, and quite often if you attempt to process map (physically graph) these processes, you'll find the many of the issues I noted above stand out. You'll find omissions and inefficiencies all over the place. You'll find redundancy (and sometimes, this redundancy is there because if it is taken out - things break in weird ways - figuring out how to restructure things to fix this can be a real challenge). You'll find you're dealing with an organism more so than a machine. Automating such a thing can be an exhausting challenge even for a proper team of developers...

worldsayshi 7y ago

There are plenty of tools that help us in clarifying our ideas though. Take mathematical notation for example. Or music notation. Or a CAD program. All are examples of domain specific tools that allow the user to specify their intention in a non-ambiguous way. And they also allow the user to think about and experiment with the problem space. I think what we need is something akin to this. The "business logic" that we are talking about here is to me a non-infinite domain. It should be possible to boil it down into a domain specific tool that is more helpful than a general purpose programming language.

taneq 7y ago
They all help, yes, but you still have to know what you’re trying to achieve.
bitcuration 7y ago
Business domain vs. Math., that's an interesting comparison. The problem is that business domain is exact an "infinite domain", in comparing with Math. Or to say that the competitive nature of business is very much reliant on its ability to break its domain boundary. Again, not so much in the case of Math.
- marcosdumay 7y ago
  > Again, not so much in the case of Math. I will resonantly disagree here. Math is successful exactly because each time it had a rule that was problematic, people just extended it. And the success of modern (20th+ century) Math is caused exactly by the fact that we got an inifinitely extensible language, so nobody has to ever break it again anymore.
matthewowen 7y ago
some sort of "common business-oriented language"?
jimbokun 7y ago
> Take mathematical notation for example. Or music notation. Or a CAD program. Or programming languages.

Angostura 7y ago

I rather disagree. I work at a large non-profit. I'm not a coder, but I'm IT literate, and know enough about database design to not do absolutely stupid things. I'm happy to document processes enjoy clarifying ideas. We use Sharepoint. In many many respects Sharepoint is detestable garbage, but I have managed to create some really quite complex automated workflows which are saving people in the organisation a lot of time, using Sharepoint Designer (no coding). It's documented, fairly robust and I wouldn't have been able to write it in a conventional language.

logicIsTruth 7y ago
Eh, the automation I've done between python, vba, and SharePoint (language/markup) has convinced me anything is possible.
emilecantin 7y ago
> I'm not a coder, but I'm IT literate I'd say you're at least some kind of coder. My point is that there will always be room in an organization for people like us, who aren't afraid to go down and use our tools to the fullest extent, to save "people in the organization" enormous amounts of time. These tools can be code or something else, but the point is clarifying ideas. The exact tool you use doesn't matter. "No Code" is not an existential threat to developers, it's just another programming language.

_pmf_ 7y ago

Stateflow enables better communication with domain experts at automotive OEMs than any other formal or non formal specification language I know. So I'd count this as "plus No Code".

jhjjhj 7y ago

could it have been https://www.xkcd.com/568/ https://www.xkcd.com/568/

cr0sh 7y ago

Part of it is "clarifying ideas". But I think there's another important part: Clarifying processes I'd wager that the vast majority of businesses have no idea how their internal processes actually operate, what steps they take, what steps are already automated, what steps are not automated but could be, and what steps don't seem like steps but are actually super-important parts of the overall process. I'm not an expert in the domain, but a few employers ago I worked for a company that was heavily involved in Six Sigma. Yes, it was a management buzzword. In many cases it was probably being used wrong. Or was being applied in a manner orthogonal to the problem. Or...any number of other things. But one thing we studied in our "off time" (the company was a focused membership organization - we had magazines, conferences, everything) was how to apply 6S to our own business (you'd think that would have been done from the beginning - you'd be wrong). One thing we looked into, and attempted to understand and apply, was business process mapping. That is - everything (and more) that I noted above - in various forms of flow-charting and other process mapping diagram systems, mostly done by hand, as it was easier for multiple people to see the processes and reason about them. Once we had things relatively "tacked down", we would convert those over to an electronic form. It was an interesting exercise, and we never completely finished it before I moved on (the company went belly up soon after I left, as I was the only SWE left - it wasn't a large business). But we did notice in the exercise some interesting things: 1. If your business process flowchart looks messy, and can't be "untangled" - there are problems with your process. 2. Similar to #1 - if the flowchart looks unbalanced, even after untangling, there may be issues with the process as a whole. 3. Process flow lines that cross should be avoided; usually this is just a result of how things are arranged, but if you re-arrange things and still find a lot of criss-crossing lines, and can't make them not cross - again, issues may be there. 4. Soft processes are real processes - and trips things up. These are things where you might do something "out of the loop" or talk to somebody about something - but it doesn't seem like a real part of the process - but if it weren't done - the whole thing would break. Usually, these kinds of things aren't uncovered until one or another party leaves, either permanently or while "on vacation". Sometimes, the issue doesn't appear until some automation is put in that leaves that soft-process out, or unintentionally goes around it - then it can stick out like a sore thumb. Identifying these processes - and they can be difficult to identify, as sometimes even the person doing it doesn't know they do it, as you talk to them about their role in the overall process. You have to watch them do it. This last one - there's a story I once read, I'll condense it as best as possible: A woman brings her car into the shop complaining that the vehicle isn't running well after driving it a while. She gets in it to go to work, and at first it's ok, but within a mile or so it doesn't run very well. She doesn't know what is wrong. The mechanic looks at it, starts it up, it seems like it runs well. He tries it in the morning, everything is ok. He calls the owner and she comes into the shop and gets her car, but returns the next day complaining that it is still running strange. The mechanic asks if he can take a ride with her, to show him the problem. She says sure, they get inside the car, and as he sits down in the passenger seat, he sees her pull out the choke and hang her purse on it. It turns out that her previous car had a special pull out "hook" for just that purpose, and she didn't know. After the mechanic explained the problem, she had no idea, but the problem was fixed. No charge. Ok - showing my age a bit there, and it's a somewhat contrived story - but the point is there: A process can be so ingrained for a single individual (or even within an automated process) that it is forgotten that it is needed (or shouldn't be done - depending on the situation) that it is overlooked when automation, or even just "process mapping" is done. This can lead to interesting problems - and sometimes they can be hard to understand unless you are "in the driver's seat" so to speak. So, that's also part of the job of a software engineer - figuring out these processes. The problem is for many if not most companies, they don't even know what their processes are, because they never actually planned them. More often than not, they mostly grew organically, and evolved, and quite often if you attempt to process map (physically graph) these processes, you'll find the many of the issues I noted above stand out. You'll find omissions and inefficiencies all over the place. You'll find redundancy (and sometimes, this redundancy is there because if it is taken out - things break in weird ways - figuring out how to restructure things to fix this can be a real challenge). You'll find you're dealing with an organism more so than a machine. Automating such a thing can be an exhausting challenge even for a proper team of developers...