Search Amazon.com:
Register a SA Forums Account here!
JOINING THE SA FORUMS WILL REMOVE THIS BIG AD, THE ANNOYING UNDERLINED ADS, AND STUPID INTERSTITIAL ADS!!!

You can: log in, read the tech support FAQ, or request your lost password. This dumb message (and those ads) will appear on every screen until you register! Get rid of this crap by registering your own SA Forums Account and joining roughly 150,000 Goons, for the one-time price of $9.95! We charge money because it costs us $3,400 per month for bandwidth bills alone, and since we don't believe in shoving popup ads to our registered users, we try to make the money back through forum registrations.
«5 »
  • Post
  • Reply
shrughes
Oct 11, 2008

(call/cc call/cc)


You've probably read You And Your Research.

What are the important problems in programming? What can you do to make the world of programming, and let's say we're talking about professional get-poo poo-done programming, better?

Can it be done? Are we at the optimum now? I mean obviously there's not going to be some "visual programming languages" revolution (at least it's not gonna be LabVIEW).

Right now we've got

  • dynamic languages
  • static languages

Is it really about programming languages? Is it just a question of what tools would make code become more quickly implemented, more quickly executed, more correct?

What about self-improvement in team communication? What about team communication tooling?

If you could devote the next five years of your life to making programming be more tolerable, what would you work on?

Adbot
ADBOT LOVES YOU

b0lt
Apr 28, 2005


C++ needs more features.

Hamled
Sep 11, 2003


Auditory programming languages

LOOK I AM A TURTLE
May 22, 2003

"I'm actually a tortoise."


I just want to say one word to you. Just one word. JavaScript.

tef
May 30, 2004

Avoid Symmetry, Allow Complexity, Introduce Terror


The biggest problems are cultural, i.e people.


shrughes posted:

If you could devote the next five years of your life to making programming be more tolerable, what would you work on?

My aim. pew pew.

