|
The work can have significant applications in cognitive disorder treatment and post-stroke rehabilitation. 'Oh, so you're thinking of turning me off?'
|
|
|
|
|
The Hack_Right program aiming to help young hackers avoid cybercrime and use their skills for good has received a pledge of support from about 20 companies. "There is no right or wrong, just fun and boring."
|
|
|
|
|
Microsoft’s focus as a company is on productivity, but a recent experiment by Microsoft Japan suggests with a 4-day workweek we may be more productive if we work less. Me too
If I'm 40% more productive with a 3-day weekend, imagine how productive I'd be with a 6-day weekend!
|
|
|
|
|
With regards to software development, productivity is an entirely subjective concept.
It's entertaining and somewhat disheartening to read some of the definitions of productivity:
Quote: the state or quality of producing something, especially crops.
okaaaay.
Quote: the effectiveness of productive effort, especially in industry, as measured in terms of the rate of output per unit of input.
Unit tests anyone?
And my favorite:
Quote: the rate of production of new biomass by an individual, population, or community; the fertility or capacity of a given habitat or area.
Wikipedia has an interesting definition:
Quote: Productivity describes various measures of the efficiency of production. Often, a productivity measure is expressed as the ratio of an aggregate output to a single input or an aggregate input used in a production process, i.e. output per unit of input, typically over a specific period of time.
The thing is, the concept of "input" and "output" with regards to productivity is highly abstract when it comes to defining productivity for software development. Input can range from someone saying "this needs to be done" to a full blown spec. Output can be anything from a bug fix to an entire application.
Because of this wildly ludicrous range, we have scrum and agile methodologies which create sprints, breaking down "productivity" into more chewable (but not necessarily more digestible) units:
Quote: A sprint is a short, time-boxed period when a scrum team works to complete a set amount of work.
And it accomplishes this by forcing an arbitrary time interval to the work from which, again somewhat ludicrously, the team's "velocity" can be measured to create nice graphs for the venture capitalists that are keeping the sinking ship from, well, sinking.
And because only so much can be done within a fixed time period, we have "iterations" and "refactoring" and "only do the minimal amount necessary to get the task in the sprint done." So velocity looks good on paper, but does anyone measure how many times the same piece of code (and its dependencies) get refactored over a thousand or ten thousand sprints because the task wasn't given enough time to do it right in the first place?
Of course the solution to that is to decompose the task into, you guessed it, smaller tasks which are "sprintable." Rinse and repeat until you get a tower of babbling developers, project managers, and C-level managers, each speaking in unrecognizable tongues to the others.
Outsourcing addresses this bottomless pit by getting rid of costly developers and hiring droves of cheap developers that have laser focused myopic vision (see post below on the 737 Max) which results, if you're lucky, in a failed product, and if you're less lucky, death. Of the project, of people, of the company, of the management, any and all of the above.
So how do we then measure developer productivity? Let me ask a different question. Why should we measure developer productivity?
The productivity of developers is meaningless before the product hits the market. How can you measure "input" and "output" when the damn thing isn't even generating any money? Charts of velocity are useless, at best they might tell you when your money is going to run out or when the VC's are going to pull the plug. I feel my argument is weak here, but I stand by the premise.
The productivity of developers after the product hits the market and is generating revenue might be measurable against certain criteria, such as sales and customer satisfaction. It is also easier to perform sprints on an existing product that is in its maintenance cycle rather than its development cycle because maintenance is mostly tooling improvements, bug fixes and specific new features and the eternal pendulum swing between fragmented (microservices, serverless, etc) and monolithic architectures.
Using sales as a criteria becomes useless when you have a monopoly, or more PC, "cornered the market." Or you have enough money to buy your competition. Customer satisfaction? Who really cares as long as you're making sales?
So how then do we measure productivity? Simple. How much money did I make today vs. how much did my developers cost today? If that ratio is > 1, someone (not necessarily your developers) is productive. It could even be the consumer, being productive enough in whatever they do to afford your product, be they person, collective, corporation, or government. If that ratio is < 1, then you have a productivity problem. Somewhere. Not necessarily your developers. Maybe the consumer isn't buying enough of your product due to an economic downturn. Or simply that your product sucks.
The only time you can actually measure developer productivity is when the company is too small to have a gaggle of managers, a shoal of lawyers, and a murder of sales "engineers", on a product already bringing in revenue.
In other words, a startup company that has succeeded in making some sales, usually to corporations or government which will pay for maintenance contracts (hence some revenue stream after the initial sale) and that is most likely growing too fast and too hard and can't keep up with the customer requirements and bug fixes but hasn't yet hired the gaggle, shoals, and murders that a well greased "where did my productivity go?" company requires.
Which brings me to my Alice in Wonderland conclusion, that developer productivity can only be measured in that awkward, painful, stressful, and insane period when a company has "hit it" but hasn't "gotten it", there is a minimal amount of obfuscation between the customer and the developer, the backlog of work is far beyond what the current team can accomplish without the tech to transfer brains upon death, and productivity is measured against "this has to get done by Friday or we lose the customer or sale." In that specific circumstance, productivity is easy to measure. You either succeeded to keep the customer or make the sale, or you failed. Binary. Black and white. You succeeded in producing the output or you didn't. You were productive or you weren't.
One final rabbit hole. Developer productivity is also meaningless because it assumes a manufacturing style of "input" and "output" over a given time period. Software isn't like that. It might take years to write a Google or Facebook, but once it's done, well, it's done. The "consumption" of the product is a web link or a 30 second download (unless you're Microsoft.) So how the heck do you measure productivity now when once the product (the software) is produced, the "output" is little more than a click that clones onto your hard drive (if even that) the pattern of 0 and 1 bits that define the product? Wow, my developers are insanely productive! We've had a million visitors to our site this year!!!
Which gets us to the evil of productivity -- is Marc more productive than Joe? Meaning, given similar tasks, does Marc get the job done faster and with similar "accuracy" than Joe, or not?
Which, going back to my Alice in Wonderland scenario, is not an issue when your developers are "expert islands" and the developer to island ratio is 1:1. You have no basis for comparison until your company get passed that birth process and the developer to island ratio is 2:1 or more.
And this ratio, by the way, defines "job security" vs. "eek, I'm replaceable", and therefore drives developers to be perceived as productive when in the "eek, I'm replaceable" corporate structure. Fortunately, there are many islands and the key to success (both for the developer and the corporation) is to have a healthy balance in the developer:island ratio, because developers want to feel unique and valued and not a cog in the machine, but a healthy level of stress and knowledge sharing is also socially rewarding. Which, in terms of psychology, makes for a happier and more productive developer! And ironically, in a corporate environment, leads to the conclusion that only the developer can tell you whether he/she "feels" productive and to what degree, so you're productivity measure in that scenario becomes entirely subjective. Which was the first sentence in this tome that just killed your productivity. 
modified 3-Nov-19 20:36pm.
|
|
|
|
|
Fitbit will develop Made by Google wearables for Wear OS, should the deal close successfully. Congratulations on taking 5000 steps. Here's an advertisement for ice cream.
|
|
|
|
|
|
Om my .. this story is really perplexing, unbelievable and logical at the same time...
|
|
|
|
|
0) It's the fault of the engineers for not specifying in the MCAS requirements that cross-checking systems was necessary.
1) It's Boeing's fault for OUT-SOURCING the development to Indian developers who barely know what a f*cking airplane even is, much less that have anything resembling even passing familiarity with avionics.
2) It's Boeing's fault for not sending aviation engineers to monitor the developers' work. THOSE would have been the guys to stand up and say, "Hey, this ain't right!"
3) It's Boeing's fault that management placed more importance on money than on safety. This probably led to "shortcuts" being implemented in order to meet unreasonable schedules. When presented with the age old conundrum regarding cost, features, and time, and that you can meet two of those three critreria, they practically stampeded to cut features in the interest of cost and time.
4) This is a very good example of how management screws up software, and then tries to blame the developer instead of management. I bet management all still got their huge-ass bonuses, too.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
I hope you read the article.
|
|
|
|
|
Yeah, I read the article - they tried to fix bad hardware with software, and failed. Earlier articles on the subject tried to lay the blame at the feet of the programmers, but I (and every developer here) knew it was bullsh*t from the start.
0) Boeing screwed up the aerodynamics because they were trying to avoid the "not a 737 anymore" problem, because IT COST LESS MONEY.
1) Boeing decided to fix it with software, because it COST LESS MONEY
2) They outsourced the software development to India, because it COST LESS MONEY
3) All the things that happened as a result of or that caused the three items above were done to REDUCE COST TO BOEING.
4) Money over safety - same sh*t, different day.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
#realJSOP wrote: They outsourced the software development to India, because it COST LESS MONEY
Nowhere is it mentioned that they outsourced MCAS to India. They might have outsourced Payroll, HR or such non-technical stuff to India, not something as critical as MCAS, certainly not at $9 per hour.
modified 4-Nov-19 7:19am.
|
|
|
|
|
It was revealed in an article about it. No, I don't have a cite.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
I did critical Food & Beverage (and pharmaceutical) inspection software for 9$ / hour.
GCS d--(d+) s-/++ a C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
#realJSOP wrote: Indian developers who barely know what a f*cking airplane even is, much less that have anything resembling even passing familiarity with avionics
I am not sure whether such sweeping statements can be made.
A small example is that Aerospace Engineering, Indian Institute of Science, Bangalore[^] was formed in 1942, much before most of us were born.
|
|
|
|
|
I've been the victim of outsourcing twice, so I claim the right of extreme sarcasm.
To your point, establishing ANYTHING that happened in 1942 as a rebuttal is beyond bullshit, because NO programmer alive today has more extensive subject matter knowledge regarding avionics than an avionics engineer (unless of course that programmer has been an avionics programmer for a long enough period to be able to raise pertinent objections to the specifications).
The whole thing is still Boeing management's fault. The programmers did what they were told to do, the way they were told to do it.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
Quote: NO programmer alive today has more extensive subject matter knowledge regarding avionics than an avionics engineer
I worked for a large British plane maker (that will remain nameless but you can probably guess) for 7 years. I worked in Flight Test Data Processing working on jet fighters so you would think I know a lot about flight engineering and avionics. I didn't. I worked with a couple (and occasionally more) aviation engineers to develop an expert system to analyse flight tests - however, the engineers specified the formulas, constants and other criteria that I used. I was an aeroplane nut at the time - getting my pilot's licence - but I still didn't know what half the stuff was. I was still able to build the test analysis framework very successfully (it was still in use 17 years after I left the company) so that these engineers could specify want they wanted without any "intelligence or subject knowledge" built into the program at all. It's not always needed to develop an expert system - as long as you have a couple of actual experts guiding you along!
- I would love to change the world, but they won’t give me the source code.
|
|
|
|
|
Forogar wrote: It's not always needed to develop an expert system - as long as you have a couple of actual experts guiding you along!
And that's xactly his point #2 in the first message
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
|
Funny how, if you squint, it looks a lot like Chrome's logo. 
And for a browser called "Edge", it has no edge, which one usually thinks of as a straight line. 
|
|
|
|
|
Well that's certainly going to make installing Chrome on a new PC harder. 
I'm not sure why MS thinks making their own browser harder to find leaving the system appearing to not have one installed at all is supposed to help anything at all though. 
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
|
|
|
|
|
The human brain can recognise a familiar song within 100 to 300 milliseconds, highlighting the deep hold favourite tunes have on our memory, a UCL study finds. Think of how much time top 40 radio stations could save!
Duh duh DUH
duh duh da-DUH
|
|
|
|
|
..and then you need up to 40s to remember the lead-singers name.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
It's thought that stars began appearing in the first 100 million years after the Big Bang, and we've seen some really old stars; but the processes that created them from the primordial Universe soup are a big mystery. "It doesn't matter how beautiful your theory is, it doesn't matter how smart you are. If it doesn't agree with experiment, it's wrong."
|
|
|
|
|
Kent Sharkey wrote: If it doesn't agree with experiment, it's wrong
Are you implying the universe is just a big experiment?
|
|
|
|
|
Well, it is wrong. 
TTFN - Kent
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
