What part of software development do you wish was "fixed"?

[Maximilien]

honey the codewitch wrote:

a final end to source dependency hell.

OH PLEASE YES !!! THIS THIS THIS.

I'd rather be phishing!

[PhilipOakley]

Ooh, I didn't know I had primes :) Must look them up.:thumbsup:

[W Balboos GHB]

Were it not for Nagy V, I'd be risking broaching this subject - which was surprisingly absent. In part, however, it's because I'm so well isolated from management and my only real "customer" is someone who actually needs what they ask for and knows how to ask for it. But the star fixes would be in the following categories:

• Mandatory Intelligence test for users before they can use applications
• Mandatory Intelligence test for managers, cyber-security, and others before they make comments/suggestions
• Painful consequences for those who have me create and refine a project and then never use it
• Renewal of my 007ish license to enforce the above

Ravings en masse^

"The difference between genius and stupidity is that genius has its limits." - Albert Einstein

"If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010

[PhilipOakley]

Maybe it's Users and Coders understanding each other a tad more (and managers getting out of the way) ;) .

[W Balboos GHB]

I'm afraid that ship has sailed. The penultimate example:

Screen: "Press ANY Key to continue"
User: "I can't find the ANY key"

Ravings en masse^

"The difference between genius and stupidity is that genius has its limits." - Albert Einstein

"If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010

[PhilipOakley]

Maybe there isn't an "ANY" key among the many keys they have on their keyboard ;) Maybe they tried Ctrl+Alt+Del. Genius has it's limits.

[Dan Neely]

Kent Sharkey:

'Fixed' as in 'plumber', or 'fixed' as in 'veterinarian'?

Clueless meddling, and fixed as in encased in cement. @kentacmebinarycom

Did you ever see history portrayed as an old man with a wise brow and pulseless heart, weighing all things in the balance of reason? Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful? --Zachris Topelius Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies. -- Sarah Hoyt

[Dar Brett 0]

I'd add Microsoft's Remote Desktop App (available for Android and iPhone). Not as good as logging in with a PC, but they did cleverly set it up so the phone screen functions like a laptop touchpad rather than trying to make touches pass through as clicks. It's much more usable than I expected.

[Owen Lawrence]

- I wish hackers would go away so I could stop having to pay security taxes. - For the same reason, I wish customers would pay honestly so I could stop wasting time securing the product against unlicensed use. - I wish Microsoft would finish its APIs before releasing them. - Reliable and deterministic GUI layout (and stop trying to cram the whole world into a browser) - Team members that would stop taking shortcuts, and bosses that think cheaper/faster isn't worth the expense/delay/mess - A complete set of tools that everyone is happy with so we can stop changing them all the time and get some work done - Marketing departments would have small budgets, get it right the first time, and stop forcing us to create nonsensical applications and keep changing them in a giant hurry. Recognize when a product is finished and stop piling in more features that ultimately ruin it. (That goes for programming languages, too.) - Reliable hardware, asynchronous access everywhere all the time, push notifications, easier thread coordination that didn't result in crashes or hangs whenever something went amiss - Hotshot programmers that know their place and humbly stay in it - I wish all customers would follow troubleshooting instructions, in order, to completion, answering every question that was asked, only what was asked, in complete, intelligible, punctuated sentences.

[Joan M]

Can't we simply get the customers/managers fixed? :D:D:D:D:D:D

www.robotecnik.com[^] - robots, CNC and PLC programming

[Marc Clifton]

Most of my software development woes are not technology related but people related. 1. Coworkers that actually know how to code (present job excluded) 2. Previous employees that worked on the code that actually knew how to code (present job included) 3. Management that wasn't a collection of overpaid morons (present job excluded) 4. Third party vendors that would actually write decent API's 5. Third party vendors that would actually write decent documentation for aforementioned API's. The only technology solution I want is: 1. One button click to fully clone my entire development environment onto another computer. And a general complaint: 1. Can we just get rid of passwords? ;)

Latest Articles:
Client-Side Type-Based Publisher/Subscriber, Exploring Synchronous, "Event-ed", and Worker Thread Subscriptions

[Kiriander]

