How to get in touch with a developer?

[stratum]

Why? Because the developer you are looking for also has to learn new stuff in his 40ies+.

I have tried teaching coding to my spouse when she appeared to be curious about it, and I was surprised to find out that she was doing well initially but quickly lost track when things have gotten slightly more complex. That's what's wrong with some 40+ people, they don't have the patience, not that it's really difficult to learn new things.

[FabienTDR]

I just run a label with a roster in and out of 150 artists++ (over 200 releases if that's not enought) plus do online coaching program with about 600+ people. And since I have a university degree in psychology, I do know very well of K&D's work. Thanks for pointing it out, I'm not that much of a n00b.

Releasing a record is very different to releasing a software product. There are worlds in between. You can take any noise and upload it somewhere with a pretty image. It's easy. You won't sell much, but it works, risk is ridiculously low. Set and forget.

But a software product first and foremost has to run. Today and tomorrow, and even after Apple's next update, on Avid's next plugin format, and so on. As a non developer, making software for fun is brutally expensive, risky and in most cases, results land right into the trashcan. You are both fighting with financial and time considerations, operating systems changes and plugin host bugs, tough programming issues, physics and the market. Do one mistake and you lose everything, sometimes even more. Lose your dev and the same happens. All the money, all the invested time and effort. Most professional software projects fail (~70%), and these are pros doing this since decades! Think in terms of houses, not the 4-5k you need for a solid music release.

A typical developer easily crashes dozens of ideas and projects into dead ends before even getting a feel of what is doable and what isn't. Many never succeed at finishing any. Most devs will be very pessimistic to outsiders and beginners, out of experience.

[stratum]

Most professional software projects fail (~70%), and these are pros doing this since decades!

I'm quite curious about the way failure is defined in that context. It's unlikely that 70% failed in the sense that they do not even work. Chances are high they do, but were too late to the market, and are considered to be a failure commercially.

[resynthesis]

There are various ways of defining success but usually it's a combination of timeliness, budget and specification met. The percentage of projects that hit all three is usually abject (I've seen pretty large studies that suggested <10% hit all three). Reasons for failure are many and varied, read a standard software engineering text

Note also that a lot of software is not for public consumption but written specifically for some organisation which will (hopefully) have written a detailed, unambiguous specification for acceptance. This is very different to something like a VST where a product is released and the devs hope for sales.

[stratum]

Note also that a lot of software is not for public consumption but written specifically for some organisation which will (hopefully) have written a detailed, unambiguous specification for acceptance.

Sometimes those specifications are a way of getting rid of risky in house development and being accountable for the results. It's easy to write specifications when somebody else will be implementing them. Write one and hand out to one of those small companies who forever trace "easy" ways to make money. They'll first accept the job and think about it later. You don't even need to read a standard software engineering book to understand why this method fails.

[PurpleSunray]

Note also that a lot of software is not for public consumption but written specifically for some organisation which will (hopefully) have written a detailed, unambiguous specification for acceptance.

Sometimes those specifications are a way of getting rid of risky in house development and being accountable for the results. It's easy to write specifications when somebody else will be implementing them. Write one and hand out to one of those small companies who forever trace "easy" ways to make money. They'll first accept the job and think about it later. You don't even need to read a standard software engineering book to understand why this fail.

That's why you do a product requirements document and ask the dev to create a functional specification document out of it, before coding it (the wrong way).
And if you'r masochist and have lots of dollars, you ask them to first prove their Automotive SPICE compliance before you give them a project lol

[S0lo]

Still, Replying with a polite NO, is usually better than not replying.

[resynthesis]

Note also that a lot of software is not for public consumption but written specifically for some organisation which will (hopefully) have written a detailed, unambiguous specification for acceptance.

Sometimes those specifications are a way of getting rid of risky in house development and being accountable for the results. It's easy to write specifications when somebody else will be implementing them. Write one and hand out to one of those small companies who forever trace "easy" ways to make money. They'll first accept the job and think about it later. You don't even need to read a standard software engineering book to understand why this fail.

That's why you do a product requirements document and ask the dev to create a functional specification document out of it, before coding it (the wrong way).
And if you'r masochist and have lots of dollars, you ask them to first prove their Automotive SPICE compliance before you give them a project lol

This is why, in the old days of paper, the specs and safety cases for avionics systems used to fill the back of a truck Nowadays things are more compact and helped by having tool-based formal methods of carrying out V&V from original spec to executable code.

[PurpleSunray]

This is why, in the old days of paper, the specs and safety cases for avionics systems used to fill the back of a truck Nowadays things are more compact and helped by having tool-based formal methods of carrying out V&V from original spec to executable code.

Think it depends on the aera you work on.
On Automotive it gets worse year by year.
Paper specs used to fill the back of a truck.
But if I would print all process definitions, requirments, functional specs, test cases .. from DOORS & co, I cloud easy fill the stoage of a supertanker

[stratum]

Think it depends on the aera you work on.
On Automotive it gets worse year by year.
Paper specs used to fill the back of a truck.
But if I would print all process definitions, requirments, functional specs, test cases .. from DOORS & co, I cloud easy fill the stoage of a supertanker

And yet it can still fail. A common cause is that the "truck" happens to have transmission failure while carrying that heavy "paper" load.

[PurpleSunray]

And yet it can still fail. A common cause is that the truck happens to have transmission failure while carrying that heavy paper load.

Ofc, but that is the major reason for all of that huge overhead.
If something fails, you need to be able to exactly identify what and why. So that you can change the process that is related to it, to make sure it never fails again ("traceability" is the buzzword here).
It's a different world.. no... a different univerese, than developing end-user software

[JCJR]

Re unanswered email, when I was programming I tended to fall behind on mail because I was too busy.

After retirement, I check email maybe once a week and don't pay much attention to it. Mainly retrieve mail once in awhile to keep the mail servers from getting full, figuring on looking more closely one of these days. So if something interesting might be received, it might be a month or more before I'd even notice.

Maybe most folks are not so slack. Or maybe it is common that programmers don't pay close attention to email when busy. There are only so many hours in a day. Or more to point, there were a handful of people who always got immediate email replies, directly work related. Wasn't much time for sifting thru names not immediately recognized.

[stratum]

Ofc, but that is the major reason for all of that huge overhead.
If something fails, you need to be able to exactly identify what and why. So that you can change the process that is related to it, to make sure it never fails again ("traceability" is the buzzword here).
It's a different world.. no... a different univerese, than developing end-user software

I think that process system tries to emulate the way a single developer works. It's like a larger "brain" but neural wires have been replaced by talking, meetings and paper work. As a result, it has multiple sclerosis by definition. If that was all, perhaps it wouldn't be too bad, but it also has problems with dementia, since no single developer has a silent place to work and does a poor job due to attention defficiency.

[PurpleSunray]

I think that process system tries to emulate the way a single developer works. It's like a larger "brain" but neural wires have been replaced by talking, meetings and paper work. As a result, it has multiple sclerosis by definition. If that was all, perhaps it wouldn't be too bad, but it also has problems with dementia, since no single developer has a silent place to work and does a poor job due to attention defficiency.

Nah dude. Developers work like developers, they need to link commits to an ID, but's all.
Sclerosis and dementia is what managers are here for.

[stratum]

Sclerosis and dementia is what managers are here for.

Well, that has to be the case, since they are the ones who are responsible to see that in spite of the fact that every developer in the team is pretty smart the whole system still has sclerosis and dementia .