Slashdot Mirror
Code is Too Hard To Think About (theatlantic.com)
From a longform piece on The Atlantic: What made programming so difficult was that it required you to think like a computer. The strangeness of it was in some sense more vivid in the early days of computing, when code took the form of literal ones and zeros. Anyone looking over a programmer's shoulder as they pored over line after line like "100001010011" and "000010011110" would have seen just how alienated the programmer was from the actual problems they were trying to solve; it would have been impossible to tell whether they were trying to calculate artillery trajectories or simulate a game of tic-tac-toe. The introduction of programming languages like Fortran and C, which resemble English, and tools, known as "integrated development environments," or IDEs, that help correct simple mistakes (like Microsoft Word's grammar checker but for code), obscured, though did little to actually change, this basic alienation -- the fact that the programmer didn't work on a problem directly, but rather spent their days writing out instructions for a machine. "The problem is that software engineers don't understand the problem they're trying to solve, and don't care to," says Leveson, the MIT software-safety expert. The reason is that they're too wrapped up in getting their code to work. "Software engineers like to provide all kinds of tools and stuff for coding errors," she says, referring to IDEs. "The serious problems that have happened with software have to do with requirements, not coding errors." When you're writing code that controls a car's throttle, for instance, what's important is the rules about when and how and by how much to open it. But these systems have become so complicated that hardly anyone can keep them straight in their head. "There's 100 million lines of code in cars now," Leveson says. "You just cannot anticipate all these things."
It's lousy requirements, fickle customers, bad environments and tools. The code is the easy part.
love is just extroverted narcissism
"There's 100 million lines of code in cars now"
No, there isn't. So this guy, criticizing, is making shit up in order to do it.
Whats he selling?
"His name was James Damore."
Too hard to think about is good because it means job security for those who can.
If you think "code is hard", then maybe SlashDot isn't the right site for you.
The problem is that software engineers don't understand the problem they're trying to solve, and don't care to,
Then those software engineers are idiots. Standard for my projects and my teams is, when starting a project, before ever writing a line of code, we try to understand exactly what it is we're trying to accomplish. Work with customers to get requirements, prod the customers to figure out the details they didn't think about and figuring out the best compromises when we have conflicting requirements. Only after we've got a pretty good idea what we're trying to do will we actually start coding.
I wanted to upvote a comment. Can't easily see how to do it.
Damping absorbs vibrations. Dampening is caused by moisture.
At least not too hard for everybody. But the simple plain fact is that thinking about code above a certain minimal complexity requires special talent. Tools, languages, coding-styles, etc. make no real difference.Those that do not have it ( probably something like 95% of all people) should stay away from professional coding. Incidentally, the same applies to mathematical thinking and reasoning, for example. Nothing surprising here, just too many people writing code that do not have what it takes.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Any experienced programmer will know very well that abstraction does not always make better solutions. The sad truth is that complex problems usually require complex solutions.
To me, it's a machine or tool. Like a hammer. Use a hammer this way and it does something. Use it another way and end up with bruised fingers. It all seemed so simple and transparent and obvious . I just groked it, long before the concept of grok, and I could not for the life of me understand why other people couldn't get it.
What intensified that was the need to read and memorize about a zillion IBM and FORTRAN manuals. That also appealed to my obsessive ADHD side, long before the concept of ADHD. Add the extra ego brownie points when I could describe some obscure feature or function call to the instructor or one of the advanced calculus students and it was a match made in heaven.
The Russians have won. They have made the world a cesspool of distrust, greed, fear and hate.
"The problem is that software engineers don't understand the problem they're trying to solve, and don't care to,..."
I think they do understand the problem and that's why things generally work, or don't they? I think they do work on the whole.
The reason is that they're too wrapped up in getting their code to work.
To this, I must rephrase:
"The reason is that they're too wrapped up in getting their code to work, as they should..."
Before a single line of code hits the IDE, you plan out what you're trying to solve, the problems you have to deal with, and how the logic will have to act. Coding happens after the "hard" work has been done, once you have a good idea of what has to be done and how to do it.
If anyone thinks that a true software engineer just sits down, starts slamming on some keys and then says "Oh well, I wrote code, let's see how the throttle handles it", then they don't understand software development or software engineering.
Rust will solve every problem known to mankind. In Rust, you don't even need to think about the problem your code should solve. The Rust toolchain will do that automatically for you. When using Rust, bugs are a thing of the past -- they are simply impossible.
The problem is that software engineers don't understand the problem they're trying to solve, and don't care to," says Leveson,
They are teaching you, the software engineer, enough mathematics during the CS studies at the university with at least 50% more credits recommended compared a typical Masters level engineering degree, enabling you to understand the requirements the engineers, mathematicians, scientists and other subject matter experts are giving you after some time studying them. Wait, I think I said something funny there in the context of this discussion..
Programmer-Analyst/System-Analyst/Business-Analyst - it's part of the job (understanding the overall problem & flow of logic) etc. - I am GLAD then that I started my career on that track professionally in 1994 (programmer-analyst) since it demands you "understand the problem" after doing what you stated (speaking to customers & creating a spec etc.).
* I don't understand WHY anyone would approach systems design (especially LARGE ones) any other way... it also prevents "feature-creep" also (customers can't go & just 'change' spec on-the-fly once 'written in stone' unless everyone agrees & timetables can change with features added etc. - et al too).
APK
P.S.=> You're correct & I spent decades doing it that way & never had a 'failed' project (40++ "enterprise-class" systems that spanned millions of lines each to my, & teams I worked with also's, credit in the timeframe noted above)... apk
This has to be the most obvious "news" story I've ever seen on /.
Why does this even have to be said? Its obvious.
Real ones by definition understand the problems they are solving.
Of course in the US where any self-taught moron can call themselves an "engineer" that may not always apply.
Noody, at any point, has stared at a field of 1s and 0s to code. The rest of the summary is just as wrong. Why would anyone post this bilge to /. of all places, unless it's an attempt to troll?
I write code for the gov and the hard part is when the bug is in the law. The bug might have not been obvious to lawmakers, but when I write my if-else it becomes dead obvious. It is hard because
A) I know what I'm doing is wrong, but I have to do it, because it is written into the law
B) There is no bug tracker where I can submit bugs in the law.
I've been doing this for years and in almost all cases contractors have no idea what the business is doing or what the code is supposed to do. Of course people say that they don't need to know details anymore, just pick up a story from the backlog and all of the stuff can stand by itself.
I used to hate the Accentures of the world but now my anger is on the Agile mafia, if a project fails it's not Agile's fault, you just didn't do it right.
...lets go shopping!
Should be the real title. Eg, POTUS can easily start a nuclear war, here are the directions: https://www.bloomberg.com/poli...
Visual programming is the "answer"? Every decade some non-programmer discovers visual programming and says we are all going to be creating programs by dragging blocks around. No, I didn't bother to RTFA.
We haven't solved the hard AI problems necessary to make computers think like us, so we have to think like computers in order to program them, and we're not good at it. This is news?
Machine language is hard? No, it's not. What it is is tedious. Assembly is not much better, although it was wonderful (at the time) it was so much more human readable. It's actually been an interesting trip, starting out with honest to god physical switches, then machine code, then assembly, then fortran, c, java. Probably be a great way to teach kids about abstraction... If there's a point to this post, I'm not seeing it.
Often the same thing is done many different ways.
For example, every project usually has some kind of threading code. Everyone does it slightly differently.
Duplication is wasteful but as long as people disagree about how to acomplish task X it will happen. Furthermore, even without disagreement, people will duplicate functionality for copyright reasons.
The vast majority of oversized codebases have oversized frameworks. Frameworks make programminb easier in the short term, but can cause headaches in the long term.
like programmers wrote programs, the first woodpecker that came along would destroy civilization.
Sorry that's the only (hopefully funny) comment I could come up to contribute (and I didn't even come up with it, I read it somewhere in pre-Internet time!).
When you're writing code that controls a car's throttle, for instance, what's important is the rules about when and how and by how much to open it. But these systems have become so complicated that hardly anyone can keep them straight in their head.
This bullshit argument is unarguably true, but it can be applied to anything, and means absolutely nothing.
There is this persistent myth of the "lone programmer" or "lone inventor", but that is not how things work in the real world.
Even a moron knows that nobody in this blue marble can be a master of every possible field, and very few people can even master ONE specific field. In the real world - where shit gets done, not some sitcom fantasy - you work in teams, so that each member can bring their skillset, experience and opinion to the table, and so that together they can come up with a superior solution.
The design is separated from the implementation, and done in advance. Things aren't done "as you go". The methodology doesn't change midway. Everything is planned, and THEN the plan is executed.
This is how airplanes stay in the air, why you can carry a computer in your wrist, and why I can post this shit on the internet. There are thousands of people working on this shit. Yeah, sometimes they break, but we learn from that and we fix them and make them better.
If things were as bad as these bullshit articles try to make them, we would still be sitting in caves eating shit because "Agriculture has become so complicated that hardly anyone can keep it straight in their head.".
It is an insult to our collective intelligence and human achievement.
Developers should avoid writing code by hand and instead write abstract high-level programs that generate code. This rule aims to reduce human errors and save time.
Which is why we've been abstracting away the hard bits for a while now. We're not manually flipping in digits. We made punch cards, automated punch cards, compilers, and higher level languages.
I couldn't imagine doing non-linear control algorithms with C or assembly. Did simple PIDs in college, understand how to do it and just let Simulink write the DO-178C and MISRA 2012 code for me. It's already certified for critical code.
It's also easy to build a plant model to unit test against and add in SIL/MIL/HIL level testing. I let Windriver and other compilers handle the assembly generation. Again, they're already tested and certified.
"100001010011" and "000010011110"
Great guys.
Software is still in that era. Each machine built then was made from the scratch, with custom built parts. There were no standard off the shelf components then. We still don't have a standard reliable gui that can be assumed to be supplied by the OS in linux. Windows guarantees a mouse/screen but it can't even give multiple customizable desktops in 2017 Windows 10.
If I am designing an electric motor, I don't have to worry about the anchoring bolts. I know the power and torque and weight of what I am shooting for. I will simply pick from well tested components library a set of four, six or eight bolts with known tensile strength, corrosion resistance, temperature profiles, cost and provide for holes large enough for the anchor bolts. If I am designing the controller for the same damned electric motor, every interaction the motor has with the micro processor that controls it is custom made. Several device control muPs each with its own protocol for data, feedback and error handling.... If I am designing a mortgage consolidation program for the asset management of a bank, every data feed I get, every data output, feedback, and error handling is custom built. That is why software reliability is poor, security holes are ill understood and development is insanely complex.
Having said that, we have made great strides in standardization. File IO within a system, of https requests across the network is getting standardized. XML is helping a lot. Entrenched players deliberately mess up interoperability with ulterior motives. But as the end users become more and more aware of switching costs and vendor locks, eventually these things will dry up and interopera bility will improve.
Well tested, well understood components are the key to building large, complex but reliable machines. We are getting there. Serious computation is a mere 60 year old technology. Hardly two and a half human generations, coping up with 45 generations of computational technology evolution. It will take a couple of human generations before we have senior managers who grew up with technology who would not fall easily for the sales tricks and demand real tested true interoperability and well tested well understood components.
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
I read the article on Friday and remember how it was trying to propose some kind of other way to visualize the behavior of code, and thought it was pretty cool idea. Then I remembered the first anecdote in the article about how a 911 calling system crashed because the unique ID's hit their max value. If one were to create a visualization of the system, it would still show "green" for when the system hit their max value for unique ID's. So I don't think that the solutions proposed fixes the problems at all.
I also didn't like how it bemoaned how programmers will start programming a little bit before working out all of the architectural details. That's probably true for a brand new system, but for adding a new feature, I find it much more beneficial to poke around a little bit to see what's possible with the pieces which are already in place. It's a very helpful way to get my mind to think about parts of the code with which I am unfamiliar with.
I love thinking about code.
Since the invention of hexadecimal. It was such a pain, working with all those 1's and 0's on your screen. Lots of cutting and pasting to get anything done. People looking over your shoulder at your screen couldn't tell what you were doing, though, so browsing for porn at work was easier.
Have you read my blog lately?
I write code for the gov and the hard part is when the bug is in the law. The bug might have not been obvious to lawmakers, but when I write my if-else it becomes dead obvious. It is hard because I know what I'm doing is wrong, but I have to do it, because it is written into the law.
may be summarily dismissed as newsstand magazine click-bait.
The gist article may have been relevant in 1988, or 1978, or 2008, or any particular decade since the 1940s. Only the details need to be changed to reflect the latest cherry-picked failures. One does not predict a Zombie Apocalypse because of a few cases of leprosy.
Functionally sound and working software pervades nearly every aspect of our lives. Practically every aspect of nearly all manufactured product we consume is designed/made/shipped/distributed and delivered utilizing software. That we continue to have occasional failures is simply a sign that we continue to push the boundaries of what we attempt to do with it. No one was promised a utopia. For that, we must wait for the AI Overlord. (And I, for one, look forward to welcoming.)
The author's view is that if you can't look over someone's shoulder and understand what they're working on, then there methods must be broken: "it would have been impossible to tell whether they were trying to calculate artillery trajectories or simulate a game of tic-tac-toe". Let's ignore that the same goes for any hardware development. Likewise, we can't distinguish between a man working a math problem on a plane, and a man carrying a bomb on a plane, so math must be broken, too?
IDEs ... did little to actually change, this basic alienation
As far as I can tell, although they do make the day-to-day job of programming computers much easier (and yes, I did start coding before there were any IDEs), they've made things worse in terms of expectations. Even as getting programs correct is getting harder, the people who don't do it are looking at the tooling and the support, and the how simple the very basic stuff is, and thinking, "this looks easy, therefore it must be easy, therefore if this guy can't get it done in a couple of hours, the only possible explanation is that he's incompetent."
Proud neuron in the Slashdot hivemind since 2002.
Comment removed based on user account deletion
C.D. Reimer is a renowned Slashdot collaborator, as he puts it himself; "Because of the quality of my posts and my article submissions, I'm a highly rated commentator and moderator."
But does anybody ever wondered what "C.D." stands for? Well, it stands for Creimy Dumpty of course!
Creimy Dumpty sat on the wall,
Creimy Dumpty had a great fall.
All the king's horses
And all the king's men
Couldn't put Creimy Dumpty
Together again.
Creimy's siblings video and theme song, very realistic, especially the pants, just like Creimy's:
https://www.youtube.com/watch?...
Creimy's real pictures:
Before the sex change:
https://ibb.co/cc7Ddw
After the sex change:
https://ibb.co/gVad65
Creimy's "enterprise-level" chair, he talks about it all the time on slashdot:
http://www.keynamics.com/image...
Creimy's head, while his supervisor was talking to him, not with him, since it is impossible to do with Creimy:
https://school.discoveryeducat...
Creimy acting in educational resource document, he actually confirmed himself on Slashdot that he was handled by Special Education for the Santa Clara County Office of Education! He is really a king Dumpty!:
http://www.sccoe.org/depts/stu...
You shouldn't be in the field of software development. Whoever uttered that statement should be fired from any programming related job.
It does require a special sort of insight (eg. being able to keep track of state and thinking much more abstractly about computers than what you're used to) which can be both acquired or natural but is only improved by practice but it's by no means impossible to think about code and what it will end up doing. In most cases, programmers have thought about ways the program can fail (eg. buffer overflows) and either think it's no big deal (it will never get connected to the Internet) or have to give up finding solutions for it due to lack of time or funding.
Custom electronics and digital signage for your business: www.evcircuits.com
There you are posting crap again you disgusting fat sexist tube of lard, Christopher Dale Reimer!
You can be sure I will be watching this fake account too. I know this is you because you told me you were working on your freepass 11 file server and you are so dumb that you can't even masquerade yourself properly.
Now, I told you I was out of meds last week and you didn't even care to contact me you lazy fucker.
How many time do I have to express the emergency of the situation??????
The python click script you wrote for my pheromone revenue stream web site suddenly stopped to work!!!!!!
You fucking incompetent python script writer!!!
When it works, I get 4000+ clicks a day on my pheromone revenue stream web site but only 5 or 6 without it!!!!
Now, it seems like you dont care and that you have abandoned me you heartless fucking pig!
Bonus:
Here is a story that creimer told me when convincing me what a hard life he had:
The tree was him and the tree knot was his butt hole!
So, his uncle packed his fat ass with lard and with his cock! Not that it makes much of a difference but anyway, there it is!
Signed:
The girl that used to love you and now hates you, burn in hell where you belong you sexist pig!
You're forgetting that much of the environment your code has to work in consists of more code. And while we often do out of habit, we really cannot ignore that forever. There's also that debugging is said to be twice as hard as writing it in the first place. So if you're being at your maximum cleverest while writing, you end up with a problem debugging that code. "Coders" tend to be in love with their cleverity. And the people who're just writing code because it's a job typically aren't that clever in the first place. That's all before the corner case coverage incompleteness theorem and all that what follows from there.
So yeah, the root of the problem is complexity, too much of it. Not that TFA has a sensible answer. In fact, while they correctly identify some problems, their solutions are too clever by half, also. Buncha ironic hipsters.
But anyway, this is a deep and thorny problem that so far we're only compounding. We certainly haven't seen the last of it yet.
The fundamental of Software Engineering is Requirements Capture - in order to understand the task at hand. Obviously if your requirements are wrong then the code will be crap. That's not a problem peculiar to Software Engineering though - in any profession you will find idiots who have risen to positions above their abilities - like in journalism.
Exactly! We, at Special Education for the Santa Clara County Office of Education, couldn't agree more with you!
For the valuable /. users that might already have read the following, please note that there is an important update.
IMPORTANT UPDATE:
Special Education for the Santa Clara County Office of Education has invested money to buy Chris a new chair:
http://www.keynamics.com/image...
Information about Christopher Dale Reimer and autistic people:
Autistic people have obsessions about things normal people don't care. For example, one of our autistic patient went haywire when he realized that there was a penny missing in his pocket change.
To calm him down, one of our educator pretended to have found it on the floor and gave a penny to him.
The autistic patient condition went even worse because he realized it wasn't the same penny!
Chris has an obsession with budgeting every penny. He doesn't understand that most people do not budget to the penny and have a flexible amount they allow for miscellaneous items.
I am Nancy Guerrero and I am Director of Special Education for the Santa Clara County Office of Education. We use Chris' (a.k.a. creimer,cdreimer) picture in our document because he is the hardest case we have ever had to handle:
http://www.sccoe.org/depts/stu...
Our artists were inspired by the low carb diet that Christopher follows scrupulously for the small lunch box and by the picture linked below for the rest. I am sure that you will notice the similarities such as the bump on the side of his chest and more:
https://ibb.co/gVad65
Please be easy on Christopher although, I am aware that some of our staff handling Chris post joke comments here and obvoiusly, the Santa Clara County Office of Education disapprove that behavior vehemently:
https://school.discoveryeducat...
But it isn't Chris' fault if he is the way he is. We do the best we can do with him and he is partially integrated into society. We try to cure his abnormal need for attention but he is kind of stubborn and won't listen to anybody.
Thank You dear users,
-Nancy Guerrero
http://vpri.org/html/work/ifnct.htm
Hey Creimy Dumpty Reimer!
About modular programming, in your siblings video, they seem modular enough for me. What do you think?
In about 100 years, the codebase of most simple appliances will start to resemble the size of the entire genetic material for a small insect. While no human can possibly think about the entire DNA sequence for even a simple creature, we start to think of which alleles can be switched "on" or "off" and cut and paste sections using CRISPR from related codebases. This is the ultimate in "script kiddie" hacking, but that's where we are with complex code like genetics, and that's where we will be with manmade code as well once it reaches hundreds of billions of lines of code.
You might think, "no human can analyze or write that much code!!!", and you would be correct. However, we will start using more and more automated tools. We will have programming interfaces where you can just talk to it and roughly describe what you want and it will spit out a portfolio of possible solutions like a commissioned artist might at their patron's behest. "I want my self-driving car to prioritize skipping potholes over saving running over kittens!". And while those solutions will look polished and smooth, it will be anything but in the underlying code and employ not just hideously complex code but hideously complex data like random forests or gradient-boosted regression trees with tens of thousands of trees and millions of leaf nodes for the simplest of classification questions, "is it a pothole or a kitten?".
It will be akin to those Frontpage and WYSIWYG web editors that spew out hundreds of thousands of lines of HTML code for the simplest of web pages. We will move to an FDA-like deployment process, where no one reviews the code but we just test it in simulation, and then in real life with mice and then monkeys and then humans. It will take 5-7 years to release code because no one will understand what it does or its long-term side-effects like modern pharmaceuticals. The QA-process will just involve large-scale clinical trials and zero code review.
Why does an article like this get any attention? Why is it that people think "code" should be accessible to the layman? You never hear people saying "we need to make building bridges easier" or "rockets need to be more diverse". Why should programming be treated any differently to other technical fields? People are not all the same and have different skills and capabilities. Constantly aiming low like this will be reflected in the outcomes.
After attempting to read through the 100 million lines of article I gave up around the point where they started talking about writing flowcharts to represent code. But they did mention this was connected to a Kickstarter project called Light Table (which apparently somehow inspired Apple's Swift??). So I watched the kickstarter video ( https://www.youtube.com/watch?... ) and the kickstarter page ( https://www.kickstarter.com/pr... ) and I still don't have a clue what it is, what is new about it, or how it makes programming unnecessary. Are we supposed to be spending writing tools that write programs instead of writing programs? Aren't we already doing that?
Maybe someone with an entire day of their time can read the article and decipher what it is they are talking about.
It sounds to me more like they are making code harder than it actually is.
Anyone looking over a programmer's shoulder as they pored over line after line like "100001010011" and "000010011110" would have seen just how alienated the programmer was from the actual problems they were trying to solve; it would have been impossible to tell whether they were trying to calculate artillery trajectories or simulate a game of tic-tac-toe.
All I see it blonde, brunette, redhead...
"When information is power, privacy is freedom" - Jah-Wren Ryel
100M lines of code is a made up number used to sell extended car warranties. I wish people would stop quoting it.
And math forces you to think like a mathematian. Great chess players think differently than beginners. And experienced programmers have a deep understanding of how a computer operates.
Computer Science is the study of taking big problems and breaking them down into pieces that can easily be translated for a computer.
"Why do we pay IT, everything is working without their help." "Why do we pay IT, nothing is working". Sub in developers for IT. YMMV.
Fat, drunk, and stupid is no way to go through life, son.
You can write bug-free code. You can unit-test your code until hell freezes over. But then, you have to integrate your code into a larger application,
a lot of which has been written by others. In an application that runs to, perhaps, hundreds of modules and hundreds of thousand or even millions of
lines of code, how do you effectively test the changes you made to your one module? We all know: you can't. So I don't see the problem as one
of coding so much as I do one of integration and testing. And this doesn't even address the problems of design and specification, for which there
never seems to be enough time or money or energy. You know: code yesterday, deliver today, think tomorrow.
Yes programming is difficult. Being creative logically, understanding the big picture and where the project is going, being able to get lost for hours in your head and staying focused as your tracking variables and flowing data ya, it’s hard. It’s also exactly why this silly notion that “everyone needs to learn to code” is simply asinine and coding boot camps are a lie. Different people have different skills
I wonder if the existing method of writing software isn't just running into the limits of general human cognition.
We can conceptualize complex systems or tasks, but to make software that does them requires a very low level of understanding of how it will work and gluing together many low-level functions to get to the finished complex system.
Fixing a system like this when it doesn't work as expected requires an encyclopedic level of knowledge about all of the low level pieces as well as the larger picture of the entire system.
I'm sure there are people who are better at this than others, but maybe we're just reaching the point where the systems are so large and there are so many of them that we lack the access to the human resources or methods of automation capable of managing them. Ordinary, even conventionally above-average people, simply aren't capable of effectively managing the complexity involved.
The problem is that software engineers don't understand the problem they're trying to solve, and don't care to
I thought the article had some issues but this one really made me mad... I have worked with scores of professional developers who indeed spent a LOT of effort trying to understand the domain (problem) we were writing software for, most of them would push back on requirements that made no sense for "solving the problem" when we knew it would hinder (or at least not help) users.
Also on a sidenote, the TLA+ stuff sounded interesting but if you go find the webpages that describe that, they are pretty old and have not been touched in years... it sure seems like yet another flash in the pan magic bullet for creating software. Has anyone successfully used TLA+ on projects in recent times?
I don't think developers are inherently against mathematical models to help define systems, it's just that invariably the models we have all seen applied tend to fall down trying to describe the complexities of real software. I mean, remember the UML craze (not mentioned in the article), which had significant efforts trying to build software from a model... but the major issue (at least at a company I worked for) was that the final code was way to complex to be represented in the model. The model became just another kind of requirement that after some time failed to track with the results.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
"The problem is that software engineers don't understand the problem they're trying to solve, and don't care to"
Some of us understand that the purpose of software development isn't mental masturbation, but actual problem solving. Writing the actual code is usually the easiest part, unless you're working with a very constrained runtime environment. If you think the hard part is learning a programming language and using it to write instructions for a computer, you shouldn't work in software development.
I read the article on Friday and remember how it was trying to propose some kind of other way to visualize the behavior of code, and thought it was pretty cool idea. Then I remembered the first anecdote in the article about how a 911 calling system crashed because the unique ID's hit their max value. If one were to create a visualization of the system, it would still show "green" for when the system hit their max value for unique ID's. So I don't think that the solutions proposed fixes the problems at all.
I also read it Friday, and also thought that idea was interesting - as mentioned in the article, Swift Playgrounds has something a bit like that, because after running a session you can see some values charted over the lifetime.
That to me is the key, not that you can simply visualize the software but that you see it over time - so in that case it wouldn't be all green, you'd see the software over the lifespan of projected use, and at some point see red when the ID boundary was exceeded... at least that's how I see such a visualization factoring in time.
I still think it's an interesting approach to try and model and visualize software behavior over time, perhaps we'll see some more analysis tools around that, which hardly anyone would use just like all of the other code analysis tools we have today. :-)
"There is more worth loving than we have strength to love." - Brian Jay Stanley
I've seen roughly an even mix of both. Bleep happens.
As far as car control software, back in the days, you had to keep your hardware controls fairly simple for manufacturing costs, repair-ability, and to have tolerances for wear and manufacturing defects.
Software removed many of these constraints and so companies have stretched software to its limits in order to be competitive in terms of performance and fuel efficiency. It does NOT have to be complex, but you likely will be sacrificing metrics to gain simplicity. Perhaps much if it can be reworked to be simpler, but that requires a lot of software and hardware engineering effort, and may delay car models. At least the current code is road-tested.
In short, there's no free lunch. Now that more functionality of an automobile has moved to software, companies are flummoxed because they are used to focusing on hardware. Their cheese moved:
Welcome to the Change Club. The first rule of the Change Club is that the first rule will change.
Table-ized A.I.
Creimer, please stop! As a mod, I am getting desperate! You've had too much of an educational experience from trolling your trolls!
Either coding is too hard for the average person, or every person can be trained to be a good coder. You can't have it both ways. And yet, I see articles declaring both, all the time, although lately it's been mostly the latter. Of course in reality, the former are just selling their own magical coding tool(s) and/or process(es), and the latter are trying to flood the job market so they don't have to pay so much for coders (and they get what they pay for).
Too many developers solve the problem at a low level programming domain language and constructs. They need to learn to solve the problem. Decompose he problem in natural language with natural language abstractions. Test Driven development, particularly using BDD for requirements and Unit Testing is a very effective approach that allows the implementation to be varied.
As usual, you thought wrong, creimer. The purpose of modular programming is to provide separation of concerns - this helps with code reusability, and allows sections of code to be developed and updated independently.
Separation of concerns actually makes them LESS likely to be interchangeable cogs, as it allows for MULTIPLE developers to implement multiple modules that work in concert. Someone can certainly come up to speed on a module they're not familiar with, but the expert who implemented a given module is certainly going to be faster for a good while. What it allows is faster delivery of code, as multiple modules can be developed in parallel.
What a fucking hoot!
"As for “cdreimer,” he’s too busy to post more than one or two comments per day, doesn’t care to argue, and has no use for the trolls."
You mean, cdreimer's karma has been nuked to oblivion as well, so you can ONLY post one or two comments per day on that account.
And ILoveFatCashew's karma has also been nuked to oblivion, so you can ONLY post one or two comments per day on that account.
And your AC postings are limited to 10 per day, since you're probably too thick to understand how to proxy your traffic.
That means that you, creimer, are only able to shitpost 14 times a day. And given the drop from 30-40 comments per day on creimer, you must be experiencing some serious withdrawal!
"Management deleted the “creimer” account without any questions the day after Labor Day."
No, they renamed it to __aaclcg7560. Which means your entire shitposting history is available.
"The last six months of playing with the trolls on Slashdot has been an educational experience."
Yes, you learned that you're not a tough guy, your marketing schemes don't work, and that you're roundly disliked by many people on the internet. That kind of an education is tough to get for free, creimer!
Tight code that just does the job and no more can be done, but the writer, or the guy standing over him, has to *deeply* understand the problem, from the inside. Frankly, I think it's easier to teach the problem-expert programming than it is to teach a programmer the problem.
I worked for my local water/sewer utility, first as their IT head, then moved back to my first degree, engineering - but it was my IT that got me the engineering job, which was putting all our pipes, valves and other assets into a giant database that was also a "GIS", a map. We had already for years been switching to mapping with CAD, and had various macros and programs written within its development environment to make, say, placing a hydrant a single graphic operation.
So I got the one contract CAD programmer to greatly expand his "macros" into a comprehensive drafting system where the draftsman first drafted the underlying network, then all the pipes and other assets on top of that; the database understood the connected network and could trace it, analyse flow. The coding from the one former draftsman, who completely understood the drafting problem and the needs of his fellow-draftsman customers hired a couple of young programmers,made sure they were doing what his customers needed, and was done in a year for about $400,000. The IT department charged me much more than that to just supervise him and make sure he "met all corporate standards"!
Well, the IT and Mapping departments hated this software because it ran on top of the CAD package, Microstation. They insisted this was at end-of-life and all mapping was going to an "All-GIS" environment in the 800-lb gorilla of the GIS market, ESRI. They went over me (multiple levels) to get a huge project approved to replace my little $400K amateur effort from a mere engineer.
Long story short, that project peaked at 35 staff, went 3 years, spent $8 million and generated I can't imagine how much code because it was all with Microsoft programming tools that load in whole libraries every time you do anything.
At that point, management realized that it was another $2M-$3M to finish it, and testing showed it would offer no improvements and maybe some slowdowns.
They cancelled it.
My $400,000 CAD software is still there, not yet "end of life" at the age of 20, some 8 years after it was declared good-as-dead. Pity about the lost $8M. What I could have done with that! (There is, by the way, no sign of the whole CAD market vanishing in favour of GIS. Not surprising. Our IT and mapping people also picked Microsoft Silverlight as a winner.)
Whenever I read about giant code messes, I wonder if good, working software for the same problem would be less than a tenth that size. And it isn't bad programmers, it's bad project management. You should never put IT in charge, always their customer. This absolutely requires IT-savvy customers, and these horrors will go on until we get some.
So much bitterness, FakeFuck39. I guess creimer really did pwned your sorry ass.
Comment removed based on user account deletion
Comment removed based on user account deletion
There you are posting useless crap amazon affiliate spam from yet another fake account you disgusting fat sexist tube of lard, Christopher Dale Reimer!
You can be sure I will be watching this fake account too. I know this is you because you told me you were working on your freepass 11 file server and you are so dumb that you can't even masquerade yourself properly.
Now, I told you I was out of meds last week and you didn't even care to contact me you lazy fucker.
How many time do I have to express the emergency of the situation??????
The python click script you wrote for my pheromone revenue stream web site suddenly stopped to work!!!!!!
You fucking incompetent python script writer!!!
When it works, I get 4000+ clicks a day on my pheromone revenue stream web site but only 5 or 6 without it!!!!
Now, it seems like you dont care and that you have abandoned me you heartless fucking pig!
Bonus:
Here is a story that creimer told me when convincing me what a hard life he had:
The tree was him and the tree knot was his butt hole!
So, his uncle packed his fat ass with lard and with his cock! Not that it makes much of a difference but anyway, there it is!
Signed:
The girl that used to love you and now hates you, burn in hell where you belong you sexist pig!
C.D. Reimer is a high profile Slashdot collaborator, as he puts it himself; "Because of the quality of my posts and my article submissions, I'm a highly rated commentator and moderator."
But does anybody ever wondered what "C.D." stands for? Well, it stands for Creimy Dumpty of course!
Creimy Dumpty sat on the wall,
Creimy Dumpty had a great fall.
All the king's horses
And all the king's men
Couldn't put Creimy Dumpty
Together again.
Creimy's siblings video and theme song, very realistic, especially the pants, just like Creimy's:
https://www.youtube.com/watch?...
Creimy's real pictures:
Before the sex change:
https://ibb.co/cc7Ddw
After the sex change:
https://ibb.co/gVad65
Creimy's "enterprise-level" chair, he talks about it all the time on slashdot:
http://www.keynamics.com/image...
Creimy's head, while his supervisor was talking to him, not with him, since it is impossible to do with Creimy:
https://school.discoveryeducat...
Creimy acting in educational resource document, he actually confirmed himself on Slashdot that he was handled by Special Education for the Santa Clara County Office of Education! He is really a king Dumpty!:
http://www.sccoe.org/depts/stu...
We, at Special Education for the Santa Clara County Office of Education, couldn't agree more with you!
For the valuable /. users that might already have read the following, please note that there is an important update.
IMPORTANT UPDATE:
Special Education for the Santa Clara County Office of Education has invested money to buy Chris a new chair:
http://www.keynamics.com/image...
Information about Christopher Dale Reimer and autistic people:
Autistic people have obsessions about things normal people don't care. For example, one of our autistic patient went haywire when he realized that there was a penny missing in his pocket change.
To calm him down, one of our educator pretended to have found it on the floor and gave a penny to him.
The autistic patient condition went even worse because he realized it wasn't the same penny!
Chris has an obsession with budgeting every penny. He doesn't understand that most people do not budget to the penny and have a flexible amount they allow for miscellaneous items.
I am Nancy Guerrero and I am Director of Special Education for the Santa Clara County Office of Education. We use Chris' (a.k.a. creimer,cdreimer) picture in our document because he is the hardest case we have ever had to handle:
http://www.sccoe.org/depts/stu...
Our artists were inspired by the low carb diet that Christopher follows scrupulously for the small lunch box and by the picture linked below for the rest. I am sure that you will notice the similarities such as the bump on the side of his chest and more:
https://ibb.co/gVad65
Please be easy on Christopher although, I am aware that some of our staff handling Chris post joke comments here and obvoiusly, the Santa Clara County Office of Education disapprove that behavior vehemently:
https://school.discoveryeducat...
But it isn't Chris' fault if he is the way he is. We do the best we can do with him and he is partially integrated into society. We try to cure his abnormal need for attention but he is kind of stubborn and won't listen to anybody.
Thank You dear users,
-Nancy Guerrero
The 100 million lines of code argument is utter bullshit. Why? Because modern coding is modularized. How many lines can you keep track of? If every routine uses 10 subroutines, roughly speaking you only need to understand like 10 * log (100M) lines of code -- all the subroutine calls. That comes to, er, like 80, not 100M. Amazing what happens when you consider modern code practices.
The difficulty in coding is not so much in understanding millions of lines of code, but in communicating and understanding subroutine specifications correctly, and not missing error conditions that can occur in the real world.
Who do you think you are fooling, you disgusting fat sexist tube of lard, Christopher Dale Reimer!
You can be sure I will be watching this fake account too. I know this is you because you told me you were working on your freepass 11 file server and you are so dumb that you can't even masquerade yourself properly.
Now, I told you I was out of meds last week and you didn't even care to contact me you lazy fucker.
How many time do I have to express the emergency of the situation??????
The python click script you wrote for my pheromone revenue stream web site suddenly stopped to work!!!!!!
You fucking incompetent python script writer!!!
When it works, I get 4000+ clicks a day on my pheromone revenue stream web site but only 5 or 6 without it!!!!
Now, it seems like you dont care and that you have abandoned me you heartless fucking pig!
Bonus:
Here is a story that creimer told me when convincing me what a hard life he had:
The tree was him and the tree knot was his butt hole!
So, his uncle packed his fat ass with lard and with his cock! Not that it makes much of a difference but anyway, there it is!
Signed:
The girl that used to love you and now hates you, burn in hell where you belong you sexist pig!
C.D. Reimer is a renowned Slashdot collaborator, as he puts it himself; "Because of the quality of my posts and my article submissions, I'm a highly rated commentator and moderator."
But does anybody ever wondered what "C.D." stands for? Well, it stands for Creimy Dumpty of course!
Creimy Dumpty sat on the wall,
Creimy Dumpty had a great fall.
All the king's horses
And all the king's men
Couldn't put Creimy Dumpty
Together again.
Creimy's siblings video and theme song, very realistic, especially the pants, just like Creimy's:
https://www.youtube.com/watch?...
Creimy's real pictures:
Before the sex change:
https://ibb.co/cc7Ddw
After the sex change:
https://ibb.co/gVad65
Creimy's "enterprise-level" chair, he talks about it all the time on slashdot:
http://www.keynamics.com/image...
Creimy's head, while his supervisor was talking to him, not with him, since it is impossible to do with Creimy:
https://school.discoveryeducat...
Creimy acting in educational resource document, he actually confirmed himself on Slashdot that he was handled by Special Education for the Santa Clara County Office of Education! He is really a king Dumpty!:
http://www.sccoe.org/depts/stu...
In a manner of speaking, Microsoft Visual Basic 3-6 dealt head-on with creating applications and solutions rather than drowning in oceans of code. VB6 was not perfect nor was it designed for every solution.
For the average person and developer that needed to knock something out quickly it was\is amazing! Many still use VB6 today for that reason. Many found rewriting all their code just to be able to use .Net not the best ROI. That is another topic all together though.
The point: we need this era's true RAD solution to creating and knocking out applications rather than getting lost in code. Fun and visionary rather than being geared toward whatever the elite code gurus mandate everyone use.
You've posted twice today under ilovefatcashews...disproving nothing.
Regardless, don't you have better things to do that deal nonstop with a bunch of people who wish you would leave?
: You're the only one who's had to relinquish his account and lose all his karma... How are we the ones "pwned"???
Ask cdreimer, criemer, creinner, cremier, and FakeFuck39.
https://www.kickingthebitbucket.com/2017/06/20/the-confessions-of-slashdot-asshats/
Microsoft on Visual Studio, an IDE that costs $1,199 a year
Not that I think Visual Studio is helpful or useful or much more than bloat, but supposing that somebody did do the research and expend the effort to come up with something that actually WAS useful in taming software complexity, and it cost $1,199/year (or hell, even $199/year), the first question from management would be, "how do we get that for free?"
Proud neuron in the Slashdot hivemind since 2002.
No, the reason is their pointy-haired bosses, people like this Leveson, prevent software engineers from getting close to the problem.
I used to work in large scale factory process automation. I can't tell you how many time I've asked "can I go into the factory and see this process I am being paid to automate with software?" and been told "no, the process engineers will do that. You just write the code. Stick to your job!" I eventually left the field because of this, and found out it's pretty much the same everywhere outside of startups and academia.
I've been working on CRUD-centric applications since before the GUI era. And I wonder why we keep reinventing CRUD systems? Most of the "logic" COULD be defined as attributes, such as data dictionaries, and relatively simple "rule tables" that are kept in the database. These could handle roughly 95% of the logic, and most the rest could probably be put in stored procedures to make them app-language-change-proof.
I've seen products that kind of come close, but they get tossed out when the shiny New Thing comes along and kills sales or momentum. People are so scared of being left behind that they throw everything out and start over to keep up with the IT Joneses. I don't really blame them: agism is real and ugly in our industry.
I agree the front-end style keeps changing, such as going from CUI to GUI to Web to mobile etc., BUT most of the principles of CRUD have not changed. Do we really have to throw out the entire CRUD engine to get the latest front-ends?
Techniques like MVC were supposed to separate front-end issues from the rest, but as implemented I fail to see it. They often do or assume data joins in code instead of the database, for example. That's stupid; whey reinvent the database? And they often rely on "scaffolders", which are code generators. If you are relying on an attribute-centric CRUD model, then you don't need to generate app code. Generating code means you failed to abstract ideas into attributes and are implementing low-level attribute handling in app code instead of reading/processing them directly from the attribute/rule tables. They automated bloat, not removed it. (Sure, you'll still need to generate client-side code, such as jquery handlers, but it could be at run-time.)
Maybe CRUD is not as exciting as aerospace and thus has none of the modelling tools and abstraction languages mentioned in the article. It has a reputation as being too simple, which is not really true. Dealing with customer expectations, databases that have built up a lot of tangled cruft over the years, and adapting abstract representations to changing UI fashions is often not easy.
Table-ized A.I.
Has anyone here tried TLA+? Any comments?
Table-ized A.I.
Comment removed based on user account deletion
This sounds like the lament of the "big idea guy" who believes that they have the next great idea that will revolutionize everything but lacks the ability to articulate it into something actionable. It's obviously the "coders" fault that he "doesn't get it." Those stained cocktail napkins covered in faded and ripped scribbles should've made everything crystal clear.
I guess this could explain why I'm so much better at programming than anyone else I know. I actually do think like the computer.
Yes, this is getting much closer to my objection to the quoted piece. Writing a program is essentially constructing a mathematical proof. Can you get from your desired inputs (assumptions) to your desired results (theorem)? Over the years, I've seen CS coursework reduce the underlying background in math, and specifically formal methods like proofs, in favor of getting in there and programming. That's a recipe for producing more programmers quickly, but not necessarily assuring that they have what it takes.
Separately, there seems to be a very strong incentive to let a cool prototype, with all that that implies about its (non-)handling of edge cases, say, turn into critical infrastructure as people pile on to enjoy the initial benefits. We as consumers accept this all the time, and often have neither the time (or think we don't) nor the capability to question things until it's too late.
seriously. Https://docco.in is our saviour.
If code wasn't challenging, I wouldn't enjoy programming.
Same as literate programming from Knuth.
“Typically the main problem with software coding—and I’m a coder myself,” Bantégnie says, “is not the skills of the coders. The people know how to code. The problem is what to code. Because most of the requirements are kind of natural language, ambiguous, and a requirement is never extremely precise, it’s often understood differently by the guy who’s supposed to code.”
My reading of the article is that it's not coding itself that's the problem, we can do that, the problem is that we're struggling to develop requirements for more and more complicated systems. As systems become more flexible and their environments more variable, it's becoming harder to write them.
WRONG
Anyone who ever thinks anything like this, trying to excuse their own shortcomings, is totally incompetent.
Bugs are a management issue. Period. They don't even need to exist.
But for some reason tasks that would be management's job in engineering jobs of comparable scale in other sectors are deferred to grunt programmers, with the gold standard being "does it appear to work at the time the investors want to force a release?"
Most people still treat computers like voodoo magic. They are resistant to the idea that we have total and complete control over the medium. Even people who are trained engineers have not dispensed with this kind of attitude.
I'm not sure anyone really wants to hear my real point, but I'll cut to it.
Poor software quality is a direct reflection of the corruption in our society: no standards, no rigor, no one cares, good enough to get me back to my microcosm of comfy chairs, bright colors and loud noises is good enough to survive the eons.
This is the direct result of letting low-quality people participate in our society and assuming everyone is equal because "treat others as you would want to be treated no matter what even when they're ignorant unyielding belligerents trying to claw their way into the niche you depend on for survival"
We are chasing our tail into the grave.
Okay, I guess we need some more mod points to shut you up too. I'm sure it'll happen soon.
BTW - you didn't bat an eyelash even once at the suggestion that you're creimer. In fact, you just confirmed it, aspie.
Enjoy your karma loss, sucker!
You've posted twice today under ilovefatcashews...disproving nothing.
Regardless, don't you have better things to do that deal nonstop with a bunch of people who wish you would leave?
Who are you talking to? If you read the blog post, cdreimer doesn't even read these comments.
Comment removed based on user account deletion
Who are you talking to? If you read the blog post, cdreimer doesn't even read these comments.
The funny thing is that all these self-righteous assholes are proving that cdreimer is right about them.
Fixing a system like this when it doesn't work as expected requires an encyclopedic level of knowledge about all of the low level pieces as well as the larger picture of the entire system.
I quite often fix complex system with virtually zero knowledge and only a basic understand of the high level concept. I fill in the details using reasoning and make the general assumption that there are few ways to solve a particular problem well, and if I can create a good solution in my head, the chance of that solution being similar enough to the current implementation is very high. This has worked extremely well for me
An example of one such situation is my companies $250k F5 firewall was sporadically having a bad interaction with some of our customers when using HTTPS for web API calls. The issue had all of our senior admins stumped, we had a team from the F5 company activity looking into the problem for several days, the multi-million dollar contract customer was very angry. I was fresh out of college with a few days of programming under my belt and zero experience or knowledge about HTTPS, other than it was some cool magic. In less than 10 minutes of reading Wikipedia about how HTTPS worked, I had an idea of what the issue was, and in 30 minutes we were able to reproduce it, and told them admins where to look. Turned out it was the HTTPS session cookie was set to expire after some amount of time, but the HTTPS session cookie cache was expiring the cookies earlier.
The admins plus the Enterprise level support specialists from F5 could not figure this out in the 3+ days they had been working on it, yet I was able to figure it out in less than 10 minutes, which included reading Wikipedia on how HTTPS works. Before you say that I had the benefit of their 3 days of research, I did not. All I had to go off of was the original email the customer sent. I was not ranked high enough to be able to talk directly to such senior staff during such an important event. I had to explain it to my manager first who was able to get the ear of the CTO to tell them to talk to us.
Get rid of the idiot simpletons doing Java, C#, Python, and such crap. Code is NOT hard to think about at all. It's just not for janitors.
Try it yourself: Stand straight, feet side by side. Prepare to walk. First you will have to shift your weight to one side so that the foot on the other side can be raised. Balance, lift leg, move that leg forward. Did you notice that when moving that leg forward your body moves back to maintain balance? Did you notice your arms moving? Think about how your arms move while walking- do you fully understand what is happening there?
Riding a bicycle is too hard to think about. Playing a violin is... The reality is that we do many things in life without conscious awareness. Thinking is not only NOT required, it is counterproductive. We depend upon reflex actions that are a result of repeated practice. Coding isn't that special.
...omphaloskepsis often...
But with Brian and Steven's help, I guess I can be a computer engineer!
Most of the article is just pointless storytelling that carries no useful information whatsoever. Here's the gist: The author has no fscking clue about programming. The problem: Yes, it's hard to keep all the invariants in your head (not to mention budget and time constraints) which leads to bugs. The proposed solution: Formal verification. So now instead of getting the code right, we just need to get the verification specs right. It's turtles all the way down.
Also, not just any formal verification but some supercool (read: idiotic) graphical system where you create the specs by connecting boxes with lines. Because that's somehow supposed to be easier than working with text. Anyway, good luck finding a mistake in a spec with more than 20 boxes. You're gonna need it with all that visual clutter in front of you.
I was one of those fake accounts. Account was re-named, same as with creimer." I was getting bored with it, so no harm done.
I have no idea who "Fakefuck39" is, and I'm not from France or Israel, so maybe the claims that there was a sort of anti-creimer posse was a "don't believe everything you read on the Internet" situation.
Yes, we lost years of karma and posting history... Oh no wait, YOU did, sumo-breath!
FakeFuck39 was a two-year-old account. Unfortunately, the owner of that account focused exclusively on creimer for months. Management has no problem deleting such accounts for harassment. Your account will also get deleted for harassment in the near future.
....for all the rest of the sheeple. They're too simple minded to understand or even be capable of doing the work that we programmers do. This is why we make the big bucks and have nice cushy jobs that pay well with excellent benefits.
The flipside of all that though is the bullshit that comes with it. The fact that its too hard to think about empowers Senior programmers to make up bullshit excuses to send us underlings off on totally unnecessary pointless busywork to do so that we have nothing to "show off", and in the long run they do and their own jobs stay secure, and management is too stupid to know any better. If we argue that we've been assigned a totally pointless bullshit task that is going to equate to a big waste of time and money that adds no real benefit, there's no way simplify and describe the bullshit to management in a way they're intelligent enough to really understand. They only have the input of their "trusted Seniors" to go by, so they'll just conclude that it is we, the programmers, that are being difficult to work with an insubordinate to our superiors and thus we'll eventually get fired or laid off, which of course further solidifies the security of the Senior programmers (this was their real agenda all along). Its a disgusting reality, but ya gotta face the fact that its true to some respect: for some folks code really is too hard to think about.
Maybe your attention span is to short? Hard problems take time, and thought. An old sating goes, "the easier a problem looks, the more stupid you are." Of course, everyone knows about the company of fools and their money.
And what exactly do you think youâ(TM)re proving by creating multiple sock puppets? All youâ(TM)re doing is driving reaction to you more negative - no worries about running out of mod points, creimer - more mods are turning negative against you with every post you make. Youâ(TM)re so far negative at this point that every time you create a new sock puppet, itâ(TM)ll be nuked to oblivion in minutes.
Suck it, big boy.
the AI, or limited AI, will take our ideas for what a program should do, and translate that into computer code.
And that's the reason why we have OOP.
keep it simple stupid.
the cleanest, leanest IDE is the way to go. to be honest, if android stopped 'innovating' (deprecating & changing its APIs) maybe people would have time to learn how all the tools & stuff works.
#1 best feature of any a platform: not changing.
to be the link between the business folks who understand the problem, and the programmers, like me, who understand the computers.
A rational manager would look at a tool and think, "This is $1199 a year for a developer I spend $150K a year on. Does it make my developer 1% more efficient? If so, it's worth it."
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
Code is not "hard" for me. Well, it can be, but usually it isn't.
As for complexity, there are well-known mechanisms for controlling that complexity.
In the end I'm a trained professional and highly suitable for working in this field. Oh, and I have no trouble keeping in mind the user requirements, the practicalities of the user interface, performance and all the rest. Defining those things can be a problem.
Easily the worst part is getting a user to explain their job and business process in ways that don't involve hand-waving, "it's complicated", or "at this point some magic happens." Most users aren't used to explaining their jobs in ways that the computer needs. I get paid (in part) for being able to drag these stories out of them, without turning them into Computer Science grads.
Yes! In the real world there is often time to do something thrice or more but nowhere near enough time to get it right on the first try. Doing is the quickest way to learn. One of the most common mistakes I see is leaving integration test until after "design" is complete.
refactor the law, its bloated, confusing and unmaintainable.
My subj says it all. This MIT guy is probably looking for an excuse for why he sucks at his job. If it's too hard - don't do it, a job and play should be indistinguishable for a true professional.
I tried to read the article, but it was too hard to think about.
Actually, it does raise some good issues, but one corollary of its central point - that as systems grow more complex, the potential for error increases - is that as time goes on, our understanding of how to solve a particular problem will change.
Putting Lovelace aside, we've only been working with software for less than a century. Many of humanity's technologies are quite a bit more mature, stable, and less prone to such error, as we've had time to work out the kinks.
Were this article to be re-visited in 2117, many of the "problems" it raised would no longer exist (though certainly other, newer ones that had yet to be "debugged" would).