4 ms·

This remind me of the recent Microsoft AI that can write code demo. You give the AI instruction and explanation in English, preferably as clear and as detailed

by matz1 6y ago

This remind me of the recent Microsoft AI that can write code demo. You give the AI instruction and explanation in English, preferably as clear and as detailed as possible and you get back code. Essentially its very similar workflow when working with offshore developer, in the future you could in theory replace the offshore dev with AI, except with much less latency.

akmarinov 6y ago
Well you can replace all developers by that logic not just offshore ones.
ChrisMarshallNY 6y ago
The issues we have with any code development; whether through on-site employees, offsite employees, contract shops, or integrated contractors, would also apply to AI. Those of us that have been doing it a while, know that the single biggest issue in any commercial code project is bad input to the process; otherwise known as Requirements. No one knows what they want, or, even worse, they know what they want, and what they want, sucks. Steve McConnell wrote about how projects mess up, and how much the damage can propagate throughout a project lifecycle; with bad requirements being the nightmare scenario. This was about a quarter century ago. It is not new (https://stevemcconnell.com/articles/software-quality-at-top-speed/ https://stevemcconnell.com/articles/software-quality-at-top-...). The best requirements for a software project is code. Even an AI will need extremely high-quality, detailed, and well-considered requirements that are likely to require their own language (so AI requirement-generation will look a heck of a lot like "coding"). What AI gives us, is (maybe) speed between requirements and executable, so, theoretically, we could have a really high-power, effective iterative process, where bad input results in bad output, and we see that quickly, then refine the input; much like we already do with code, and run the build again, to see how that results in executable. I learned development back in the "big iron" days, where CPU time was the most expensive part of the process, and we were required to debug our code in the design phase. If we borked during our slice, we were penalized. Nowadays, I tend to just write some junky "strawman" code, fire up the debugger, and step through until it breaks. Working with separate contractors, whether domestic or offshore, needs really good requirements, and some kind of fast feedback and a flexible, iterative lifecycle process; which is frog-fur rare. If we don't have a fast feedback cycle, then we can't iterate effectively. In-office staff helps to make feedback fast, but it's quite possible to have fast feedback in a distributed environment (I used to work for a Japanese corporation, so I can tell you about "feedback lag"). It's just that we then need some kind of process to afford and regulate that feedback loop. I think that the process of software development is fundamentally broken, and that the industry is still thrashing around, trying out all sorts of "silver bullets" (See Brooks, Fred). I also believe that overbuilt process is an enormous issue. I call it "Concrete Galoshes" (https://medium.com/chrismarshallny/concrete-galoshes-a5798a55af2a https://medium.com/chrismarshallny/concrete-galoshes-a5798a5...), and it affects new-fangled, agile shops, as much as it does old-fashioned waterfalliers. Unfortunately, if we want to reduce "tribal knowledge," and treat our engineers like interchangeable LEGO blocks, then we need a pretty heavy process. It's still a heavy process, even if we call it "agile." "Tribal knowledge" is a bad term in the software development industry, but it is the most effective way to have a light-touch process. It also requires treating engineers well (not just paying them well), so they stay around. I'm not sure that foozball tables and on-site beer are doing the trick, as the average stay at a corporation seems to be less than 2 years. I do not have the answer. If I did, I would own a private jet for every day of the week. I have my own personal process that works quite well for me, but I don't think it scales particularly well to others.
- monksy 6y ago
  It's amazing how we have, and used to have, all this great knowledge about process and methodology. (McConnell and Brooks) but yet the industry would rather throw their hands up and micromanage projects into the ground. (Agile). The books that are published feel like they're targeting entry developers and it's a lot of stuff you'd learn on the job. It feels like we're over-promoting way too quickly and demanding delivery over experience or quality. Interviews: You have developers that refused to learn this skill and they just skim a few leetcode problems and expect the interviewee to solve it in 15 minutes. Best practices: What happened to developing standards and demanding/expecting tests (and their appropriate categories unit, integeration, smoke, feature/functional, etc)
contravariant 6y ago
With a precise and clear enough description you could throw it at a python interpreter and run it. Though things could get fun if AI can enable more flexible declarative programming.
- matz1 6y ago
  if you could throw it at a python interpreter and run it then that wouldn't be english.
  - PeterisP 6y ago
    I'd argue that "precise and clear enough description" means using a subset of English that's more complicated and much, much more verbose than python. Have you read laws? That is the style of language that tries to make a "precise and clear enough description" in English, but it does not go far enough, it's still not sufficiently precise to be applied directly, you would have to use something like 'super-legalese' for that. So even if you had a system that could accept English, nobody would want to use that because it's difficult to express precise and clear enough descriptions in English, and easier to do so in Python or some other programming language; and in any case, the difficult part of programming is thinking up the precise and clear enough descriptions. This comes up in writing specifications for outsourced programmers. Writing a specification in English that's clear and actually precise enough takes more work than just writing the code directly - since you have to do all the hard part anyway, and then have to express it in a language that's poorly suited to do so. And a reasonable specification is very much not precise enough to be executed, it relies on the programmer putting in a lot of the details based on their domain understanding and common sense, leading to very different implementations as that domain understanding and common sense varies.
    - matz1 6y ago
      >So even if you had a system that could accept English, nobody would want to use that because it's difficult to express precise and clear enough descriptions in English Yes but in the future this can be solved by the smarter AI. Essentially that what a lot of developer do, they turn other people idea or english description into working code.
skocznymroczny 6y ago
We had a similar technology for a long time. You give the computer instructions and explanation in a language, as clear as detailed as possible and you get back machine code. It's called a compiler.
- matz1 6y ago
  >You give the computer instructions and explanation in a language, as clear as detailed as possible and you get back machine code I specifically referring to English though, not computer language.

by matz1 6y ago

akmarinov 6y ago

Well you can replace all developers by that logic not just offshore ones.

ChrisMarshallNY 6y ago

The issues we have with any code development; whether through on-site employees, offsite employees, contract shops, or integrated contractors, would also apply to AI. Those of us that have been doing it a while, know that the single biggest issue in any commercial code project is bad input to the process; otherwise known as Requirements. No one knows what they want, or, even worse, they know what they want, and what they want, sucks. Steve McConnell wrote about how projects mess up, and how much the damage can propagate throughout a project lifecycle; with bad requirements being the nightmare scenario. This was about a quarter century ago. It is not new (https://stevemcconnell.com/articles/software-quality-at-top-speed/ https://stevemcconnell.com/articles/software-quality-at-top-...). The best requirements for a software project is code. Even an AI will need extremely high-quality, detailed, and well-considered requirements that are likely to require their own language (so AI requirement-generation will look a heck of a lot like "coding"). What AI gives us, is (maybe) speed between requirements and executable, so, theoretically, we could have a really high-power, effective iterative process, where bad input results in bad output, and we see that quickly, then refine the input; much like we already do with code, and run the build again, to see how that results in executable. I learned development back in the "big iron" days, where CPU time was the most expensive part of the process, and we were required to debug our code in the design phase. If we borked during our slice, we were penalized. Nowadays, I tend to just write some junky "strawman" code, fire up the debugger, and step through until it breaks. Working with separate contractors, whether domestic or offshore, needs really good requirements, and some kind of fast feedback and a flexible, iterative lifecycle process; which is frog-fur rare. If we don't have a fast feedback cycle, then we can't iterate effectively. In-office staff helps to make feedback fast, but it's quite possible to have fast feedback in a distributed environment (I used to work for a Japanese corporation, so I can tell you about "feedback lag"). It's just that we then need some kind of process to afford and regulate that feedback loop. I think that the process of software development is fundamentally broken, and that the industry is still thrashing around, trying out all sorts of "silver bullets" (See Brooks, Fred). I also believe that overbuilt process is an enormous issue. I call it "Concrete Galoshes" (https://medium.com/chrismarshallny/concrete-galoshes-a5798a55af2a https://medium.com/chrismarshallny/concrete-galoshes-a5798a5...), and it affects new-fangled, agile shops, as much as it does old-fashioned waterfalliers. Unfortunately, if we want to reduce "tribal knowledge," and treat our engineers like interchangeable LEGO blocks, then we need a pretty heavy process. It's still a heavy process, even if we call it "agile." "Tribal knowledge" is a bad term in the software development industry, but it is the most effective way to have a light-touch process. It also requires treating engineers well (not just paying them well), so they stay around. I'm not sure that foozball tables and on-site beer are doing the trick, as the average stay at a corporation seems to be less than 2 years. I do not have the answer. If I did, I would own a private jet for every day of the week. I have my own personal process that works quite well for me, but I don't think it scales particularly well to others.

monksy 6y ago
It's amazing how we have, and used to have, all this great knowledge about process and methodology. (McConnell and Brooks) but yet the industry would rather throw their hands up and micromanage projects into the ground. (Agile). The books that are published feel like they're targeting entry developers and it's a lot of stuff you'd learn on the job. It feels like we're over-promoting way too quickly and demanding delivery over experience or quality. Interviews: You have developers that refused to learn this skill and they just skim a few leetcode problems and expect the interviewee to solve it in 15 minutes. Best practices: What happened to developing standards and demanding/expecting tests (and their appropriate categories unit, integeration, smoke, feature/functional, etc)

contravariant 6y ago

With a precise and clear enough description you could throw it at a python interpreter and run it. Though things could get fun if AI can enable more flexible declarative programming.

matz1 6y ago
if you could throw it at a python interpreter and run it then that wouldn't be english.
- PeterisP 6y ago
  I'd argue that "precise and clear enough description" means using a subset of English that's more complicated and much, much more verbose than python. Have you read laws? That is the style of language that tries to make a "precise and clear enough description" in English, but it does not go far enough, it's still not sufficiently precise to be applied directly, you would have to use something like 'super-legalese' for that. So even if you had a system that could accept English, nobody would want to use that because it's difficult to express precise and clear enough descriptions in English, and easier to do so in Python or some other programming language; and in any case, the difficult part of programming is thinking up the precise and clear enough descriptions. This comes up in writing specifications for outsourced programmers. Writing a specification in English that's clear and actually precise enough takes more work than just writing the code directly - since you have to do all the hard part anyway, and then have to express it in a language that's poorly suited to do so. And a reasonable specification is very much not precise enough to be executed, it relies on the programmer putting in a lot of the details based on their domain understanding and common sense, leading to very different implementations as that domain understanding and common sense varies.
  - matz1 6y ago
    >So even if you had a system that could accept English, nobody would want to use that because it's difficult to express precise and clear enough descriptions in English Yes but in the future this can be solved by the smarter AI. Essentially that what a lot of developer do, they turn other people idea or english description into working code.

skocznymroczny 6y ago

We had a similar technology for a long time. You give the computer instructions and explanation in a language, as clear as detailed as possible and you get back machine code. It's called a compiler.

matz1 6y ago
>You give the computer instructions and explanation in a language, as clear as detailed as possible and you get back machine code I specifically referring to English though, not computer language.