Requirements. Those I surely wish were fixed. Yeah, I can anticipate a couple things, but I also end up with monstrosities after months of iteration.

[etkid84]

Organizations have to get rid of all of the shims, especially the manager types.

~d~

[honey the codewitch]

I've been called a shim before, but not professionally. I've only ever understood it as 1. A slim chunk of material used to space two things or otherwise wedge them into position 2. A (usually dodgy) adapter or interface unit of some type 3. An anti-trans slur. I'm assuming #2 here? maybe between developers and the people at the company that sign the checks?

Real programmers use butterflies

[Steve Naidamast]

I would simply get rid of all technical management, which will solve all your other problems very quickly...

Steve Naidamast Sr. Software Engineer Black Falcon Software, Inc. blackfalconsoftware@outlook.com

[Rick York]

I think of them as being interfaces, kind of like that guy in "Office Space" whose sole job was to take specifications and hand them to the developers.

"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"

[mdowd65]

I wish companies would stop abandoning perfectly good development tools when they pursue the next big thing.

[trønderen]

I've been living (and programming) long enough to see myriads of great solutions ... left behind. Lots of the problems that we wish had commonly accepted solutions have solutions - but not commonly accepted. At least not today. Maybe they were common, twenty or thirty years ago, but not today. An example: The problem of changing APIs. OK, we got "interface definitions" - so make it "changing interface definitions". Every new library version comes with a dozen updated interface definitions, to cater for new, extended functionality. You must update your application, interface definition or not. The majority of Win16 APIs were like LibFunc that became LibFuncEx (with a different argument list), then LibFuncExEx, ... There was (is?) at least one with five 'Ex'! But another subset of APIs took a single argument: A struct, the first member being the struct size, implying the number of arguments, followed by the arguments. The function can be extended without changing the API: Arguments for extended functionality is added at the end of the struct. Well, you might say that appending "optional" struct members is a change, but certainly a non-breaking one. It doesn't require caller code change. Not even a recompilation. If the new library function is handed a "short" struct, it knows to skip the functionality depending on the extra parameters. A great way to reduce/avoid API changes! I follow it whenever I control the API. Here and there, I see APIs like that, but it is certainly not standard, The Way to Do It. Never touted in the programming courses and tutorials I have seen. You learn interface definitions; great for implementation independency with one specific set of arguments, but of no help with the next version. When I suggest this approach for coworkers and programming friends, the most positive response is "Yeah, for a function with more than four arguments on the ARM, the compiler lays out code the way you say". Every programmer I know insist on having every single argument individually visible in parentheses after the function name, not as a list of struct members. And every single of them thing they have a godgiven right to change that argument list for every single version. "Just look at the .h file; there you'll see the arguments you must use!". I have lived through dozens of similar ignored/forgotten techniques. Sometimes, I have to explain how we used to do it a couple decades ago, and they are truly surprised: Why don't we simply do it that way, then?

[B L Zeebub]

Easy test to see if a # is "prime": it's served with hollandaise sauce! Otherwise it's "choice"!

[Member_14857213]

- Have all software devs magically realize their build scripts can be hard to read too and they shouldn't hack or overdo them without documentation - Have all build scripts magically be able to warn a dev when a link dies or a project vanishes (or back it up automatically) - Have libraries/programs magically all start being backwards compatible unless there's a very strong reason not to (e.g., security issues) - Have all software magically clearly indicate where every file it needs is, even if the author forgot to make a specific error message - Have hiring managers evaluate candidates on skill instead of bullet points - Prefer to train managers from inside rather than hiring them in - A cross platform C/C++ GUI library that can compete with Winforms on C# and is easy to set up - Have all software magically detect everything that it needs to make it work and spit out an easy to follow report (even for non-devs) saying exactly what you need to install and where so that anyone can set up their PC like that. Including things that the dev already had set up without noticing. - Have the industry be one that learns from itself rather than saying "this time is different, we're going to start over without the legacy cruft" and then smashing headfirst into the same mistakes solved years ago. - Have every interface that takes something that already exists and rearranges / presents it in a different form (e.g., OOP layer over procedural API) clearly indicate what the abstraction is and what problems it solves / makes easier in the old API