7 ms·

I've worked for the European Space Agency and EUMETSAT and it's crazy how much effort is wasted because everybody is writing separate mission control, monitorin

by dotdi 8y ago

I've worked for the European Space Agency and EUMETSAT and it's crazy how much effort is wasted because everybody is writing separate mission control, monitoring and data analysis applications that do 95% of the same things, each with its own horrendous UX/UI, idiosyncrasies and bugs. I'm not in that industry anymore but I just wish everybody would just grow up, use this (and related) software and contribute. No reason not to do that (of course except for pride).

oso2k 8y ago
...And contracts, and export controls, and ... :(
pjmlp 8y ago
Back when I was in a similar field, there were about 5 C++ threading libraries in production. Naturally no one was willing to give up on their own one.
- user5994461 8y ago
  The blame lies in C++ for not having a threading library built-in until recently.
  - pjmlp 8y ago
    That was naturally the reason why they were created in first place, but not why they couldn't standardize into a single one across the institute research groups.
KineticLensman 8y ago
This is actually a generic problem in public acquisition - projects are tightly funded to meet specific customer requirements and cannot themselves resolve enterprise-level problems. Building for re-use tends to add complexity / cost and a hard-nosed PM will not easily be pursued to solve someone else's problem. It seems to require top-down commitment of intent and resources - and a big stick - to make individual projects do the right thing. Obviously there can be situations where common approaches are developed and used but this seems to be the exception rather than the norm. (source - I've spent 10 years trying to work this issue in a UK public acquisition context)
- larkinrichards 8y ago
  This is quite true. At the end of the day, you've got to meet the requirements, and there are design choices you can make so that the solution for one customer is clean and elegant and yet completely unusable for another customer.
- mcguire 8y ago
  In any build vs. buy situation, "build" is driven by the desire to enlarge someone's empire, while "buy" is driven by personal relationships and other sales techniques. The first maximizes "unique requirements" while the second minimizes them. Between the two, I generally prefer "build", bad as it is, because it leads to fewer horror shows later. (10 years at MSFC, 28 years in this industry.)
- calgoo 8y ago
  This is an issue in enterprise situations as well, I have 100s of servers which are supposed to be "managed" but each project / product manager just adds their own company card to amazon and builds their own platform. The only way this can be solved is if it gets escalated to VP / CTO levels and they force everyone to follow the "standards".
  - lifeisstillgood 8y ago
    oddly enough most enterprises I know have servers "standards" for their own data centres and would dearly love to just fork cash to amazon to get them out of that hell
    - Cshelton 8y ago
      Yup. The heads of IT at enterprises are begging to just switch everything to AWS/GCP/etc., while all the mid level IT guys are starting to see the writing on the wall. Much of what they do will not exist anymore and they will need to retool themselves and/or find a new job.
      - albertgoeswoof 8y ago
SmellyGeekBoy 8y ago
> ...it's crazy how much effort is wasted because everybody is writing separate mission control, monitoring and data analysis applications that do 95% of the same things, each with its own horrendous UX/UI, idiosyncrasies and bugs. Heh, sounds like they have a lot in common with JavaScript frameworks and web development in general. With this observation in mind I doubt making mission control "web based" will rectify the situation...
- tekkk 8y ago
  What do you mean? I save a lot of time in web development using solutions created by others. I don't think this problem is unique to JS/web development but to software development as a whole. "Not invented here" syndrome is quite prevalent in a lot of areas and sometimes lack of options doesn't mean it will make the product any better. Quite the contrary it can mean that everyone is using the same buggy solution because there are no alternatives. I do not know the details of mission control technology but my uneducated guess would be that this is a cultural/management problem in these organizations. Top-down hierarchy with very large resistance to change would make introducing of new ideas (open source solution in this case) a tough job for any single actor. Also the IT-contractors or companies benefitting from selling these solutions are probably doing everything they can to keep the status quo as it is.
  - TeMPOraL 8y ago
    > What do you mean? I save a lot of time in web development using solutions created by others. How much time do you lose keeping track of those solutions and their dependencies? The JS world has probably the hugest fragmentation problem in software history. Every level in the stack is rapidly evolving, constantly spawning multiple half-baked alternative solutions to the same problems. I think GP's point is simply that if similar things are happening in NASA on small level and are considered a problem, then switching to a technology ecosystem that is a living embodiment of those issues isn't going to help.
_pmf_ 8y ago
> I'm not in that industry anymore It's the same in automotive industry (development and end-of-line-testing) (XCP and MDF helped, but ultimately devolved into a meta-standard for vendor specific functions) and in the rest of the industry I've had contact with (cooling, heating), fragmentation is as bad as ever. Standardizing on web standards will probably follow the pattern of making of adding another layer that is worse than anything in the previous 30 years.
itronitron 8y ago
if it makes you feel any better, just look at how many VC funded startups are basically doing the same thing in any given space

by dotdi 8y ago

oso2k 8y ago

...And contracts, and export controls, and ... :(

pjmlp 8y ago

Back when I was in a similar field, there were about 5 C++ threading libraries in production. Naturally no one was willing to give up on their own one.

user5994461 8y ago
The blame lies in C++ for not having a threading library built-in until recently.
- pjmlp 8y ago
  That was naturally the reason why they were created in first place, but not why they couldn't standardize into a single one across the institute research groups.

KineticLensman 8y ago

This is actually a generic problem in public acquisition - projects are tightly funded to meet specific customer requirements and cannot themselves resolve enterprise-level problems. Building for re-use tends to add complexity / cost and a hard-nosed PM will not easily be pursued to solve someone else's problem. It seems to require top-down commitment of intent and resources - and a big stick - to make individual projects do the right thing. Obviously there can be situations where common approaches are developed and used but this seems to be the exception rather than the norm. (source - I've spent 10 years trying to work this issue in a UK public acquisition context)

larkinrichards 8y ago
This is quite true. At the end of the day, you've got to meet the requirements, and there are design choices you can make so that the solution for one customer is clean and elegant and yet completely unusable for another customer.
mcguire 8y ago
In any build vs. buy situation, "build" is driven by the desire to enlarge someone's empire, while "buy" is driven by personal relationships and other sales techniques. The first maximizes "unique requirements" while the second minimizes them. Between the two, I generally prefer "build", bad as it is, because it leads to fewer horror shows later. (10 years at MSFC, 28 years in this industry.)
calgoo 8y ago
This is an issue in enterprise situations as well, I have 100s of servers which are supposed to be "managed" but each project / product manager just adds their own company card to amazon and builds their own platform. The only way this can be solved is if it gets escalated to VP / CTO levels and they force everyone to follow the "standards".
- lifeisstillgood 8y ago
  oddly enough most enterprises I know have servers "standards" for their own data centres and would dearly love to just fork cash to amazon to get them out of that hell
  - Cshelton 8y ago
    Yup. The heads of IT at enterprises are begging to just switch everything to AWS/GCP/etc., while all the mid level IT guys are starting to see the writing on the wall. Much of what they do will not exist anymore and they will need to retool themselves and/or find a new job.
    - albertgoeswoof 8y ago

SmellyGeekBoy 8y ago

> ...it's crazy how much effort is wasted because everybody is writing separate mission control, monitoring and data analysis applications that do 95% of the same things, each with its own horrendous UX/UI, idiosyncrasies and bugs. Heh, sounds like they have a lot in common with JavaScript frameworks and web development in general. With this observation in mind I doubt making mission control "web based" will rectify the situation...

tekkk 8y ago
What do you mean? I save a lot of time in web development using solutions created by others. I don't think this problem is unique to JS/web development but to software development as a whole. "Not invented here" syndrome is quite prevalent in a lot of areas and sometimes lack of options doesn't mean it will make the product any better. Quite the contrary it can mean that everyone is using the same buggy solution because there are no alternatives. I do not know the details of mission control technology but my uneducated guess would be that this is a cultural/management problem in these organizations. Top-down hierarchy with very large resistance to change would make introducing of new ideas (open source solution in this case) a tough job for any single actor. Also the IT-contractors or companies benefitting from selling these solutions are probably doing everything they can to keep the status quo as it is.
- TeMPOraL 8y ago
  > What do you mean? I save a lot of time in web development using solutions created by others. How much time do you lose keeping track of those solutions and their dependencies? The JS world has probably the hugest fragmentation problem in software history. Every level in the stack is rapidly evolving, constantly spawning multiple half-baked alternative solutions to the same problems. I think GP's point is simply that if similar things are happening in NASA on small level and are considered a problem, then switching to a technology ecosystem that is a living embodiment of those issues isn't going to help.

_pmf_ 8y ago

> I'm not in that industry anymore It's the same in automotive industry (development and end-of-line-testing) (XCP and MDF helped, but ultimately devolved into a meta-standard for vendor specific functions) and in the rest of the industry I've had contact with (cooling, heating), fragmentation is as bad as ever. Standardizing on web standards will probably follow the pattern of making of adding another layer that is worse than anything in the previous 30 years.

itronitron 8y ago

if it makes you feel any better, just look at how many VC funded startups are basically doing the same thing in any given space