First of all let's get some things out in the open:
1) I don't really like developing large pieces of software. I quite like embedded systems stuff, but that rarely feels like it counts as "software development" as the systems are usually small and really focused on a small number of pieces of functionality that are closely tied to the hardware.
2) As many people who I've worked with over the years have observed, I'm not a good software engineer. I'm often lazy in the wrong ways and inconsistent in how I do things... both not good when writing software.
3) Despite the above, I do still write software. Sometimes people even pay me to do it, and I do manage to make it work well enough to be useful.
Right, enough of the scene setting, on with the moaning!
Moan #1
"Everything has got so complicated"
Writing code is essentially a pretty simple activity. You open a file, you type in some appropriately formatted text and you then run it. The "run it" bit might involve a few steps, like compilation or whatever, but that's essentially it: type it in and run it. It is still possible to work this way, and many people who do back end types of work will still do this for knocking up scripts and utilities to keep the wheels turning, but it's actually very difficult (and frowned upon, it seems) to try to work this way for even slightly more complicated systems. As soon as you have any sort of user interface you are sucked into frameworks, IDEs and multi-layer systems.
Moan #2
"Everything has got so big"
Recent projects have made me realise that the baggage associated with things getting complicated comes in many forms, but they mostly trace back to how big their footprint is. Many IDEs seem to be very big and resource hungry, even for the smallest project because they are offering facilities to do all sorts of fancy debugging and bundling in of hooks to other systems, much of which any individual project won't use. This also spills over into deployment methods, which seem to be almost an afterthought and regularly neglect simple ways to include dependencies and runtime environments or components of runtime environments. Or they just bundle everything into a mahoosive blob and demand 1Gb of disk/RAM to run "hello world" really slowly (I'm looking at you JetBrains).
Moan #3
"Everything takes so long to learn"
Over the last few years I have downloaded and installed various IDEs to use for a number of projects that I've worked on in Java, Python, C and C++ and I've never managed to get anything non-trivial working without spending several days (usually at least 3 or 4) working out enough of the detail of how the IDE works to know that it doesn't really do what I want it to in an easy way. That's sort of OK I suppose if you're going to spend a month or more buried in that project, but for anything much less than that it's a bit full-on. They also usually assume that you're also going to become an expert in some GUI development framework and shoehorn your project into some very particular template, that is broken down in their particular way. Maybe I'm just crap at learning this stuff, and always want to do things in stupid ways, but I regularly end up in a nightmare of scope problems and passing stuff around in stupid ways or with globals just to get stuff working.
So what's my answer?
We'll of course I don't have an answer and part of the reason for posting this is that unpleasant fact. But I do now have a couple of approaches to try to minimize grief:
1) I avoid IDEs. I'd rather spend the time writing code than learning some behemoth of a system that gaslights me by hiding things and trying to lock me in a cupboard with a weird toolkit consisting of the software equivalents of a toothpick, a sledgehammer and a very high end oscilloscope for which there is no documentation.
2) If I'm in a real rush and the system allows it then I'll hack together GUI stuff using a (probably horrible) webserver and lowest-common-denominator PHP. At least it will (genuinely, unlike Java) work more or less anywhere and I don't have to learn a new system every time, bundle system dependent libraries or worry about whether it has the right runtime installed etc. just to get a button for a user to click.
3) If I want/need to do something "native" (and for my work stuff this now almost always means in Windows) then I will build stuff using plain C, the win32api and a command line compiler like minGW. I can make statically linked executables that are tiny, fast and run on any windows box with no installation other than copying the executable. The GUIs look like something out of the stone age, but they work and are quick and easy to put together.
Is there a point to this?
Not really, other than to point out that I'm a bad person and probably have completely failed to understand anything about modern software development. I do, however, think that we're probably barking up the wrong tree if we've got to the point where 1) the easiest way to make a system "easy to run anywhere" is to bundle it with an entire virtual machine... I believe that's not really what they were invented for but that seems to have become a common reason for their use... and 2) I have to invest months of my life in learning one framework that's been honed in/for one IDE and one programming language. I don't believe that we need very complex tools to build very complex software... we need very *good* tools to build very complex software.