[My day job is working for a non profit helping kids get into coding, so I think i'm quite close to working on what I think would make programming more tolerable]

tef fucked around with this message at Oct 24, 2013 around 10:14

Fib
Mar 3, 2005

Snake...?
What took you so long?


Programming will be terrible forever. Here is a cool talk by a cool guy http://worrydream.com/dbx/

pigdog
Apr 23, 2004


I haven't, actually. Also tl;dr.


I feel the limitation is going to be the human capability to specify how exactly they expect the program to work, rather than the computer following these specifications, whichever language they are in.

MononcQc
May 29, 2007

"I believe I did, Bob."



I'm gonna go ahead and agree that the problems are cultural and social first and foremost.

Outside of attempting to fix that, I'm guessing there's a glaring lack of a good way to assess software quality across languages and teams and that makes poo poo fairly difficult to evaluate in an objective manner.

tef
May 30, 2004

Avoid Symmetry, Allow Complexity, Introduce Terror


pigdog posted:

I haven't, actually. Also tl;dr.

I'd say go and read it anyway, but the tl;dr summary is this: You don't make progress working on css frameworks, and fart apps, you make progress by working on hard problems, the ones that aren't amenable to brute force.


MononcQc posted:

Outside of attempting to fix that, I'm guessing there's a glaring lack of a good way to assess software quality across languages and teams and that makes poo poo fairly difficult to evaluate in an objective manner.

I'd say the hard problems we face, or the hard problems we ignore, are of running systems, rather than designing systems. A lot of tutorials, courses focus on building a single monolithic program to be run once, and abandoned before moving on. There is much less focus on the care and maintenance of active programs. Although a few platforms *cough* erlang */cough*, have some niceties, it does seem that making live edits to a program and managing versions in production is far more painful than it should be.

necrobobsledder
Mar 21, 2005
Lay down your soul to the gods rock 'n roll

The hardest problems with programming? Dealing with changes as fast as the people that pay us (hell, even ourselves as nerds) want them to be done. The correlation of effort to "business" results is not correlated whatsoever because we're still caught up in the traditional spergy concerns like scalability, maintainability, and so forth. Software estimation is basically unsolved when most industries and creative professions have a pretty good idea of how to at least deliver something workable if you run out of time or money.


I don't think the current paradigms for programming really gel with a lot of what other "creative" industries can do with rapid iterations and such. Even the whole rapid feedback ideas from the Bret Victor talk reveals how painfully slow and imprecise we can be and then go on to produce code that's non-comprehensible.

Musicians, writers, and artists of any sort are able to get feedback instantly to good practices and bad practices / mistakes because a single unit of action is composed differently than our software is, precision and repeatability be damned. You don't get an option to be sloppy and imprecise as a programmer that scales well to becoming more precise as you get better - you start with precision / repeatability and we wind up creating constructs and scaffolding specifically in order to make the complexity of just understanding what the hell other people just played back to you more manageable, not necessarily to actually produce results faster.

Higher experienced programmers do not necessarily write FizzBuzz faster and more accurately the first time they try - quite the opposite almost. They write it in different paradigms (styles of music arguably), more maintainable to others (wtf, they're composers?), and the technicals just fade away.


Simple example is playing a guitar vs making a webapp (I'm grasping for a better analogy than this). Picking an E string gets you a result awful fast compared to typing out print "Hello World" no matter what in any language out there. As we scale out to complexity, a bad note in the middle of a concerto does not cause the entire performance to come to a screeching halt. Sure, a specific note that must be hit precisely because it's a solo or cue or whatever tarnishes the performance, but it can limp along. Our current paradigms of programming border upon "let's train 200+ orchestras identically, have them all play to different audiences, and hope that the majority of performances get a standing ovation with critical acclaim in the newspaper."

Our complex applications look like a crazy Bohemian Rhapsody of so many different languages and platforms and interconnections we are almost defined by dysfunction rather than things working. Somebody mispronouncing Bismillah makes someone miss the 5th measure cue for Mahler's 3rd symphony causing the drummer from the Roots to not wake up in time for him to play My Favorite Things with a single kick drum with his tongue. The audience typically only pays attention when Miley Cyrus has a duet with Dolly Parton for five seconds. And there is no way to get everyone back on the same page again because they're located around the world in different recording studios and their managers are forbidden from talking to each other except through room temperature IQ dolphin lawyers.

Music is complex in many other ways than I've described but the complexity is completely orthogonal to how we do things as programmers and engineers and the results between an amateur and pro are nearly imperceptible. When much of industry, once concerned with making us factory workers for decades, is now more concerned with making computing more like trained orchestras and everyone outside the musicians wants to be a composer.

And no, I'm not talking about a "difficulty" / "learning" curve, I'm talking about things in terms of "poo poo you get done for hours invested" in addition to "what do we work on in our day to day tasks?" This is a major part of why I take almost zero stock in the usual "high performers" analysis like "Talent is Overrated" because they are for professions that involve practice and execution being innately separate aspects of their job. We aren't doing hackathons or topcoder when our website is up.

I'll say one important thing though that is of benefit to all these challenges - it keeps us all solidly employed until your workplace janitor has about an equal chance of being able to write GCC as RMS by typing out its codebase again and again. Some might even argue we constantly make up this stuff to keep ourselves employed.

Programming loving sucks unless you love loving around and solving crazy puzzles oftentimes with terribly unrealistic time limits as a lifelong obsession.

tef posted:

Although a few platforms *cough* erlang */cough*, have some niceties, it does seem that making live edits to a program and managing versions in production is far more painful than it should be.
This is basically the equivalent of changing the tires of a car while it's running the Indy 500 is the thing, and most industries have trained professionals that spend entire careers with mostly static principles of technology that work. For our industry, we expect to go through several language paradigms and ways to change tires, change our oil with different whacky Rube Goldberg contraption funnels, and all of us go through tons of different models of cars from SUVs to Mini Coopers, etc. Instead, I have to make my own tools half the time because a bolt was made by hand by some kid in Mumbai that is also a metallurgist even though I bought it with certain specs from a top-tier Swiss company.

Operations in today's business environment is not considered to be anywhere near as important as oh... sales. If NASCAR were run like most tech businesses where a car is a service / product, the logos would be massive statues and spikes on the tires covered in molasses while the pit crew has to drive alongside the car and replacing the nuts with duct tape and being expected to break records every year just because they made in the top 5 the year before... and Dale Earnhardt would have died a penniless pariah while the NASCAR commissioner is second only to God Himself.


Do I sound bitter? I loving hope so.

Dren
Jan 5, 2001


I'm convinced that one of the biggest problems with programming these days is software deployment.

Suspicious Dish posted about some proposed solutions for linux over in the python thread that I thought sounded promising:

Suspicious Dish posted:

OSTree allows atomic deployment and upgrade of operating system trees. It is not designed for applications, per se. The systemd folks are looking at providing sandboxed applications as bundles.

Another coworker has been working with the Docker team, and he points out the similarities and differences between this and something like the systemd sandboxed apps.

And I agree with a lot of what necrobobsledder said about professional programming being kind of a joke. Software shops often don't know how to deliver and customers often don't know how to be good customers (how to ask for what they want, what a reasonable timeline looks like, etc.). The end result is that a lot of good money gets thrown after bad. I'm a bit more optimistic than necrobobsledder. I think that over time the scaffoldings that support software development will improve and that best practices will emerge and become standard practices.

Otto Skorzeny
Nov 7, 2008

He's a PSoC, loose and runnin'
came the whisper from each lip
And he's here to do some business with
the bad ADC on his chip
bad ADC on his chiiiiip


necrobobsledder posted:

Software estimation is basically unsolved when most industries and creative professions have a pretty good idea of how to at least deliver something workable if you run out of time or money.

I really don't know if this is the case. The mechanical engineers and electrical engineers at work aren't any better at effort/schedule estimates than the firmware engineers are. Their problems are superficially simpler but their bugs are subtler and their debugging tools are much more limited and have worse observer effects than ours, typically.

shrughes
Oct 11, 2008

(call/cc call/cc)


One of my mechanical engineering friends works at an aerospace manufacturer where, thanks to union rules, he's not allowed to touch any parts.

Smugdog Millionaire
Sep 14, 2002

8) Blame Icefrog


shrughes posted:

What can you do to make the world of programming, and let's say we're talking about professional get-poo poo-done programming, better?

If we confine ourselves to just get-poo poo-done professional programming, I think it's pretty clear that the biggest problems are people problems. What percentage of software projects fail because technical hurdles couldn't be overcome? I've personally never seen one such failure. It's just not hard to write code that does what you want, even if the code isn't good.

On the other hand, I've personally witnessed several project failures because the projects were managed poorly. I take a very wide view of "management" here. Many, many people who influence the course of software development still don't understand that it's a bigger deal to change a feature once development has begun than to change it beforehand. It's now a tired truism that you can only set two of the three variables: scope, timeline, effort. Yet if we look at the software project making news these days, we see that the ACA healthcare exchange sites have functionality and deadline dictated in federal law. It only takes a half a clue and half a minute to come to the conclusion that such an undertaking would almost certainly be enormously troubled.

I don't believe that such difficulties are going to be improved through purely technical work. Better languages, better tooling, better deployments, these things aren't going to change the way industry does business. It's not going to change who your manager's manager is or what they know, and it's not going to change what your salesperson is trying to sell to your customer.

And it's not just a lack of experience driving this wishful management. I had a Director of Development that had been a competent programmer, and he still sometimes reverted to wishful thinking over reality-based policy. I think that it takes special skills and significant education to be a decent programmer, and I think the same is true for every other person in a position to influence software projects. I don't think you can come into the field and do a good job with merely similar experience in a non-programming context. Software projects do not manage themselves, there is definitely no pit of success when it comes to software projects.

I suppose the solution to that problem is educating people in such positions about the fundamental truths of software projects, and raising awareness that software projects do not naturally tend towards success. However, I now find myself completely unmotivated when it comes to this task. I spent time trying to explain why adding more programmers to a late project does not make the project less late. Now when I'm faced with people who need that education, I find the prospect to be tiresome in the extreme. Perhaps I'm just bitter like necrobobsledder, but I don't have the energy to help my non-programmer peers be better at their jobs.

Pie Colony
Dec 8, 2006
I AM SUCH A FUCKUP THAT I CAN'T EVEN POST IN AN E/N THREAD I STARTED

we are definitely not at the optimum. i think two cool areas that are currently just research but have a lot of potential for helping programming are "live programming" ( http://research.microsoft.com/en-us...ing.aspx?iedz00 ) and automated bug finding/formal verification (i guess there are actually a bunch of cool commercial products in this area, but even more research looks promising)

Factor Mystic
Mar 19, 2006

Baby's First Post-Apocalyptic Fiction

The biggest problem with programming these days is that when something goes wrong, there's by and large no way to find out what exactly was happening. When software crashes you're only chance to fix it is to basically do a lot of guessing. Sometimes the guessing is easy because you have a debugger hooked up and you and inspect program state live. Sometimes there's logs or stack traces or memory dumps. Sometimes it's only a user giving you a 1 star review.

The NTSB can rebuild the whole airplane after the crash and figure out bolt #824621 was loose and this caused a chain reaction causing the plane to explode, and they can do this because they have enough of the pieces, service logs, black box recording, eye witness reports, video and pictures, the aircraft blueprints, etc. They control as many variables as possible and run tests and models and build up an understanding of the transition from success to failure states.

In software all we have is those inadequate artifacts of failure I mentioned but it often takes a lot more guessing to uncover the root cause. The transition from success to failure states in software pessimistically amounts to guessing because its virtually impossible to capture even a fraction of the necessary environment to really know what happened. Computers are too complicated and environments are too complicated, and computers, environments, and software are also always changing.

I see a lot of software (particularly at work) get written to deliver output when it should be written to deliver an explanation of how output was achieved. If the software is designed to be able to explain itself, the time you spend guessing about why something failed decreases a lot. Sometimes this is even just "more logging. no, MORE logging" but I think especially in a team environment it requires an attitude change.

Dren
Jan 5, 2001


JavaScript/web stuff already kind of has live programming, doesn't it? Who cares about applying it to a very experimental research-oriented language?

the talent deficit
Dec 20, 2003

a cultural boneyard

There's way too much tribalism. I don't mean brogramming or any of the 'isms either. I mean 'I'm a Ruby programmer', 'I'm a C++ programmer', 'I'm a front end dev' and 'I'm an embedded programmer'. Programming as a profession is way too up it's own rear end about what tools and methods should be used to solve programs and not about actually solving problems.

Gul Banana
Nov 28, 2003



demand exceeds supply and so a great many working programmers are not highly skilled

Suspicious Dish
Sep 24, 2011



I think my biggest problem currently is social. It's hard to learn specialties like cryptography and compression, and a lot of people steer you away instead of recommending research on them.

I'd also like to see a lot of pettiness removed. I know this is really part of every big engineering discipline, not just programming, but think of what could have accomplished if we had said "the compiler will only accept tabs" long ago. Or "the braces go here, because that's where they go".

This also isn't programming-specific, it's more of a general tech thing, but I'm really unsure where the future is. My main line of work is on desktop/workstation systems, and if you listen to the tech media, it's more irrelevant than ever. I'm generally uneasy by the "PCs are dead, laptops are dead"

And this is really a more specific challenge, but it's related to the stop energy comment above: A big problem we're facing right now in RHEL, which is similar to what Dren is saying, is that it's super scary to upgrade. We have customers still using RHEL3 because the cost of upgrading is just too high. It's just a bad way to build software if upgrading is scary. We're developing systems internally that make upgrading less scary, but it's a big social problem, because if we automate things like building packages and spec files so that there's no human error, it means the people doing it right now lose their jobs.

OneEightHundred
Feb 28, 2008

Soon, we will be unstoppable!


Dren posted:

I'm convinced that one of the biggest problems with programming these days is software deployment.
It's not just a development-side problem, the user experience is just as bad. Windows should have added a centralized update mechanism and per-app registries ages ago, but Microsoft doesn't give a poo poo about deployment at all and has just absolved themselves of responsibility by deferring to third parties like InstallShield (who are incompetent).

Also, whoever invented wizards should be shot.

Dren
Jan 5, 2001


OneEightHundred posted:

It's not just a development-side problem, the user experience is just as bad. Windows should have added a centralized update mechanism and per-app registries ages ago, but Microsoft doesn't give a poo poo about deployment at all and has just absolved themselves of responsibility by deferring to third parties like InstallShield (who are incompetent).

Also, whoever invented wizards should be shot.

I totally agree with you and I meant what I said in reference to user experience and dev experience. I recently tried getting some virtual dub plugins going on windows. I haven't done that since around 2003 and drat... what a pain in the rear end that still is. That sort of software is not very polished to begin with but the awful experience surely is largely owed to the fact that there is no good way to package and distribute software and dependencies that is supported by MS. Like why the gently caress does the visual studio redistributable runtime or the .NET CLR need to be distributed w/ a VS compiled app? Why isn't that poo poo bundled with windows?

And dish, our product is a customized distribution of RHEL. I wrote a system to inspect a kickstart file, solve and download all dependencies based on a local repo, and remaster the ISO w/ downloaded rpms. If we're not able to deliver a completely up to date system we're pretty drat close. If RHEL users could design their systems this way, as customizations of the official ISO where they know what the deltas are and it's relatively easy to stay up to date, maybe more of them would stay up to date. The problem with servers is that people don't apply any process to creating them and therefore end up with special snowflake machines they are afraid to touch. Maybe RHEL could do something where any changes to the system are recorded a la git and can be played back.

Suspicious Dish
Sep 24, 2011



Dren posted:

Maybe RHEL could do something where any changes to the system are recorded a la git and can be played back.

To do this, you need to remove the ability for packages to run arbitrary shell scripts as root on install/upgrade. But this ability to downgrade to an old composed tree is exactly what ostree wants to do.

Suspicious Dish
Sep 24, 2011



OneEightHundred posted:

It's not just a development-side problem, the user experience is just as bad. Windows should have added a centralized update mechanism and per-app registries ages ago, but Microsoft doesn't give a poo poo about deployment at all and has just absolved themselves of responsibility by deferring to third parties like InstallShield (who are incompetent).

I don't think centralized update is a great idea. Ideally, upgrading apps should be silent unless something bad is happening, and I want to be able to upgrade my apps independently of my OS. This is something that plagues us in Fedora and RHEL right now, because we have this broken policy where if one app uses some library like libpng, all other apps need to use the same exact version. So you can't upgrade app A and not upgrade app B, because libpng is the common divider.

What I'd love to see MS do is put out a library to make Chrome-style silent updates easily implementable, with all the bells and whistles that come with that (nag dialog if you've been using an old version for too long, prompt for upgrades if e.g. app addons will break).

Dren
Jan 5, 2001


Guys we've got it all wrong.

http://www.itworld.com/cloud-comput...-good-thesaurus

shrughes
Oct 11, 2008

(call/cc call/cc)


There might be a grain of truth there in that 200 verbal score nerdlords are the problem.

qntm
Jun 17, 2009


That person thinks a thesaurus helps?

OneEightHundred
Feb 28, 2008

Soon, we will be unstoppable!


Suspicious Dish posted:

I don't think centralized update is a great idea. Ideally, upgrading apps should be silent unless something bad is happening, and I want to be able to upgrade my apps independently of my OS. This is something that plagues us in Fedora and RHEL right now, because we have this broken policy where if one app uses some library like libpng, all other apps need to use the same exact version. So you can't upgrade app A and not upgrade app B, because libpng is the common divider.
Let me put it this way: If Microsoft made a way for developers to just add their own software to Windows Update's optional downloads list (with their own keys and download links) and exposed an API to ping that service to see if it has any updates pending, it would resolve most of the user experience problems with updating. It would get rid of the current paradigm of every app having its own updater, which is annoying for users and developers alike, and it's hard to see the drawbacks.

InstallShield's developers could do it too, since they have the market position for it, but they're also incredibly lazy.


As far as cases like libpng, that can be organized pretty easily with the proper structure. Small libraries can be static-linked or distributed with the app binaries, large libraries that can't maintain compatibility easily can be distributed as multiple distributions, and large libraries that can maintain compatibility (which is ideal) can ship with the OS updates.

MrMoo
Sep 14, 2000


Advancement in programming should follow science heritage of standing upon the shoulders of giants; we are standing upon rickety stilts that are being gnawed at by ferocious beavers.

Case in point: try find a steady monotonic clock on Windows.

Factor Mystic
Mar 19, 2006

Baby's First Post-Apocalyptic Fiction

MrMoo posted:

Advancement in programming should follow science heritage of standing upon the shoulders of giants; we are standing upon rickety stilts that are being gnawed at by ferocious beavers.

Case in point: try find a steady monotonic clock on Windows.

Ok I'll bite, here's the very first google hit for "monotonic clock on Windows" http://stackoverflow.com/questions/...to-applications

What am I missing?

MrMoo
Sep 14, 2000


It wraps every 49.7 days, GetTickCount64() is only on Vista+, the answer is felled by believing QPC is monotonic.

Bruegels Fuckbooks
Sep 14, 2004

i keep my word and i will kill you like i said
killing me? thats impossible for anyone


MrMoo posted:

It wraps every 49.7 days, GetTickCount64() is only on Vista+, the answer is felled by believing QPC is monotonic.

Well gettickcount also isn't strictly monotonic either even disregarding the wrapping, if you make the calls faster than the timer resolution the value returned won't change.

necrobobsledder
Mar 21, 2005
Lay down your soul to the gods rock 'n roll

Things get a lot stranger still when you're operating under a virtual machine and there's a strong possibility that your "realtime" clock is not actually really reflecting time whatsoever. This paper will tell you more about timekeeping than you'd ever care about in day to day programming.

Plorkyeran
Mar 21, 2007

Plorky Pig, let's get that Maria+Holic typesetting done yeah? You're starting to develop the requtation of lazy and slow, so ammend that for your own sake


hieronymus posted:

Well gettickcount also isn't strictly monotonic either even disregarding the wrapping, if you make the calls faster than the timer resolution the value returned won't change.

That is still monotonic. A clock which always returned a value greater than the previous value returned would be a strictly increasing clock.

MrMoo
Sep 14, 2000


necrobobsledder posted:

Things get a lot stranger still when you're operating under a virtual machine

Basically every other Microsoft API for time fails in wondrous ways. Virtual machines, daylight savings, C3 power states, and suspend & resume: all cause for celebration.

My Rhythmic Crotch
Jan 13, 2011



I think new developers need to support legacy apps, fix bugs, and learn Linux for a couple years before they get turned loose building new frameworks and apps. I think there needs to be much more focus on simplicity and maintainability of environments, build systems, deployment systems and documentation when planning new projects. Some of that is the fault of management because they let that stuff fly under the radar, but there is plenty of blame for developers too. Once you've spent some time maintaining old code and systems, I think you naturally want to make systems that are as intuitive and bulletproof as possible... unless you have political or job-security reasons not to... which is an entirely different problem.

the talent deficit posted:

There's way too much tribalism. I don't mean brogramming or any of the 'isms either. I mean 'I'm a Ruby programmer', 'I'm a C++ programmer', 'I'm a front end dev' and 'I'm an embedded programmer'. Programming as a profession is way too up it's own rear end about what tools and methods should be used to solve programs and not about actually solving problems.
I don't necessarily see a problem with that. C++ has tons of features and complex syntax constructions, so I think specializing in it is probably a good thing - provided that you are using the advanced stuff when necessary and beneficial, and not just sprinkling them all over every class for the hell of it.

MononcQc
May 29, 2007

"I believe I did, Bob."



necrobobsledder posted:

quote:

I'd say the hard problems we face, or the hard problems we ignore, are of running systems, rather than designing systems. A lot of tutorials, courses focus on building a single monolithic program to be run once, and abandoned before moving on. There is much less focus on the care and maintenance of active programs. Although a few platforms *cough* erlang */cough*, have some niceties, it does seem that making live edits to a program and managing versions in production is far more painful than it should be.


This is basically the equivalent of changing the tires of a car while it's running the Indy 500 is the thing, and most industries have trained professionals that spend entire careers with mostly static principles of technology that work. For our industry, we expect to go through several language paradigms and ways to change tires, change our oil with different whacky Rube Goldberg contraption funnels, and all of us go through tons of different models of cars from SUVs to Mini Coopers, etc. Instead, I have to make my own tools half the time because a bolt was made by hand by some kid in Mumbai that is also a metallurgist even though I bought it with certain specs from a top-tier Swiss company.

:itsacaranalogy:

Here's a bunch of things where in-use or deployed systems can have servicing done on them:

  • in-flight airplane refueling
  • Mars rovers receive remote upgrades while on Mars. This interrupts scientific data gathering (for stability reasons), but can be done remotely while in the field
  • Buildings, houses and offices can be renovated without evacuating all inhabitants (also: you can change the bathroom's faucets without needing to turn off the water in the kitchen in most cases)
  • Bridges and roads can be repaired while only reducing service partially (closing lanes) in many cases
  • Ships can be repaired routinely while in the water, without needing to drydock
  • Brain Surgery can often require you to stay awake so surgeons know if they're breaking anything as they go

Software systems can and are routinely updated live, when designed for it and when the frameworks and platforms allow it (I've done it around 25 times per server in production this year alone, and easily over 30 times the year before).

That you want to do live upgrades or not is up for debate, but running systems and diagnosing them live (rather than just waiting for a dump or an autopsy to figure out what's your disease) is worthwhile. Maintenance on its own is a major part of all software expenses over its lifetime (between 60% to 80%) and it's kind of ridiculous how little care there is put on it.

Suspicious Dish
Sep 24, 2011



My Rhythmic Crotch posted:

turned loose building new frameworks and apps.

This is sort of tangent, but "building new frameworks" is something that should not ever happen.

Frameworks cannot be built in a vacuum — the successful ones are split out from existing apps. The only exception I can think of is node.js, but it took about a year of being used in real apps for it to actually become useful, as early on _ry had a habit of rewriting a component two or three times a week.

My Rhythmic Crotch
Jan 13, 2011



Suspicious Dish posted:

This is sort of tangent, but "building new frameworks" is something that should not ever happen.

Frameworks cannot be built in a vacuum — the successful ones are split out from existing apps. The only exception I can think of is node.js, but it took about a year of being used in real apps for it to actually become useful, as early on _ry had a habit of rewriting a component two or three times a week.
I agree with your tangent. I'd consider Flask another exception, though IIRC you don't like it (for valid reasons).

Adbot
ADBOT LOVES YOU

duck monster
Dec 15, 2004



The bigggest problem is expectation management.

Consider the following reccuring problems ALL professional coders that are not parked behind an anonymous desk forever face.

1) Estimation. No matter how good you'll get at estimating projects, you'll never get it perfect, and occasionally make estimation fuckups that will cost you a lot of money or reputation.
2) Requirements. Clients are horrible loving assholes who don't understand what they need and will constantly be trying to change scopes and requirements. The best processes in the world can't change this.
3) Buyers remorse. And sometimes even after getting it 100% correct and building the client the system of their dreams, upon recieving it, they'll decide it wasn't what they wanted after all.
4) Technology choices. No matter how innapropriate a choice for the task something is, the client wants you to use it. You will be asked to write iphone apps in Java, windows servers in Objective C and linux scripts in dot net, and if you suggewt its not the right tools for the job they'll threaten to take their business elsewhere.
5) Bugs. No matter how good you are, you could have the most continuously integrated unit tested mathematically proven perfect code and deployment , but somewhere you'll gently caress up on the big job, and it'll probably be during acceptance testing with a bunch of important suits watching. Then they'll write threatening letters, because ACTUALLY they have buyers remorse since they paid for stock taking system but at the 11th hour decided they didn't need one after all.
6) Micromanagement. The client simply doesn't accept he gives you money and specs and you come back with a product 3 months later, so you implemented an Agile workflow to keep him "in the loop" and now he turns up at your office everyday and wants to engage in a retard version of pair programming with you where you type and he stares. This throws you completely off your game as he constantly tries to change your order of priorities and the whole thing slips out months at a time into a deathmarch.

All of this is about expectation management. The client gives you money and you will have perpetual problems meeting expectations. In better teams the project manager is keeping you isolated from this poo poo, but let me assure you, the problem is still there.

And this isn't a solveable problem either.

Programming is for chumps.

  • 1
  • 2
  • 3
  • 4
  • 5
  • Post
  • Reply
«5 »