Slashdot Mirror
'Just Let Me Code!'
An anonymous reader writes: Andrew Binstock has an article about the ever-increasing complexity required to write code. He says, "I got into programming because I like creating stuff. Not just any stuff, but stuff other people find useful. I like the constant problem solving, the use of abstractions that exist for long periods nowhere but in my imagination, and I like seeing the transformation into a living presence. ... The simple programs of a few hundred lines of C++ long ago disappeared from my experience. What was the experience of riding a bicycle has become the equivalent of traveling by jumbo jet; replete with the delays, inspections, limitations on personal choices, and sudden, unexplained cancellations — all at a significantly higher cost. ... Project overhead, even for simple projects, is so heavy that it's a wonder anyone can find the time to code, much less derive joy from it. Software development has become a mostly operational activity, rather than a creative one. The fundamental problem here is not the complexity of apps, but the complexity of tools. Tools have gone rather haywire during the last decade chasing shibboleths of scalability, comprehensiveness, performance. Everything except simplicity."
...just do it on your own time, and don't expect people to pay for it.
He who pays the piper calls the tune...
Yeah there are some complicated tools but you don't have to use them. Use the old tools and code in the old way... most of them still work no problem. And even with the new ones there's simple ways to do the same thing.
How many people are throwing up snipits of python code... its everywhere. I really don't know what the fuck this guy is talking about.
I've decided to stop wasting my time responding to AC trolls/sockpuppets... so if you want a response from me... login.
Engineering any complex system requires a significant amount of planning and management overhead. When you want to build a bridge, you don't just throw a bunch of construction workers at it and trust them to make the best judgements, even though you might trust each one of them individually to build a sawhorse or something equally trivial.
It seems that you did not put the new cover letters on them.
If you want to bring three hundred people half way around the world, don't try to do it on your bicycle.
If you enjoy bicycling far more than piloting a jumbo jet, then you should be in bicycling, not commercial aviation.
What, you don't like jumbo jets and nobody wants to pay you to ride a bicycle? Maybe you should invent the hyperloop or manage a B&B instead.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
This is a old song and dance. It's easy to create software, but it is difficult to create and maintain good software.
Apply Sturgeon's Law and be done with it.
I'm tired of whiny youngsters, and not-so-young wimps who think they can program because they took a few classes, or got hired by a tech company who was desperate to hire anybody with even the slightest talent.
Like the whining by Phil Fish in Indie Game movie about it being hard to write video games. Duh.
Get over yourself, it's called work. Many people including many programmers have being doing it for several decades now.
...Yep, got a pretty solid collection of those components, yesterdays micro controllers, CPU, Ram, Rom, Transistors, Tubes, Electrolytic Caps, Resistors, Varistors, Nuvistors and whatnotstors...
Yep, they're old...but they've made me a finalist in various international Robotics competitions, given me freedom to invent stuff from scratch without making everything overly complicated, kind of like LEGO building bricks...you can make anything you put your mind to, and I like a CLUTTER FREE mind.
I do feel the pain of many of todays youngsters who have to go trough extreme learning curves just to get into "the game" from scratch, not easy. Everything is specialized and we literally have no jack-of-all-trades coders anymore, pity...that's what we need IMHO.
What this world is coming to - is for you and me to decide.
Actuall, during a surgery every scalpel move does not need to be pre-approved by some clueless administrator. The surgeon knows his job and does it with great freedom. He/She 'just do' brain surgery
Nobody would survive a brain surgery if a physician would have to go through the same hurdles as a professional programmer
With new processors being absurdly faster than they were 10 years ago, writing programs has never been easier thanks to the plethora of scripting languages available today. It seems like a lot of the tools are easier than ever to use, or still in use (make). Text editors like SublimeText or gEdit can help alleviate some of the terminal based text editor fear in a more "Word" like environment.
IDEs can do some crazy shit with little or no knowledge of what's going on in the inside, just sit back and "enjoy" the magic.
I personally write a lot of small programs, and I've never thought "this has gotten harder." Granted, I'm explicitly making the choice to use a scripting language instead of something like C, Java, Haskell, Erlang, etc. but due to the advancements in hardward-- why not? Unless you're programming low-latency server applications or games it really doesn't matter.
Maybe it's just a problem of you not finding, or having the right tool for the job?
P.S. Try scaling up a 100 servers on the cloud using Chef, then try doing that with tools/platforms from 10 years ago... No don't. It'd be irritating as shitting on an ant hill.
I don't really follow what this guy is talking about in general. But one thing I have noticed is that documentation quality on new tools/APIs has steadily gone downhill. For example, I am really excited about node.js, but on the page proper, their docs just dump some bits of info on standard functions. That ends up making learning something new, really fast, more difficult than it used to be because you have to go to 3rd party sources, they may be full of crap, way out of date or both. It is one thing to have to put in your time to get comfortable with something new, but it is another to have to act like you are hacking a black box to learn it.
Actually, there are plenty of doctors who would just like to treat patients. Instead they have to deal with insurance companies, malpractice, paying off their loans, etc. Just the other day I was thinking that this probably explains why there is no shortage of doctors who will give you a "420 recommendation" but there's a shortage of physicians accepting Medicaid patients. The Medicaid program isn't even being properly funded here.
So yeah, the doctors would really like to treat patients; but there's no satisfaction in it because of the system and in some cases there's not even money. You can't blame some of them for becoming pot doctors.
I guess maybe the equivalent of being a pot software developer is either to write black hat stuff, or work for the NSA or some other government agency that violates our rights. Kind of ironic, since the pot-heads would be on the other side if you took the government agency route.
Anyway, your analogy is flawed. You're glossing over the real issues. Any profession can be bogged down with beurocracy and complexity that's perceived as interfering with certain human factors. You can't just gloss over the issue so easily. Some of these extra tasks have a purpose and can't be eliminated; some of them have no purpose other than to satisfy the irrational fears of those who hold the purse strings. Those can and should be eliminated.
The simple programs of a few hundred lines of C++ long ago disappeared from my experience
I think the reason is, that people who pay for software have been bitten by "simple" programs too often.
With a simple program: one where you open a file, do some stuff and produce an output - that always supposes that everything works as it's expected to. It assumes the input file has the expected name, that it contains the expected data and that the format is what you expect. It also assumes that the data will fall nicely within the bounds of "sensible" values, and that the output can be written as the coder expects.
However, real-world data is never as neat as we plan for (especially when there is a deadline). There can be missing values, changed formats, some data is floating point or fixed and DATES. Can the "simple" code deal with DD-MM-YY and DD-MM-YYYY or even some people who randomly swap that day / month / year field order, or use names for months - or slip leap years into the fields.
Basically, with the "simple" libraries that most of us use, there is a fundamental lack of robustness. Our code works with data we expect, but coughs a brick with something unusual - or from a changed specification.
And then there's the security angle. There's always a security angle
These are the factors that have made "coding" a complex business. Simply because the simple coding models we use to knock out a couple of hundred lines of code with, have shown themselves up to be wrong, limited an unreliable.
politicians are like babies' nappies: they should both be changed regularly and for the same reasons
As a surgeon, I long for the good old days when I could just give my patients a rag to bite on, grab my hacksaw or a good pocket knife, and BOOM, DONE. Now I'm forced to use an "operating room" which has to be "sterilized" along with everything in it -- you wouldn't believe the time it takes! My boss won't even let me use my own hacksaw; instead there's this bewildering array of "scalpels" and "clamps" and things -- they're supposed to make my job easier, but I spend half my time trying to figure out which one's the right one for the job. Oh, and goodbye rag -- I have to have an anaesthesiologist now, and IV tubes for blood and fluids, and all these doohickeys to monitor heartbeat, blood pressure, O2 sat, etc. It's a nightmare!
Just let me cut!
Koans and fables for the software engineer
As things become more powerful, you can't just wish away the complexity. Maybe you can hide it in one of these 'shibboleth' things mentioned in the summary. That sounds big enough to hide things. Or maybe we could just use describe things more clearly -- but that's crazy talk.
That's why I work with vi and arduino, or openwrt.... Much more fun, simple, and I can do almost anything I need done.
But yes, it's a fixie, not a jumbo jet. It's what I like doing, and I happen to make a living at stuff like that. If you are hired to build a jumbo jet, then you need jumbo tools and jumbo overhead. If you don't like it, scale down, hang up a shingle, and get a client. You might be surprised.
Anyone can write software, but to make it sustainable is a serious challenge. Ive worked at corporations where there was a coding standard that everyone "was expected to know" but it was never told to anyone on their first day (it turns out that was the oreilly perl best practices book.) Im currently working in a shop on a 15 year old application with a confetti development pattern that uses tomcat, jakarta, java, josso, struts, postgres and mysql, as well as a host of other malevolent and unsustainable technology with zero implementation docs and minimal code comments. I understand the love of coding, but as a greybeard i also understand the need for the managerial aspect of it as well so let me try to expound upon what it is we seek to do. im sorry if it comes across in an arrogant way.
standards, practices, limiting scope and clearly defining goals and objectives prevent redundancy and wasted human time, which lets me keep devs longer because im not constantly sandpitting them in your 'just let me code' app. competent documentation and a service framework with a specific workflow ensure your application can and is debugged in a timely manner when it breaks, meaning I dont drive you out of the company with mandatory 24/7 pagerduty. ITIL and SCRUM are designed to ensure you arent a permanent part of the application, and that I can rely on other teams to help support it if or when you decide to leave for your next job at $corporation. Status updates and progress reviews really dont help you though, they help me. I need this information because at my meetings I have to run defense for you, my star coder. I need to know dates, times, and what it is that you're doing because I translate that into simple english for people in charge of my departments expenditures. "hes just coding" is never an answer i can give to my superiors, because ultimately as a management droid im responsible for you. if something breaks, thats actually my fault. and it makes the entire team look bad, despite it just being your code. If there is an unexplained cancellation and I dont convey it to you, that is also my fault and i expect you to hold me accountable. We're a team.
I love creativity, i really do, because it means I've hired a good developer. Find a solution, write an application, code a system, but i fully expect you to design it and come up with a unique and functional way to make it the best. But unlike college, the things you do here will impact the company you're a part of for a long time. your code isnt just getting read-and-shred by the adjunct prof, its expected to perform a useful function for us and as such there are dramatically different standards and practices for how you need to code. im only sorry college doesnt teach this; it can be an uncomfortable awakening for many grads.
Good people go to bed earlier.
I could throw so many acronyms and language/framework names at you I personally use in a single project that you would want to kill yourself before going into corporate web-dev. And I don't even use Java EE, I use Spring (which is still a beast, but not as bad as Java EE.)
void *unemployment;
struct hell *reality;
Comment removed based on user account deletion
I agree, the Java stack in general is way too big and this is from a guy that does Java development with the Spring framework (not as bad as JavaEE.)
But Java does have one big advantage: It can do anything
Need to connect to some ancient database? There is a JDBC driver for that.
Need to dynamically create a new excel spreadsheet, PDF, word document and so on? There is a library for that.
Need to talk with some bizarre web service that uses some kind of binary format? Probably there is a driver for that.
Unfortunately for corporate development you really need this kind of flexibility, that is why you don't see Ruby/Python/Node too much in the industry. Even Python (which has a very good set of libraries) comes short in many areas.
Sure you could write your own driver for Node, but:
a) You are not that good with node to do it (because it is new and your devs are just learning it)
b) It will take more time to get it stable than the thing you are trying to build in the first place or it will be buggy as hell
Sad but true, the language really doesn't matter much these days, what matters most is what the language can talk with and how hard it is to make that language talk. It is getting better though, web-services for example are standardizing in REST APIs.
Yes, it is true coders have little time to code. But the author misses the primary cause: the ratio of library/framework code to self-written code.
In the old days (say, 25+ years ago), you would pick up a book -- a single book -- of the OS API calls, memorize, and start coding. Today, with github, it's as if everyone in the world were working on the same single project. Today, a developer needs to learn all these libraries that are coming out daily and how to work with them. In the old days, there was a lot of reinvention and co-invention of the wheel. Today, that is not allowed, because one has an obligation to "buy" (for free) instead of build because of a) of course, development time and b) more importantly, one gets updates/upgrades "for free" without having to invest (much) additional development time, and c) one's organization can advertise in the future for developers who already have experience with that particular library/framework.
To address specifically the reasons identified by the author:
But this new development paradigm of the global github hive -- where we're all essentially working on and contributing to this one massive codebase that we all have to understand -- is what the author missed. The amount of custom code to actually code is small now, and the majority of time is spent figuring out how to get the various libraries and frameworks to work.
Of course brain surgeons don't "just do" brain surgery .... in any surgery, there's a ton of pre-operative work, investigation, preparation, paperwork, practice, etc. No one just dives in and cuts open your head.... and just as no one administrator hovers over the scalpel's every move, no manager hovers over every keystroke, either.
The surgeon knows his job and does it with great freedom. He/She 'just do' brain surgery
Nobody would survive a brain surgery if a physician would have to go through the same hurdles as a professional programmer
Very true. By the same token, by the time your average programmer was done with your brain surgery, you'd have toenails growing out of your asshole for some inexplicable reason. "Oh, we'll fix that in the next surgery." *That* is why we have "clueless" administrators pre-approving their shit.
The brain surgeon has to be worried about malpractice lawsuits; the programmer does not. The brain surgeon requires board certification; the programmer does not. The brain surgeon requires twice the education and years of formal, on the job training before he is ever allowed to operate; your average programmer thinks he/she can write shit-hot code before they even graduate.
the growth in cynicism and rebellion has not been without cause
In DOS I had to manually draw every UI element.
Only in your first couple projects. By your third DOS project, you probably would have built up your own UI library.
But the big thing that DOS did better than Windows back in the early to mid 1990s was using all the features of the VGA. DOS applications could run in low definition (Mode 13h, Mode Y, and Mode X, with resolution of 320x200 to 320x240). This allowed updating the whole screen before Windows finished updating half of a 640x480 standard-definition screen. DOS could also use hardware scrolling to pan over a large virtual area without having to do the bit shifting bullcrap that plagued standard VGA mode back then. Both of these became less relevant, however, as CPU speeds and bus speeds rose and especially as graphics cards began to incorporate 3D rasterizers.
This new language is as much fun to code in as Python without the pure-interpretive overhead. The latest Xcode includes a "playground" prototyping space that makes it easy to experiment with pure code, including library API calls, before cementing your work into the application framework of iOS or OS X. Right now it's a one-manufacturer language, and still beta, but something tells me it's going to spread.
If you have a project that's too big to fit into 1 person's head and you want it to work right and be maintainable, you either have to have a team of people who practically read each other's minds or you have to have a solid design and maintenance process.
Either that, or you have to accept that unless you get lucky or your code is hardly ever used, you will have problems down the line.
Having a lightweight or non-existent process is fine for projects that can stay in one person's head and which won't need to be maintained by anyone other than the original author.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
Source control, IDEs, build systems and bug trackers... are all very ancient tools that tend to make people more productive so they can spend more time coding... leaving me puzzled and confused by TFA's point.
He seems to be saying enabling infrastructure to manage a product lifecycle is more difficult or at least non-trivial vs. problem space itself... Suppose if your one of thousands of shops churning out proverbial flashlight and fart apps this could well be the case...otherwise it is hard to understand how it can be true. While supporting infrastructure can and does become very complex for large development efforts there are usually tooling peeps on staff who specialize in each subdomain.
What makes matters worse you go on to hate DSL's, use NoSQL databases... which leaves me little choice but to assume you hate everything good and nice.
Either that or you got screwed working for some grossly understaffed rinky dink company with reams of old code nobody understands who lied when they used the word "developer" in job description...LOL.. happens...a..lot.....
My point was that in MS world, you don't have a compiler until you get the SDK (which most people don't even know exists), and most think you only get a compiler through visual studio, whereas in linux it is commonly already there or a 'yum install gcc' or 'apt-get install gcc' away. A *whole* lot of people assume visual studio is a hard requirement to develop with microsoft first-party toolchain and as such you end up with project files for really stupid crap.
XML is like violence. If it doesn't solve the problem, use more.
doctors like single player systems as they don't have to put up that much paper work and billing BS.
This reminds me of the mythical Programmers' Stone project, and how the solution AGC had was to live as a hippy without any money.
Not, you know, what most people want to do.
I agree with the insightful replied below (or now, in parallel): there is a lot of stuff that impedes productivity.
However, I would go further and say, what do you expect to happen if you create an unfair environment from the start? The only way it could get better is if computers were used as tools to empower people, and that hasn't happened since the 8-bit era, and even then, it was by accident.
Microsoft, Google, Slashdot, and the GNU / Linux project all became big because they empowered people to do what they wanted, at the time. Even with all the problems, Microsoft still makes the best widely available stack to move from idea to product, and they will continue to do so, because Apple only wants clients with "disposable income", but Microsoft wants mindshare first and taxes behind the scenes to maintain their position.
So as long as you want money up front (Apple, most employees, FOSS in general as consulting fees or attention of peers) and aren't setting up to rule the world (Google, Microsoft) by saturating mindshare, things are going to go the way of "big government", or any big groups, and become so full of red tape that no real innovation can occur.
Serving the needs of the many requires that you understand how different people are, and how little most people want to pay for something. The concept of "investment" may never be mainstream, and anything which allows people at all levels to make money, most of which does not come directly back to you, then you would be able to dominate minshare... but if you want only competent, professional people on your platform then you will eventually get people who are confident at being professional rather than everyone, including those who want to make the world better or express something new.
So, if you want to have fun, forget about the professional toolset... it is designed to increase operational level work at the expense of expression, because most of what professionals do is not new, and the more operations it takes, the more hours can be billed and the more job security is created, and the more documentation is left behind in the actual code, even if you do get hit by a bus or try to strike.
If you want to have fun, get a Raspberry Pi or build your own stack or deal with something that gets you closer to your goals shorter. Or become a novelist, plenty of novelty there.
The future, if there is any, won't be visible by the professional world, anymore than emulators for game systems can come from the corporate world, or meditation can come directly from big pharma.
If you're developing on a platform as developer-hostile as that and you're locked into it so your business can't port to other platforms if necessary, I would submit that you have bigger strategic problems and long-term risks than merely being a small company. An arrangement like that is an axe hanging over the head of almost any size of company and you have absolutely no control over when it might fall.
(No, I don't develop iOS apps or write console games, despite occasionally getting enquiries in those fields, and this is why.)
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Programmers are just cogs in a machine nowadays.
Code monkeys are, and that's the way that managers who hire code monkeys like it.
There are plenty of programmers out there creating interesting and useful new software, and plenty of customers/clients willing to pay serious money for the value that software offers them without all the unnecessary bureaucratic overheads and middle management crap.
If you are a good programmer and professional in your general conduct, you owe it to yourself not to be a code monkey for anyone, IMHO. You have to be really, really unlucky with the time and place when your current gig(s) run out not to have better options in 2014.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
I laughed my way through this article. The best part was when he said he wasn't the only one, and linked to someone with legitimate concerns.
Don't want to use a bug tracker? That's fine. Use a TODO file in your directory if you need to put something aside.
Don't want to use VCS? That's REALLY stupid. Hook a clapper to a backup trigger. "I'm about to do something dangerous! (clap clap!)"
Why really stupid? Because you can argue git is too complicated, that it lets you do too many things, etc, etc. Great! You might be right. But if you're a beginner, you can get away with:
The long, laborious setup:
git init
Saving changes:
git add --all .
git commit -m "This is what I did."
Undoing changes before saving them:
git reset --hard
git clean -fd
Hell, use a GUI. There's decent ones out there. But use something simple. Start HERE. This gives you an annotated history of what you changed and why. Do NOT argue that's some ridiculous process, because it will probably save you a significant amount of time within your first day.
Yes, you can set up a remote repository. Yes you can push, branch, merge, whatever the hell you want. But if it's just you, you're damn right that's too much process. So don't do it!
From: http://vpri.org/fonc_wiki/inde...
---
We are faced with a need for significant action and the odds are stacked against us. Invention receives no attention, and innovation (even when incorrectly understood) receives lip service in the press but no current-day vehicle exists to to nurture it. This wiki is an open invitation for talented individuals to pool their energy and collaborate towards fundamentally changing computing.
Over the years many groups have debated how to make progress in computing. There were likely as many opinions as there were people in the debates. Nevertheless personal accounts suggest that initiatives were sometimes reduced to a handful and then pursued with vigour. Consider what could be achieved by following the same pattern today, with the added benefit of doing it as a virtual, distributed team.
Our goal could be to capture the significant ideas and initiatives that we have been exposed to, are aware of, or can discover, distil them into groups, reduce them to a handful of concepts worthy of vigorous exploration, and focus our efforts on these common ideas with the eventual aim of making substantial progress towards finding a common set of fundamentals of new computing.
---
See also: http://vpri.org/fonc_wiki/inde...
A big focus of FONC was in reducing lots of complexity. Smalltalk shows what is possible... But in practice new languages and new standards often just add more complexity to the mix and what we often need are better tools for dealing with complexity. And community and trends mean a lot too, as does hireability and ubiquity and easy installability. So, again, in practice, I'm moving to JavaScript with conceptually simple backends (even in, yikes, PHP) -- inspired in part by Dan Ingall's own work with the Lively Kernel which shows what is possible as near-zero-effort-to-install JavaScript apps.
My own thoughts on FONC from 2010: :-)
"fonc] On inventing the computing microscope/telescope for the dynamic semantic web"
https://www.mail-archive.com/f...
---
Biology made a lot of progress by inventing the microscope -- and that was done way before it invented genetic engineering, and even before it understood there were bacteria around.
What are our computing microscopes now? What are our computing telescopes? Are debuggers crude computing microscopes? Are class hierarchy browsers and package managers and IDEs and web browsers crude computing telescopes?
Maybe we need to reinvent the computing microscope and computing telescope to help in trying to engineer better digital organisms via FONC? :-) Maybe it is more important to do it first? ...
It's taken a while for me to see this, but, with JavaScript, essentially each web page can be seen like a Smalltalk ObjectMemory (or text-based image like PataPata writes out). While I work towards using the Pointrel System to add triples in a declarative way, in practice, the web of calling cgi scripts at URLs is a lot like message passing (just more like the earlier Smalltalk-72 way without well-defined syntax). So, essentially, a web of HTML pages with JavaScript and CGI on servers is like the Smalltalk system written large. :-) Just in a very ad hoc and inelegant way. :-)
---
A 21st century issue: the irony of technologies of abundance in the hands of those still thinking in terms of scarcity.
It's an attempt to get the most "bang for the buck". Essentially you write lots of small programs which have limited and well defined functionality, then you hook them up any way you like. In fact taken to the extreme (as with Plan9) you can do anything with simple shell scripts.
BTW there are simpler developing environments out there which have a decent feature set, without the complexity of a C(++) toolchain. Lazarus is just one example of it. Of course you then loose flexibility. Lazarus, for example, is mostly suitable for GUI applications. Writing a webserver with it is hard. Of course it does GUI decently well, allowing you to have one codebase compiling from everything from your bog standard Linxux (GTK) over MacOSX, Android to even exotic platforms like Win32.
i had brain surgery once, and I performed brain surgery on somebody else at the same time. that is how you keep the costs down!
I would also like to point out that back when it was every coder did everything himself from scratch (i.e. the good old days), the actual products sucked. There was a lot of fun work to be done reinventing the wheel millions of times over, but when 99.9% of the wheels had serious flaws, it was pretty hard for the user of these wheels to get any real work done.
So it turns out that most programmers are terrible, and they think it's fun to reinvent the wheel, because wheels are the only thing (they think) they understand. They think learning new tools are "boring" or "stupid" but mainly because it's hard to do things in a way you aren't already used to and "hard" things are "stupid" to people that want to use the rationale that the only reason they might not understand something is if it's stupid. The smart programmers learn to use the tools because it actually makes more efficient use of the time spent programming.
There was a time when programmers complained that compilers were stupid because there was no need to write in a high level language when you could just write in assembly code instead.
The smart programmers weren't the ones that could read and write in assembly and didn't need high level languages. The smart ones were the ones who recognized that high level languages would make programming more efficient and created that tool.
That's because in the 90's programming got more difficult, and programmers *liked* it. No more soccer moms entering the field because they heard it was a way to earn a decent wage.
Complexity makes programmers feel they can do things most people can't. So, they seek complex solutions. If it's not complex, it must not be the intelligent way to do it, since a lesser person could do the simpler thing.
They have it backwards, of course. The ability to reduce the complexity of a task is actually a higher skill.
Requirements change. The most common reason is that the requirements are normally simply not known until the project is underway. There are exceptions; my wife liked working for accountants because they knew what they wanted ahead of time. However, most people don't know what they need until they see enough things they don't need. Good requirements analysis can help (and I have daydreamed of getting mob enforcers to do it - "Is ya gonna tell me what data you need here or is I gonna break your kneecap?"), but it almost never works all the way. Another reason is that the situation changes, whether by reorganization or new laws. I've also seen requirements people meet with the managers of the workers who are going to use the project, but that's simply bad requirements analysis. I've also been on a very successful scrum project where our hardware engineer was still doing basic design work while we were getting the preparations done. We did know the overall system very well, and so we had a good idea where we were going to have to make changes. I wouldn't recommend that process for everything, but it saved time getting a new process ready for customers.
Doing visible accounting of the cost of change requests is useful, and on a large project you really do want a change control board. You usually have to be prepared for large changes anyway.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes