That said, "[...]fairly boring stuff to anyone but myself." is at least the old defeatist "I've got nothing to hide" attitude when it comes to privacy intrusion, and chances are that Google can get interesting information from what you consider to be boring.
That's interesting. Do you let your whole extended family use your account, distorting Google's Skynet's model of you? You shouldn't do that, their business model depends on having a digital clone of everyone! It's probably even against their ToU.
To be fair, they're working on it, trying new stuff. Holacracy, various attempts at being "agile".. Not all of them are working out, but trial and error is the only thing they can do.
It is true of course that in traditional hierarchal organizations blame goes up, making management responsible. But as you said, that is an industry wide phenomena, so the (widely acknowledged, also by managers) problem has to be deeper. For example, Holacracy (which I only learned about yesterday, so my information on that is sketchy at best) tries to address the issue on the organizational structure, trying to fix the problem on that level. Could work, who knows.
My point is that managers can't do their jobs without the metrics you already mentioned, and the evidence suggests they cannot get those on their own. Research might help, otherwise we could end up in an endless loop of trial and error ("maybe this time it works out!"). I don't know if there is anything being done in academia, but it would seem to make sense.
No Man's Sky has still to see the light of day, Star Citizen is a giant cash cow even before release, with in my opinion no hope of matching the massive expectations. Robertson is probably better off to never release it and when the virtual star ship market runs dry, retire to some private island.
Refreshingly nuanced comment, taking the blame from the whipping boy marketing. But then you're saying management is to blame, while at the same time acknowledging that they don't have the tools to do their job correctly.
Useless VPs? I have yet to meet such a person. On the other hand, I have met a lot of engineers who seemed to feel they understood the whole world and everything within it, and considered management to a useless waste of time and money. Those were usually the ones who needed management the most, as they were completely oblivious to business considerations - which in the end puts food on their tables.
First off, it's not a either the software or the sysadmins. Lots of things can break in between, I suppose that's especially true when there are strict processes in place, as I imagine the workings of an airline company. That said, I've worked with Atlassian products (lots of Jira, Confluence, and Fisheye, but only a little Stash), and while I'm not a big fan (I find them bloated), I can't complain about their stability. Our admin team wasn't especially large, one could say understaffed, so I doubt they could afford to invest much time into its maintenance.
Okay, Testlog looks like an awful proprietary Windows-native tool. But if you can find a TCM with your required feature set and a documented API, it shouldn't be too big of a deal to make an own Jira plugin that interacts with that hypothetical TCM. Maybe Testrail has those features?
Watches have been at least in large parts fashion accessory for a while now, their convenience factor not necessarily being what sells them. Especially their upscale incarnations. From what I know of Apple's watch, the convenience takes even more of a backseat with its short battery life and very high price.
That really leaves this to be something primarily used by rich people to show off their wealth, like for example Rolex watches. Maybe unluckily for Apple, Rolex watches probably do last multiple generations, while, as you said, Apple's watch will be outdated much quicker than that.
I agree, they're really following up on this "cater to the rich guys" business model. Though even though I like some of Apple's products, part of me would really like to see this product to fail. Bring Apple back from being a fashion accessory to a tech company.
While I agree that this character assassination, especially with the guy's last name included and therefore the whole family involved, is not a good sign for the general journalistic integrity.
However, you are forgetting another crucial piece of evidence, the descent rate, which we have from radar data. It seems to be consensus on every source I read, that the very smooth descend rate must be autopilot controlled, and setting the autopilot's target altitude is pretty involved, and must be done intentionally.
That said, yes, they were very fast with laying the blame on the co-pilot. Disturbingly so. Let's hope the investigation will actually continue, though the plane was disintegrated, and the they're even publicly saying that the second recorder might never be found.
That relies on using exactly the same tools for the entire build chain. Which might be hard or impossible to get, and of course also need to be trusted.
The user's experience of the many interfaces of a system. E.g., as software nowadays comes, there is an (remote) backend, multiple frontends (apps, API, administrative tools). UX usually focuses on the end-user facing frontends, but those also come along with different interfaces as they have to integrate into different platforms.
Strictly speaking, yes, "user interface" could mean the sum of all those interfaces. But that's not the traditional meaning of the term.
Let me guess, you're writing these lines from the comfort of your air conditioned home office?
Give the man a break, he's had more impact than close to everyone on this site will ever have. And now he's in Russian hands, who have can easily blackmail him into anything.
What you're arguing against is might not be what the parent stated. Yes, proving your software is working correctly is hard, very hard. Not possible for an individual developer in a real life situation (limited time, resources, formal education in mathematics - what are you doing writing commercial code when you're a mathematician?). That's one of the issue what I believe the parent wanted to mitigate with improved development tools, which also need to be bug free of course. At some level, the building blocks need to be proven to work correctly, you're right there. But that's should not be for the feature developer to do, he should be able to rely on the tools he's given.
Yes, I agree with the parent, software development is way to hard at the moment, the analogy "It's as if engineers decided to only use modeling clay for buildings, because nobody sells steel, and it's too cumbersome to smelt their own." holds true and seems to fit with what you're saying.
It is pretty common to blame users for system malfunctions. And often, that turns out to be correct. However, you being here, chances are you somehow involved in software development and its processes, and have experienced many of its failures. Here, we're talking about software people bet their life on. I do think it's warranted to look very closely and actually rule out that the failure was a technical one, and I find it difficult to imagine an argument against that.
Or... maybe that's the pro-nuclear lobby portraying such easily refutable claims as the anti-nuclear agenda in order to discredit them..? Such tin-foil-hat-esque theories have lately proven to be closer to reality than I would like them to be.
At what step in your mulit-tiered review system does it usually occur to that you're not writing for publishing, but partaking in a online discussion? How often did you decide your phrasing does not fit the purpose and started over? How often did the discussion move along to other sub-threads and your carefully worded post ignored?
You make some good point. Howevr, imagine the following not uncommon scenario:
1. A small number of experienced developers starts a project
2. The devs choose to build their own framework for the reasons you describe
3. PM wants ever more features, the project grows, more developers join
4. All new code is build on the framework made in step 2
5. Framework is extended
6. Original devs leave
So now everyone can use the framework, but it's original devs stopped maintaining it. Everyone know how to use the framework, but nobody knows its inner workings well enough - we have a custom, still lightweight framework tailored for the job, but nobody's maintaining it. The worst of both worlds, a framework maintained by people you can't rely on to understand it and fix its bugs, and the initial investment to build it in the first place.
In the end, you're right, there is no clearly defined criteria for which approach is better than the other, both ways has a very good chance to bite you in the ass. My perspective however, not as a developers of production systems but a software testing engineer (writing code to break other people's code;)), what I see is bugs, bugs everywhere. Hardly any new feature, however straight forward it appears in its original specs, that's not can of worms of new and exciting issues. That's why I'm very skeptical of using new code when existing, already tested code exists.
This is hard to prove or disprove. Sure, throwing some huge framework on a small problem is not a sensible approach. Seems like a no-brainer. But where to draw the line? A real life application constantly grows, and has a good chance to eventually use a growing percentage of the features exposed by a given framework. If you know your application will not outgrow its initial specs (in an unexpected way), it might make sense to opt for an own framework.
My personal experience, however, is that developers too often opt for their own solutions, maybe due some kind of not invented here syndrome, and duplicate a lot of work. That is bad in a lot of ways, as a well maintained framework with multiple developers and documented bugs is always preferable to completely new code.
Slashdot Mirror
+1
That said, "[...]fairly boring stuff to anyone but myself." is at least the old defeatist "I've got nothing to hide" attitude when it comes to privacy intrusion, and chances are that Google can get interesting information from what you consider to be boring.
That's interesting. Do you let your whole extended family use your account, distorting Google's Skynet's model of you? You shouldn't do that, their business model depends on having a digital clone of everyone! It's probably even against their ToU.
I think the same amount of truth can be found in:
"If you see useless people all around, you're own usefulness demands scrutiny."
To be fair, they're working on it, trying new stuff. Holacracy, various attempts at being "agile".. Not all of them are working out, but trial and error is the only thing they can do.
It is true of course that in traditional hierarchal organizations blame goes up, making management responsible. But as you said, that is an industry wide phenomena, so the (widely acknowledged, also by managers) problem has to be deeper. For example, Holacracy (which I only learned about yesterday, so my information on that is sketchy at best) tries to address the issue on the organizational structure, trying to fix the problem on that level. Could work, who knows.
My point is that managers can't do their jobs without the metrics you already mentioned, and the evidence suggests they cannot get those on their own. Research might help, otherwise we could end up in an endless loop of trial and error ("maybe this time it works out!"). I don't know if there is anything being done in academia, but it would seem to make sense.
No Man's Sky has still to see the light of day, Star Citizen is a giant cash cow even before release, with in my opinion no hope of matching the massive expectations. Robertson is probably better off to never release it and when the virtual star ship market runs dry, retire to some private island.
Refreshingly nuanced comment, taking the blame from the whipping boy marketing. But then you're saying management is to blame, while at the same time acknowledging that they don't have the tools to do their job correctly.
Useless VPs? I have yet to meet such a person. On the other hand, I have met a lot of engineers who seemed to feel they understood the whole world and everything within it, and considered management to a useless waste of time and money. Those were usually the ones who needed management the most, as they were completely oblivious to business considerations - which in the end puts food on their tables.
First off, it's not a either the software or the sysadmins. Lots of things can break in between, I suppose that's especially true when there are strict processes in place, as I imagine the workings of an airline company.
That said, I've worked with Atlassian products (lots of Jira, Confluence, and Fisheye, but only a little Stash), and while I'm not a big fan (I find them bloated), I can't complain about their stability. Our admin team wasn't especially large, one could say understaffed, so I doubt they could afford to invest much time into its maintenance.
I'm not talking about a whole tool, "just" an interface. Still, it'll be more than 99, definitely.
Ah, troll mods roaming freely. Think nothing of it.
Okay, Testlog looks like an awful proprietary Windows-native tool. But if you can find a TCM with your required feature set and a documented API, it shouldn't be too big of a deal to make an own Jira plugin that interacts with that hypothetical TCM.
Maybe Testrail has those features?
Watches have been at least in large parts fashion accessory for a while now, their convenience factor not necessarily being what sells them. Especially their upscale incarnations. From what I know of Apple's watch, the convenience takes even more of a backseat with its short battery life and very high price.
That really leaves this to be something primarily used by rich people to show off their wealth, like for example Rolex watches. Maybe unluckily for Apple, Rolex watches probably do last multiple generations, while, as you said, Apple's watch will be outdated much quicker than that.
You don't strike me as part of their target audience. So, why would they care?
I agree, they're really following up on this "cater to the rich guys" business model. Though even though I like some of Apple's products, part of me would really like to see this product to fail. Bring Apple back from being a fashion accessory to a tech company.
While I agree that this character assassination, especially with the guy's last name included and therefore the whole family involved, is not a good sign for the general journalistic integrity.
However, you are forgetting another crucial piece of evidence, the descent rate, which we have from radar data. It seems to be consensus on every source I read, that the very smooth descend rate must be autopilot controlled, and setting the autopilot's target altitude is pretty involved, and must be done intentionally.
That said, yes, they were very fast with laying the blame on the co-pilot. Disturbingly so. Let's hope the investigation will actually continue, though the plane was disintegrated, and the they're even publicly saying that the second recorder might never be found.
That relies on using exactly the same tools for the entire build chain. Which might be hard or impossible to get, and of course also need to be trusted.
The user's experience of the many interfaces of a system. E.g., as software nowadays comes, there is an (remote) backend, multiple frontends (apps, API, administrative tools). UX usually focuses on the end-user facing frontends, but those also come along with different interfaces as they have to integrate into different platforms.
Strictly speaking, yes, "user interface" could mean the sum of all those interfaces. But that's not the traditional meaning of the term.
Let me guess, you're writing these lines from the comfort of your air conditioned home office?
Give the man a break, he's had more impact than close to everyone on this site will ever have. And now he's in Russian hands, who have can easily blackmail him into anything.
And the rest of the world either inclined to sell him out to the US, or not letting him immigrate in the first place.
o_O
What you're arguing against is might not be what the parent stated. Yes, proving your software is working correctly is hard, very hard. Not possible for an individual developer in a real life situation (limited time, resources, formal education in mathematics - what are you doing writing commercial code when you're a mathematician?). That's one of the issue what I believe the parent wanted to mitigate with improved development tools, which also need to be bug free of course. At some level, the building blocks need to be proven to work correctly, you're right there. But that's should not be for the feature developer to do, he should be able to rely on the tools he's given.
Yes, I agree with the parent, software development is way to hard at the moment, the analogy "It's as if engineers decided to only use modeling clay for buildings, because nobody sells steel, and it's too cumbersome to smelt their own." holds true and seems to fit with what you're saying.
It is pretty common to blame users for system malfunctions. And often, that turns out to be correct. However, you being here, chances are you somehow involved in software development and its processes, and have experienced many of its failures. Here, we're talking about software people bet their life on. I do think it's warranted to look very closely and actually rule out that the failure was a technical one, and I find it difficult to imagine an argument against that.
Or... maybe that's the pro-nuclear lobby portraying such easily refutable claims as the anti-nuclear agenda in order to discredit them..? Such tin-foil-hat-esque theories have lately proven to be closer to reality than I would like them to be.
At what step in your mulit-tiered review system does it usually occur to that you're not writing for publishing, but partaking in a online discussion? How often did you decide your phrasing does not fit the purpose and started over? How often did the discussion move along to other sub-threads and your carefully worded post ignored?
You make some good point. Howevr, imagine the following not uncommon scenario:
1. A small number of experienced developers starts a project
2. The devs choose to build their own framework for the reasons you describe
3. PM wants ever more features, the project grows, more developers join
4. All new code is build on the framework made in step 2
5. Framework is extended
6. Original devs leave
So now everyone can use the framework, but it's original devs stopped maintaining it. Everyone know how to use the framework, but nobody knows its inner workings well enough - we have a custom, still lightweight framework tailored for the job, but nobody's maintaining it. The worst of both worlds, a framework maintained by people you can't rely on to understand it and fix its bugs, and the initial investment to build it in the first place.
In the end, you're right, there is no clearly defined criteria for which approach is better than the other, both ways has a very good chance to bite you in the ass. My perspective however, not as a developers of production systems but a software testing engineer (writing code to break other people's code ;)), what I see is bugs, bugs everywhere. Hardly any new feature, however straight forward it appears in its original specs, that's not can of worms of new and exciting issues. That's why I'm very skeptical of using new code when existing, already tested code exists.
This is hard to prove or disprove. Sure, throwing some huge framework on a small problem is not a sensible approach. Seems like a no-brainer. But where to draw the line? A real life application constantly grows, and has a good chance to eventually use a growing percentage of the features exposed by a given framework. If you know your application will not outgrow its initial specs (in an unexpected way), it might make sense to opt for an own framework.
My personal experience, however, is that developers too often opt for their own solutions, maybe due some kind of not invented here syndrome, and duplicate a lot of work. That is bad in a lot of ways, as a well maintained framework with multiple developers and documented bugs is always preferable to completely new code.