How software development managers can do their part to stop and reverse the quiet crisis unfolding in software development leading to low quality applications, unhappy employees and unhappy users.
The reason I'm sharing this is because over the last ten to fifteen years I've noticed a quiet crisis unfolding in software development leading to low quality applications, unhappy employees and unhappy users. Silver bullet solutions keep creeping into our awareness (Scrum, anyone?) and predictably keep letting us down.
This is almost entirely the fault poor management — or perhaps it should be called fad management. In the past I was to blame as much as anyone until I discovered and refined a basic set of practices that for the most part cause everything else to fall into place — at least in my experience. No promises. Here we go.
(Score: 5, Insightful) by Nerdfest on Sunday May 29 2016, @02:17PM
I wouldn't blame it it on 'scrum', in fact, in my experience, Agile development is one of the few things that's actually done a bit to keep users happy and raise the general quality of larger applications. Again, in my experience,what has caused the most damage is the 'enterprise' approach to software, using heavy up-front documentation, paper deliverables (never to be used again), heavy process for making and deploying changes, etc. All of this combined of course with a poor set of requirements, which I think we should know by now is to be expected and needs to be considered in the development process.
Of all of the systems I've worked on, the best by far for user satisfaction, developer happiness, and general quality have been those where the team is kept as small as possible, processes has been kept to an absolute minimum, and the developers worked directly with the users.
I'm not sure if things have actually become any worse than they used to be these days, as even in the old days most software was crap and most users had very low expectations, but we now have great tools and great languages and things really haven't become much better, although perhaps expectations have been raised as a *few* companies seem to manage to get things right, generally by doing what I've described above.
(Score: 3, Interesting) by Anonymous Coward on Sunday May 29 2016, @05:05PM
Scrum is neither the answer nor the problem, in my experience. (Full disclosure: certified, and currently running a scrum team. Also educated in regular, classical project management, and have done that in the past.)
If your userbase is hopeless at expressing what they want, and why, without a team of psychologists on hand to help them express their feelings, your product owner will not be able to actually communicate anything useful to you. "We want a ... we want a spreadsheet-sort of thingy. Where we can enter our market project numbers. Why are you asking for more explanation? We just told you! Now stop bothering us!" This happens more often than you think. Sure, you can burn a few sprints making something that kind of looks like what they said, and then make them complain about it - but by then you're also burning all your goodwill.
Classic project management can work very well, including for development work, if what you are doing is stable core work. You know you're going to have a Postgres database, you know you'll be using Cassandra on the side for some data mining use cases, you know you'll be exporting reports in CSV format .... and so on and so on.
Use the method that works for your scenario. Another problem is the maintenance environment. Most Scrum work assumes that a bug is a pretty well-defined thing to which you can provide a well-defined answer. There's no room in scrum, as conventionally described, for a two week, in depth analysis of the logical chain that led to a complex set of problems, and a further reanalysis of the design. You sort of stumble into it - or never do it at all. If you're slapping together the next Grindr for the AKC, who cares? If you're building software for a hospital's trauma unit, the stakes are just a teensy-weensy bit higher.
As for your comment about tool improvement and so on, I heartily disagree. Tool bloat is one more thing that has removed developers from the nitty-gritty of what they're doing and why. But it's so tiny and nitty-gritty! It doesn't matter ... except when it does.
There is no one right answer. Each project needs its own balance. But organisations that do not plan intelligently for maintenance are organisations that produce really crappy software that stays crappy forever.
(Score: 2) by Appalbarry on Sunday May 29 2016, @06:38PM
"If your userbase is hopeless at expressing what they want,"
It's not your users' job to tell you what's needed, it's your job to listen, ask questions and help them to explain to you what they're seeking.
This is critical front-end work, usually iterative, which can help to avoid confusion and dead-ends.
If no-one on your team has the skills to do this, hire someone who does.
End users will invariably start by describing what they've used before, with some minor flourishes.
That's not of much value.
You need to know what already works well, what doesn't, and most importantly what features, tools, or attributes - or hoped for outcomes - would genuinely improve their work environment.
It's far too easy to look down our noses at Users when in fact their difficulty reflects bad design and implementation choices.
(Score: 4, Insightful) by Anonymous Coward on Sunday May 29 2016, @07:02PM
You're completely missing the point.
The point isn't that one can't engage in a guided information-gathering exercise. That's written into the assumptions.
The point is that this takes time (which users can refuse to dedicate to the purpose), commitment (which no force on earth can require users to provide) and some ability to express what they want (which can be very difficult and require introspection on their parts, which people can actually refuse to do).
If you do not have the power, authority, blackmail material or "juice" to get the users on board with more than anything beyond: "I want perfection, not to think about it!" all the scrumminess in the world won't get you a good product. Similarly, if users come to your product reviews with "It sucks and I don't like it but I won't tell you how it could be better." your incremental improvements will turn into a guessing game where you try to read their minds. These considerations go double when office politics give them an incentive to sabotage you.
Under those conditions you're actually better off with classic waterfall project management, because if you don't get buy-off, the project stops in its tracks and you go elsewhere to do something else. Bear in mind that considerations such as the minimum viable product definition are just as useful in waterfall as in scrum processes.
I'm not looking down my nose at users here. They're invaluable allies. I'm explaining that they can also be, quite deliberately, your worst enemies for no reason that you can ever control, or just simply so helpless, harried, and passive-aggressive that nothing short of sponsored therapy is going to get anything useful out of them.
(Score: 0) by Anonymous Coward on Monday May 30 2016, @08:42AM
getting inside a user's head is a skill
some have it, many don't
if you assume that users give a rats about what developers want or need, it is you that is missing the point
(Score: 1) by kurenai.tsubasa on Monday May 30 2016, @04:41PM
This still misses the point. Getting inside the user's head is something that the user can shut down at any time. Sure, there are those who don't have the skill and end up shutting down users because they fail to completely engage the user and learn what it is he's hoping to do.
There's a complication here in engaging end users that nobody wants to face. My job essentially is to eliminate jobs. If it looks to any particular user like it's their job I'm going to automate away, boy howdy, you betcha they're going to be throwing sabots all over the place!
That's what GP's point about “power, authority, blackmail material or ‘juice’” is really speaking to. If I do my job correctly, it needs to be a top-down decision with management's eyes wide open that we are going to eliminate jobs. That's the entire point of the exercise! Some of the individuals whose jobs were automated may be flexible enough to evolve into a new position. They won't be happy that their job is no longer manually copying data from spreadsheet A to spreadsheet B and cross-referencing policy C by hand, but they'll still be employed. The ones you really have to watch out for are the ones who know they simply don't have the capacity to do anything else than some mindless procedure. I am a direct threat to those people.
It's really night and day between when I'm on a team that's building something entirely new that doesn't threaten anybody's job (except in some theoretical sense since we're providing something that the client would otherwise need to hire additional labor to do) and when I'm on a team that will eliminate existing jobs.
There really are people out there who don't have the capacity, be it brains or creativity or whatever, to do a job that isn't a straight-forward mindless task. Until we figure out what to do with them, the problems with software are just going to get worse and worse.
That doesn't even speak to multi-million dollar boondoggles when giants like SAP get involved. It's as though a million government bureaucrats realize their jobs are about to be automated away, and they scream out in terror. I've never been involved in one of those projects, but I imagine the sabots being flung blot out the sun!
(Score: 1) by khallow on Tuesday May 31 2016, @03:03AM
What I do think has changed is that it is more likely than ever before for projects to fail due just to the intellectual weaknesses (ignorance, inability to understand, incompetence) of sincere participants. Appalbarry has an important point here. Having someone who can ferret out actual user needs can overcome a lot of user ignorance and incompetence. I think such a skill will prove to be even more useful in the future as the complexity and sophistication of the available tools continues to exceed the would-be users' collective grasp.
(Score: 0) by Anonymous Coward on Monday May 30 2016, @10:45PM
Which head did the developers get into when forcing Unity and Australis upon all of us? Maybe there was 1 lone user who wanted to have all enjoyment crushed out of him, and the devs just happened to get in his head.
(Score: 3, Informative) by turgid on Sunday May 29 2016, @07:50PM
Isn't that what a spike is? Something you can't estimate an accurate timescale for, that requires investigation? So you can break it down into general areas to investigate, and iterate until you get to a root cause and then design a fix, at which point you can do stories and tasks. Then apply planning poker...
If your manager won't let you do that, on the other hand, that's not a failure of Scrum, it's a failure of bone-headed PHB (there are lots of them about).
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 0) by Anonymous Coward on Sunday May 29 2016, @08:56PM
Sure, that's a spike. You're quite right.
Problem: when your environment is largely driven by "We need to ship this when marketing says we have to hit a trade show" then that doesn't happen any more.
This even happens in the medical informatics field (been there, done that) and the developers saying: "Guys, there's this edge case we need to sort out." rarely cuts much ice. I've been on the losing side of that argument more than the winning. The usual answer is: "We won't tell anyone it's broken, but we need to get these shiny features in for the conference headliner."
Just experience from the trenches.
(Score: 1, Insightful) by Anonymous Coward on Sunday May 29 2016, @09:19PM
when your environment is largely driven by "We need to ship this when marketing says we have to hit a trade show" then that doesn't happen any more.
At which point you are no longer agile. You are a date driven development. At which point scrumm methodology becomes a hindrance if you dont clean out your backlog and communicate to your stakeholders. Scrumm sorta fits that model. But not very well. Waterfall most certainly does not fit it.
Realistic expectations and goals are baseline for any methodology you use. If you say 'make me an OS in 2 days' I would tell you 'that is not going to happen at all'. You may get mad but guess what it is not realistic. Then you come back and try to turn it around on me (because you still are not being realistic) 'what is a realistic timeframe' I pick a number out of the air at that point and say 'at least 2 years'. Which you turn into 1 year as 'we are that good at what we do'. You then tell the CEO that and suddenly it is my problem meanwhile you get your bonus for 'bringing in the timeframe'. 2-3 years later I get let go because you didnt know what you were doing.
Poor decisions happen because of poor pushback on poor ideas with poor timeframes. Poor ideas may actually work. But usually come attached to a stupid timeframe that was made up.
I worked with a PM. He told me this rule of thumb and it has worked pretty good. If the dev has never done it before take the time given times 3. If he has done it before take it times 1.5. This is pretty good for most people but you have to test it and find out what that persons multiplier is. Everyone has one.
(Score: 1, Insightful) by Anonymous Coward on Monday May 30 2016, @01:57AM
You're not wrong ... but you're kind of wrong about reality.
I have never, ever, ever worked in a place where all the agile wishlist items came together. Not once in my whole career. And there are a hell of a lot of people who run whatever the hell they do by calendars. If not marketing, then legal. If not legal, then accounting, and so on. Someone can always, always, always tell you that their view of reality takes precedence regardless of how otherworldly it is, and in my experience that happens every time.
Waterfall has two massive advantages, assuming that you're in a waterfall place: first, you can put a date and magnitude on the injection of stupid, and point a documented finger; second, you can require that stakeholders sign off on a plan, and if they won't (or can't) agree on a plan, you can dust off your hands and tell them that there is no plan, thanks a lot and have a nice day.
Scrum has lots of advantages. However, it is not geared for failing fast, in terms of organisation. Often the problem is not the code, but the coding environment, and funnily enough that is where these things come up. If your every answer is to present a non-negotiable wishlist of items to perfectly match the Agile Way, or else shrug your shoulders and say this isn't Official Agile, so it's not Agile's fault, then you're right - but uselessly so.
(Score: 3, Insightful) by fleg on Monday May 30 2016, @03:05AM
>I have never, ever, ever worked in a place where all the agile wishlist items came together.
i have. since the turn of the century, with one exception, every job i've had they have come together. but then i avoid all "enterprise" type jobs and only go for engineering/medical/defence type stuff, places where what i build is their business not just something they need to help with their real business. so maybe that skews the results.
>Scrum has lots of advantages.
indeed, like giving you a hope in hell.
>However, it is not geared for failing fast, in terms of organisation.
i'm not too clear what you mean here, so i'll just mutter some stuff. ime scrum is viral wrt the organization. by that i mean that a fully functioning scum team will almost certainly make demands on the whole organization to become more agile. the old way of doing things just doesnt fit with the agile approach. what happens then is that either the organization changes or the scrum team withers on the vine. and its usually the latter. so in organizational terms/timescales i would say it fails "fast".
true, but its also true to say "dont blame agile (scrum) for failing if you didnt actually do it".
there is of course a middle ground, you can try to incrementally introduce the techniques, just dont expect it to be easy to do so.
(Score: 3, Informative) by fleg on Monday May 30 2016, @03:30AM
you say you're certified, but the above is simply not true.
1/ if you're doing 4 weeks sprints there certainly is time for a two week story, tho i would probably split it.
2/ if your'e doing 2 week sprints there is still time, but i would almost certainly split it.
3/ if your sprints are less than 2 weeks then definitely split the story.
all perfectly valid ways of doing scrum.
(Score: 0) by Anonymous Coward on Monday May 30 2016, @04:55AM
OK, granted, I expressed myself poorly. Let me try to clarify.
Yes (as I said above) you can, in principle, by collaboration with your product owner, and in cooperation with your user base, acknowledge the situation and work it as a spike, intended to recover from technical debt, as a structured series of technical stories that may very well expand as your open-ended journey of discovery permits you to gaze upon the full extent of the necessary refactoring work.
OK? Yes, I'm certified, and yes I acknowledge that in the full elaboration of how Agile and Scrum and all the rest of it is supposed to work, that is The Solution.
That isn't the problem.
That was never the problem.
The fact that that is ever necessary is well discussed in many books, seminars and training courses on Scrum.
If that were the problem, we'd all slap our foreheads, fix the everything, and have a beer.
The problem is that all the Agile goodness in the world doesn't make deadlines and related pressures disappear. If you need your crap out the door for the SHOT show, or NAMM, or E3, or Dragoncon, or the AGM, or the Grand Lodge's meeting, or simply because the end of the fiscal quarter is coming up and there's no budget for this in the next one, or because an idiot VP promised the CEO a blowjob-o-matic for Christmas, or because there's a penalty clause in a contract that says we hit the target date or the buyer gets to ride us bareback and make us smile for the camera, or because the law changes at 0:01 on January the First and the new stipulations become effective, or WHATEVER ...
... all your lovely plans about spikes and technical stories and technical debt become as useful as fairy-tales.
"But, but, but ..." I hear you say while your lower lips tremble and your cornflower blue eyes fill with tears "... the Agile Manifesto ..." at which point I stop listening because the Agile Manifesto is printed out on toilet paper in the executive restrooms.
The lack of time to which I referred is not a gap in Scrum. Scrum assumes that in each sprint's timebox you do all your story-type stuff to make that sprint, and then the next sprint, and the next sprint, and whatever comes up in a given sprint is whatever the Product Owner deems most valuable, and you stop working on that product when the product is Good Enough, or you run out of time, or budget, or whatever. Scrum assumes that the time you have is the time you get - but when a user story, or set of user stories, as defined to be the minimum viable product, comes with a due date that is externally imposed, nothing about Scrum helps you do the right thing rather than the expedient thing. All that it does is give you a list of what you did, and when you did it, and if that means that the debugging would take longer than you have, the debugging doesn't happen.
Again, as I said above, the relevance in this case is strongly dependent on the industry. We've all seen AAA games that made the market in a blizzard of patches to try to cover up the acres of shit. Probably nobody died, except (with any luck) the executive who made the call. In some other industries, that just doesn't fly.
Now, as to what I said with reference to there being no room in Scrum for your big investigative navel-gaze, it is entirely possible to structure time for the navel-gaze. You can actually come out the other end with a fully specified plan, complete with modularisations, interfaces, and GANTT charts .... wait, this is starting to sound waterfally, isn't it? That's because Scrum is at its best when you have a vision, and you aren't quite sure how to get there but you know what the next steps are. Waterfall project management is great when you know what you want, how to get there, and how to do all the steps. Scrum does not actually assume that you will ever do this - and it violates the Agile Manifesto, aka executive toilet paper - sorry, executive bathroom tissue. This is the disconnect.
Now you could very well say that you shouldn't do the big navel-gaze, and that would be very Agile of you. Congratulations! However, that doesn't mean that there is not value in such exercises. In fact, there are many occasions where that is precisely the best way of avoiding everyone stumbling over each other's comatose bodies, because what you're doing is incredibly tightly definable, and going at it like hungry mice hunting for the cheese somebody moved on you will result in more wasted time, not less.
So there you have it: time isn't something you get to decide you have; it's what is graciously granted you by whoever provides budget. Agility is a sort of an idealised state that maybe happens sometimes, but a hell of a lot of the time is management blather that they don't even understand, and the Big Plan to Fix Everything doesn't really fit into the Scrum way because when you get to that point, you're not doing Scrum, you're doing Waterfall (that may be broken up into sprints for paperwork reasons).
To the immediate parent poster: I hope this makes it clear that the problem is not fitting your navel-gaze into stories, or sprints, or whatever. That's the very least of my concerns. In fact, if it's just a big bug, it's usually fairly easy to justify taking the time and effort to do it right (while the Product Owner works on that Maalox addiction). It's the outright limitation of the Scrum concept in the teeth of reality. And yes, I know, Scrum has to be reality-based, and Scrum has to be adaptable to the circumstances of the particular product and environment, and every sprint retrospective meeting tries to pin down what can be better, but there's no retrospective meeting that can change the CEO's mind about developers being fungible, or the FDA's regulations.
Hope that helps. Sorry about the confusion.
(Score: 3, Insightful) by fleg on Monday May 30 2016, @08:00AM
hmmm a wall of text.
let me see if i can pick out what i *think* your problems are.
you appear to be blaming scrum for not fixing everything wrong with an organisation, and you're right, it doesnt it "just" gives you a framework whereby you can repeatedly deliver software over and over, predictably.
will there be organisational issues which come up which scrum doesnt address? sure, and as i note in a post above when that happens either the org changes or scrum dies on the vine. if you're asking for something which may help fix those other issues and has a certain agile flavour to it, i'd point you at kanban. not with much enthusiasm mind but i've been reading up on it and it *may* be the way to go.
one specific thing you said stands out...
"time isn't something you get to decide you have; it's what is graciously granted you by whoever provides budget. "
true, however, scrum says the person who does get to decide is the product owner, if you have a sudden-unknown-spring-it-on-you-date then its the PO's job to say what stories to stop working on and which ones to start, essentially the PO manages scope (with the help of the team of course). the PO is the link or bridge to the wider organisation, in early scrum the PO was referred to as the "single wringable neck".
alas, it is also true that (last time i checked) the single biggest problem scrum teams face worldwide is getting a PO to do the job of a PO.
i dont know if you already read them but if not i'd highly recommend SCRUMDEVELOPMENT@yahoogroups.com and scrumalliance@googlegroups.com where these sorts of issues come up alot and are discussed by some very knowledgeable people.
(Score: 0) by Anonymous Coward on Monday May 30 2016, @03:27PM
No. Not blaming scrum for that. Just saying scrum doesn't solve that problem any better than classic project management, and that classic project management actually has some better built-in checkpoints for telling stakeholders: "You can't have a champagne solution for beer money, go back and try again."
You also point out that in Scrum theory, the Product Owner gets to make the big decisions. In theory, this reflects practice, but in practice, it frequently does not, and the timeline is often the biggest point of contention.
(Score: 2) by turgid on Monday May 30 2016, @08:55AM
I hear what you say, and just to reiterate what fleg has said, Scrum (or any methodology) is no cure for bad management.
My last job was very much like yours, by the sound of it. All the good permanent developers, and the engineering manager, got stressed out and left (and so did I eventually). When I joined, there were several very good software people who were intelligent and very hard-working, and they were interested in new ways of working.
I introduced Scrum to the company, and "turned around" software development so much (they never delivered anything working before) that I got two big pay rises and made Technical Lead. But it nearly killed me. Two years after leaving, I'm still ill with stress and have just had my first ever week signed off work due to stress, and I'm 20 years into my career.
Management (PHBs, product managers...) did everything you describe. I was amazed at how much of my time that I could have been developing software that I had to spend explaining slowly and in words of one syllable to bone-headed bosses why they couldn't have 6 months worth of work done by the trade show next Tuesday even if it was a great idea that they'd just had (or patently obvious to anyone likely to want to use the product).
As the permanent staff gradually escaped, we had a revolving door of temporary contractors who would come in for three or six months, completely rewrite an entire layer of the code base complete with large parts of functionality removed or subtle new bugs put in, in order to meet some deadline to get something else working.
"But there are more than 8 hours in a day" the big boss told us. Didn't we know it. There are also Saturdays, Sundays and holidays. My record was 09:00 on Thursday morning, home at 18:00, back to work (from home) at 20:00 and on until 01:10 the next morning. Then back into work for 09:15.
What was particularly galling about the whole thing was that they'd flat-out lied to the (big, well-paying, prestigious) customer about the project. They told the customer we were working on it about 18 months before we actually started. Because were were working 100% of our time on several other projects for other customers who all thought they were getting 100% of our time...
The main project was waterfail, but the software was scrum. Every two weeks they got working new features. The hardware was different. It got later and later. At one point on the gant chart we had two days from having new prototype hardware in from the factory to having all of the new software integrated, tested and debugged and the product shipped to the customer. TWO DAYS!
The PHBs couldn't see a problem with this.
It took another 18 months until it was in a satisfactory shape that the customer signed off on it. However, my fire-fighting and late nights got us a 100% customer satisfaction rating in the end. Previously it was about 30%.
The next project they also lied to the customer about when the work had started, what had been achieved and how many people had been working on it.
My health has never been right since. I have permanent headaches,
The evil VP (think Bobby Brown Goes Down by Frank Zappa) who was running our site kept cutting costs. The share price doubled.
It's enough to turn you Communist.
So I got a new job. It pretty grim but in other ways. It was like stepping 20 years into the past as far as working practices go. They claimed they wanted my Scrum experience and that they were doing Scrum withing their waterfall but they're not. Not at all. It's completely rigid. Write a 3-line shell script to automate something? You'd better make sure there's budget for that and time allocated in the project.
Any sort of continuous improvement is forbidden unless there is time and budget allocated. And everything is XML/Ant/Eclipse...
There is no ability to plan anything at all since everything is completely ad-hoc, matrix management (formal and informal). It's all "could you just...." So you have to do what other people want as and when, but you're not allowed to have your own ideas. But it still has to fit within the waterfall plan. And all time is monitored.
The sad thing is, unless I win the lottery, I've got another 25 years of this idiocy to put up with if it doesn't kill me first.
(Score: 0) by Anonymous Coward on Monday May 30 2016, @10:41PM
"Again, in my experience,what has caused the most damage is the 'enterprise' approach to software, using heavy up-front documentation, paper deliverables (never to be used again), heavy process for making and deploying changes, etc."
Heh, you just described every science grant ever written. Total waste of talent and time for all involved. I'm not sure exactly who is winning this game - it's just the parody has become the reality.
(Score: 2, Disagree) by aiwarrior on Sunday May 29 2016, @02:35PM
TLDR: Aha ah ah ah. Ok a bit more Ah ah ah. Now try to actually live on the direct expense of your customer, not on the safety of the company wage. The submitter must be a management mastermind.
Who the hell is the submitter and why does it equate it's experience with a huge industry? I develop software for drones and use none of that techniques. I guess software for web applications have different requirements and management styles, as does a game or an autopilot.
In my opinion every development is about the contract, implicit or explicit you make with your end users. It might be acceptable to sell a product which is not yet finished or "low quality" but which is being actively developed, or it might be acceptable to sell a product which absolutely must fulfill the contract requirements on delivery and on time, come what may. I have had success with both kinds.
Now I am often in the position where I have somebody asking me for a demonstration much before I believe the code is as I wished it to be, but to be honest there must be compromises. I cannot live in a magic bubble where all that matters is elegance both in architecture and implementation otherwise it would take double the time. I advise you to be the one talking to the customer and have a stake at really needing it's money to live. Balances become much easier to achieve and goals very clear: Make it so you can improve but at the same time have the capability to short circuit development to fulfill the goals any time ("oh noes low quality").
The only concept I understand in the argument of the "low quality" software is that a technical debt is developed which leads to sever under performance that cannot be corrected ever without almost starting a new or huge resource spending. This leads to a failure to any kind of contract, both the ones where you are expected to iterate it to good quality over time and to the fixed requirements ones.
Sorry for the bluntness
(Score: 0) by Anonymous Coward on Sunday May 29 2016, @02:51PM
Your POV is the one prevalent in management of proprietary software today, which is not wrong. Indeed, it does "put the customer first" in some sense; but where the customer is today's customer, or more precisely a composite of customers weighted by their current and expected near future contributions to sales.
TFA does not provide a succinct description of an alternative goal, which is the main weakness of the article. If he did, perhaps he wouldn't have veered off into random rants about dress codes. Maybe he should have said: management of software should be much more heavily weighted with the architects or technical leaders of the software (in contrast with today, where the business owners have the biggest voice); and furthermore, those architects need to take the long view of the software. Those passing through with an eye to climb the corporate ladder and punch up their resume should have less weight in the discussion.
Anyway Fred Brooks covered all this ground, and more, decades ago. There are no worthwhile metrics for software quality, except defensive ones like P1 bug counts and automated test failures.
(Score: 0, Troll) by Anonymous Coward on Sunday May 29 2016, @02:41PM
One of those bottom-of-the-barrel weekend posts, eh? :) Let's see if we can make it interesting via comments - I think off-topic comments would better serve the purpose.
(Score: 2, Offtopic) by Gaaark on Sunday May 29 2016, @02:46PM
My bum itches.... any interesting comments?
Anyone?
Anyone?
Buehler?
(Is this off-topic enough for you?)
:)
--- Please remind me if I haven't been civil to you: I'm channeling MDC. ---Gaaark 2.0 ---
(Score: 0) by Anonymous Coward on Sunday May 29 2016, @03:01PM
Scratch it, fool!
(Score: -1, Offtopic) by Anonymous Coward on Sunday May 29 2016, @03:15PM
DDT
(Score: 0) by Anonymous Coward on Sunday May 29 2016, @03:57PM
AnuSol [pilesadvice.co.uk]?
(Score: 1, Insightful) by Anonymous Coward on Sunday May 29 2016, @02:54PM
Personally I think it's nice to have some articles that aren't on currently "above the fold" on many IT sites, the NYT or phys.org.
(Score: 0) by Anonymous Coward on Sunday May 29 2016, @04:31PM
If an "off-the-radar" item turns out to be a "same old cliched whining," then maybe it's off-the-radar for a good reason.
(Score: 4, Insightful) by fubari on Sunday May 29 2016, @06:35PM
"bottom of the barrel?" What are you talking about?
It was a really good article, well worth the read if you work with any size software team.
Key points:
Encourage Code Ownership:
This one was a real gem.
I hadn't thought of it this way before.
I like the idea - a lot.
I can't paraphrase better than the author, so here is the idea:
"It’s no surprise that management likes to reduce risk by treating developers as interchangeable widgets. It usually takes the form of all developers being expected to be familiar with all areas of the code. That minimizes the pain when any individual developer leaves the team or the company.
This is false economy. Your employees like working for you?—?right??—?which means turnover should be low. Don’t optimize for developers leaving which should be the uncommon scenario. For best results optimize for the common scenario.
Optimizing for the common scenario means giving developers primary ownership of portions of the code base and not allowing other developers to change that code without approval from the primary owner. This results in higher productivity since any given developer is more likely to be familiar with the code in which they will typically be working.
It also helps you identify developers that need extra attention. ..."
(Score: 1, Insightful) by Anonymous Coward on Sunday May 29 2016, @11:41PM
Expecting the entire team to own all aspects of a project isn't JUST about planning for employees quitting or being fired. I worked In a shop recently where one developer owned all things Hadoop. We had short, one week sprints so what do you think happened when this developer took a vacation last year? Urgent need for a new feature relying on data in... You guessed it. So I had to scramble to not only get familiar with something I'd never touched, I had to track down resources who could provide me with basic getting started stuff like authentication.
After that we took some time to cross-train, and when mr Hadoop had an unexpected medical leave later it wasn't as big of a deal for another team member to make some changes.
(Score: 0) by Anonymous Coward on Monday May 30 2016, @06:03AM
I've dealt with that before by, as software manager, be familiar enough with all aspects of the code that I can parachute in in an emergency and fix things (then apologise to the developer in the morning when the dust has settled). This works because as software manager I am in on the code reviews and design/etc so I pick up enough familiarity anyway. Also, as senior guy I expect/am expected to stay late/do what it takes to keep the code working.
It doesn't work well when I am covering holes in the development team in day to day work so I don't have the spare time to do the fire fighting role.
(Score: 1) by fubari on Tuesday May 31 2016, @06:26PM
Interesting anecdote, makes perfect snse.
The core concept in the TFA was that 1) being unavailable (for whatever reason) is an edge case, and 2) optimizing for edge cases is sub optimal.
Cross training is swell.
And cross training doesn't conflict with the idea of a an owner (get keeper) for key areas who signs off on all changes.
(Score: 4, Insightful) by Anonymous Coward on Sunday May 29 2016, @03:04PM
There to my knowledge, never been a true and successful Agile or Waterfall implementation. I am going on 45 years in the business.
Team size and caring are only factors in making a successful and enjoyable project and product.
Simple rules:
1) Never have more persons on a team than can fit into your car to go to lunch. That way 1 conversation and all will be on the same page.
2) Have regular LONG lunches (2-4 hrs) and pick up the tab, even if it is from your own pocket. Sport bar, Brewery, Coffee Shop, Outdoor Cafe... Places that have noise and you can talk! And not PC.
3) Lunches are to talk about family, friends, life! Then and only then, talk about the project and where you all want project to be in 3 to 5 yrs. In REAL terms! Not PROFIT!!
4) Toss everyone out of the office every few fews or months, depending on release schedule. And this it NOT personal or vacation time! So when release is made all will be rested. You may need them even more then.
5) Get all members on the same page and keep them there. So what are your standards including processing norms, for a Name, an Address, a Phone#, a Date/Time, ...? These are little things that make BIG changes. One project, we spend 3 days a talking through the "what is Date/Time?".
6) Remember being a "manger" should add up to about 15mins total in lifetime: Hire, Fire, Raise. That is it. The rest of time, you are the "waterboy", supporting them to grow.
7) All get the respect to talk to and for clients, users, other team members. They get the decision making. You are there to support.
8) Work Hard and Play Harder.
9) Let them know you will pick up the pizza when they work late.
Yes, all warm and fuzzy. But, it is respect them and be a family, don't treat as a family, just like being a parent. Kids Birthdays, Land Parties, BBQs include the whole family including the dog. In the end all will be part of the family.
PS: I'm the weird "uncle" with the cool toys.
(Score: 2) by Nerdfest on Sunday May 29 2016, @03:16PM
Well said. I'd add "make sure they have easy access to the right tools", although that does fit nicely under the "manager waterboy" category as well.
(Score: 2) by PocketSizeSUn on Sunday May 29 2016, @05:49PM
Your list is a very good one.
The only missing piece that I would state (that you have implied?) is that team quality applies as much a size.
Part of you job is to recognize the inevitable dead weight that is grafted onto your team (unless you are fully autonomous in building you team).
Your long non-PC lunches does a good deal toward seeing what members of the team are not respected ... this is often the strong indicator that someone's contributions are lacking.
Cycling out the dead weight is the worst part of the job, but is also an important piece that I don't see happening very often anymore.
(Score: 3, Insightful) by bitstream on Monday May 30 2016, @02:05AM
Non-PC lunches are a good opportunity to misinterpret other peoples body language and also to confuse interpersonal issues with quality of contribution.
(Score: 2) by JoeMerchant on Sunday May 29 2016, @06:16PM
In other words: treat your people well.
The problem with any "silver bullet" technique is when somebody reads a book, or goes to a conference, or gets trained by "the best gurus in the industry" and comes back to the office in a management position with a preconceived notion of "exactly what we're going to do," and loses sight of their people. Change is painful. Steamrollering over a group with change and sticking rigidly to some formula is a sure formula for one thing: robo-employees who do exactly what you say and abdicate responsibility for the consequences. And, there goes the power of your team, straight out the window - it's all on your head now, you who brought this new thing into the office and forced it on everyone. Everything that goes wrong from this point forward is the fault of the new thing, wouldn't have happened the way we used to do it, etc. etc. etc.
If you're Sir Robert Salt and the job is shelling chocolate bars as quickly as possible to get a golden ticket for your darling Veruca, then, sure, totalitarian management is fine. If you need your employees to do some thinking for you... you'll need to be treating them well.
🌻🌻 [google.com]
(Score: 2) by bitstream on Monday May 30 2016, @02:07AM
Guess H1-B produced code will lack in quality?
(Score: 0) by Anonymous Coward on Monday May 30 2016, @01:38PM
Generally, Yes.
I have worked in shops, where the requirement were a user walk and "I need an AR report by 3pm, showing aging." There was enough cultural information in the that request. That a program could be pulled together from scratch and meet or exceed 95% of what was request.
Yu can not get that from someone who does not "live" the local cultural, period.
For can you answer: Can a credit age? US: No. England, India: Yes.
We had another project, who was lead designer, not understand how a "FETCH" worked in language, so he was scanning the entire table for unique key. "WHERE(key = ______") vs. "WITH_KEY(_______)" Yes, it was a hybrid language that allowed both RDBM direct calls and SQL on the same statement, but he was 10 year expert in the language.
Another project took 2yrs (20 people) from quoted 2mos (10 people) for $75k. They did not want to look bad, so the QA was a ten step program that turned a 2hr job into 2 to 3 day job. I was tracking changes near real time, projecting when the project would be completed, I keep asking my VP and their VP, what was happening and why will the project be late, starting the second week showing the completion 2 year out. Final, after about 4 months (so 2 months late), their VP admitted what was up and our VP and their VP, had a lo-o-ong talk, and they agreed to complete the work on their dime.
YES, there are good projects, but I have not seen one, not H1-B, Off-shoring, or Foreign Partner. In most cases, in my option, it tends to be cultural issues - Saving Face, Not wanting to ask for help, do not understand "common" standards.
So, Answer simple questions:
Today is Jan 30.
Add 30 days, what day is it?
Add 1 month, what day is it?
How many days to end of the Quarter?
Justify your answers.
(Score: 2) by bitstream on Monday May 30 2016, @02:08PM
Add 30 days, what day is it?
Feb 29, ie +30 days
Add 1 month, what day is it?
Feb 29 + 1 month depends on the definition of month. But Mar 30 (30 additional days) seems reasonable because it is at least a common definition of an additional month. In reality it would be marked as not working and a clarification would be requested of both what is being desired and context before clearing such functionality for even a beta release.
How many days to end of the Quarter?
IF the answer of the previous question is Mar 30 then it should be 2 days. If the day begins at 00:00 then 48 hours later the first quarter would be completed.
Catch for timezone changes, leap year, 400 year oddity, local customs etc. It works when it's correct not when it seem to work. Walking through the code and image what it does usually catches those glitch cases that specific tests will miss.
An interesting case is to convert between yyyy-mm-dd hh-mm-ss and epoch at the winter/summer time changes. Some ranges of epoch will turn out to have the same hour definition and some hours will have double epochs that could match but neither is really correct.
(Score: 0) by Anonymous Coward on Monday May 30 2016, @03:36PM
BEEP you failed, thank you for playing.
But you do get bonus points for "If the day begins at 00:00". Note: I prefer to not use ':' in time, instead use 'h', for 4 char times, since it ends confusion about is it "hh:mm" or "mm:ss".
"00h00" is why contacts use 12h01am as a start time for a date. Why? A day does not start at Midnight. It is the point between two sequential dates. It is not AM. So writing midnight as 12hr clock should be: 12h00m And Noon is not PM, it is 12h00n, again between AM and PM, it is nether. Also watch out for "noonish". "Lunchl be 11:30 noonish" ARGH!
24hr clocks, yes 00h00 is ok for midnight, but so is 24h00. 00h00, it is been assigned to start a day. Where 24h00 it is being assign to end a day. I did one project that a day was defined to be up to 48hrs in it. So 30h00, was +1 days 6h00. The reason was the business day did not change at midnight, but at a random time after 2am and before 6am (hotels, restaurants, bar) we had to map back to business day in question. So a call made at 1h32am, will show up in the data as 25h32 on the prior day. When you sort the data it comes out correct sequence. Just a dirty "trick" to handle two sequences in a date and a time single field pair. Days of 27MB 12inch Winchester drives. :)
Now back to your answers. Yes, those are tricky bits of dates. :)
1) Feb 29 occurs once every 4 yrs, except once 100 yrs, except once 400 yrs. So, Feb 29 and Mar 1 are both required in your answer.
2) Adding a month is NOT adding 30 days. Adding a month is adding a month, so the answer will be both Mar 29, Mar 31 or Apr 1, depending on answer to 1). Note Mar 31 is valid, since Feb 29th is the last day of month, so Mar 31 is last day of the month, depends on alignment terms. If starting with again with Jan 30, then Feb 28 or Feb 29 are the correct answers. Mar 1 is not, since started in Jan and next month is Feb. So adding a month, WILL cause the day difference to vary from 28 to 31 days.
It is also why you always work from BIG to small in Date to and Times and only correct/adjust at the end.
So Feb 29, 2016:
add a year: is Feb 28, 2017
add four years is Feb 29, 2020. If you adjusted after each "step" then This would be Feb 28, 2020.
3) your forgot to define quarter. Most humans do not use quarter in normal life. A quarter is mainly a business term, so year over year can be compared. I worked at place where fiscal weeks, months and quarters were defined the fiscal year starting the periods, began the the first Sunday of week that has least 4 days in October, then it when 4wk, 5wk, 4wk (qtr), 4wk, 5wk, 4wk (qtr), 4wk, 5wk, 4wk (qtr), 4wk, 5wk, 4 or 5wks (qtr)(yr). To most of us though quarter is Jan-Mar, Apr-Jun, Jul-Sept, Oct-Dec., Fiscal quarters are multiple answers, even including a Fiscal Year with 1 quarter in it. In the end this is even worst than adding a month. So when you add a Quarter what is day is the expected day in the next quarter? :-)
You may now get why 3 days a talking a date/time is REALLY important for all to understand.
(Score: 2) by bitstream on Tuesday May 31 2016, @09:52PM
Why don't all time points belong either to previous day or the next day? If your function would need to return the day given epoch. What day would you return for these in between times?
As for time of day I avoid all 12h hour timing. It just increases the risk of mistakes and if only given two numbers I would say it means hours and minutes. If given three numbers the last one is seconds.
1) You didn't specify that other years than the current one (2016) should be valid.
2) Your solution results in a ambiguous result it's not a 1:1 function. I suppose it depends on the context (application). But if one needs to advance "one month" and then make a database entry at that time. Then one better know what specific date to make use of. Then there's the question of what internal representation of time to use. If one uses epoch then the definition is at least clear internally but conversion to human readable time may become complicated otoh arithmetic on human readable time can be error prone.
When you say "add a year" how do you determine if to advance with 365 or 366 days? because the length of the year will change as you advance. Your first example seem to advance to next years last day in February.
It seems like you simply advance the year and if you end up on a non-existing date like Feb 29 2017 then you adjust it back one day. But that mean one has made a implicit choice to rather be one day less than one day more.
3) If the quarter is defined by weeks. Then that is what should be used and months etc should all be ignored.
Perhaps in the future the date will be the day of the year instead of all the mess that the current date/time is. To increase the pain there are even different calendars and leap seconds etc.
Do you have any idea on how to translate 2015-10-25 02:00 to epoch without information on summer or winter time?
(Score: 0) by Anonymous Coward on Wednesday June 01 2016, @05:15AM
That is exactly the problem.
People ASSUME meaning that is not present. It why adding month and adjusting the date is better than assuming a month as 30 days. So conversion is based on assumptions. I was just invited to meeting at 5pm PDT. I asked why would I show up to meeting 4hrs after I left work. The person scheduling the meeting only thought of himself and his cultural standards, not everyone else needing to meet.
But dates as they are cultural. If you do not embrace them as they stand, do not do computers. It is important that everyone does them the same way on team. If cmd 'date' fails, then use another makes correct sense. But all the edge cases must be met and understood. SO if business thinks in "weeks" and maps them over "months" then you have to have correct understanding. One gig, I was told that there was 48 weeks in year, since all work is done in 4 week months. When I showed that if you got weekly service that would be 52 or 53 services per year, ha d company VP yelling that was wrong. Finally, took a calendar out counted. Showing they have undercharged and validated the contracts. Weekly service is once per week, it does not matter how many weeks are in month. Monthly service is once per month, so 12. Just because you try to schedule all those monthly service into a 4 week window, is not calendar issue, but is a cultural and legal definitions, not an in-house convention of counting.
About the year being 364 or 365, not true. Even using 365.24 is a approximation, though 3655.25 gives along period of reality usefulness. Did one system that all dates where kept in days since a point in time. And the starting point had to Day 1 = Jan 1 of four year cycle with the leap year being the last. So, Jan 1 1961 is a good starting point. Then did all conversion math with a 7 digit field with 2 places after decimal. So 12345.67. Then added 365.25 to that value for each year greater 1961. Then added numbers of days in for each prior month to the given month, with 28.24 for February. Then add number of days. Return only first 5 digits to calling routine. Yes, Multiples is general better than loop-addition, but on this machine, loop-addition was how the multiple function worked anyway. It worked very well and gave us 100 yr period of sequential dates.
We could even process bad dates, like 13/13/13, and it would return the best guess. 13th yr (so 2013, since starting with 1961), 13 month so add another 365.25, then add 13. the convert it back and get 2014/01/13, report back the error. Very handy in the interfaces where the data is not guaranteed to always arrive correctly, so have to handle best guess.
(Score: 2) by bitstream on Wednesday June 01 2016, @10:06AM
That after work meeting was that due to misunderstanding on time representation or due to not being aware of the implications on different timezones?
I also noticed that many US times uses the EST timezone but assumes that's natural without specifying that is so.
A year is 365 or 366 days depending on leap year. I have not seen any data that it would be 364 or 365 days. And that the average year is 365.25 not 365.24.
(Score: 0) by Anonymous Coward on Wednesday June 01 2016, @05:38PM
Look up a solar year. What all human calendars try to approximate and align to.
The solar year (365 days 5 hours 48 minutes 46 seconds), also called tropical year, or year of the seasons, is the time between two successive occurrences of the vernal equinox (the moment when the Sun apparently crosses the celestial equator moving north).
Since it is NOT 6hrs (hence .25) it is 0.2421990740740741 proper rounding is down to .24.
(Score: 2) by Magic Oddball on Monday May 30 2016, @05:11AM
Make sure that part of heading that "family" includes understanding that not all employees/people are happy, comfortable, or even functional at large gatherings — especially ones where it's not only the person's co-workers, but also the co-workers partners, screaming little kids, barking dogs, and so forth.
I've known more than a few highly talented programmers, admins, etc. who repeatedly lost jobs because even though they did high-quality work, were happy working extended hours as needed, and got on well with their co-workers, they either avoided attending company social events, or they forced themselves to attend only to stand stiffly because the interpersonal/sensory overload was just too much.
(Score: 0) by Anonymous Coward on Tuesday May 31 2016, @12:31AM
You have not met the extremes... Mensa for multiple decades.
One person was far out the continuum, that if the conservation was not about his subject, Chaos Theory, he would shutdown. His friends would bring him to parties and seed the group with topics. Chaos Theory class, with a beer-in-hand, GREAT evening!
So, hence the "family". As a family, you make space for every one. Whether a night out with the "guys" shoting pool, spouses getting a night out with kids, or a ball game, there is always way to make ALL included.
(Score: 3, Insightful) by Fnord666 on Sunday May 29 2016, @03:15PM
"In other words don’t let age play a role in your hiring process and you and your employees will benefit in the end."
They will also benefit from the fact that the company doesn't get sued into oblivion for illegal hiring practices.
(Score: 3, Interesting) by Anonymous Coward on Sunday May 29 2016, @04:21PM
H1B.. it is the root of almost all the problems
1)Massive free overtime or you're fired
2)Ridiculous schedules
3)Choice of either being a contractor with poor / no benefits or salaried which makes you a 24hr free OT slave
4)Poor and stagnent / falling salaries
We need a union...yes, seriously..
(Score: 1, Insightful) by Anonymous Coward on Sunday May 29 2016, @05:28PM
You're right! We need a union, with industry-wide membership!
This will be fantastic. The real cost of hiring union coders will be substantially higher (all that overtime now being paid, plus the overhead of union organisation, lawyers, stewards and politicians that want gladhanding), and by forcing H1Bs into the union system (because otherwise what's the point?) we make sure that they're not expanding our industry because who the hell wants them?
Fortunately, code is easy to generate anywhere in the world, and import via infrawubz! Pretty soon you'll see ads like:
"NOW HIRING software developers! Work on the latest tools! Super-exciting code ninja buzzword angels! Must be willing to relocate to Botswana."
Hiring a developer today, once you add together all the expenses, is somewhere in the region of $150K or more. More senior devs, with more rare skills, rapidly become a lot more expensive. (This includes a fudge factor around benefits, SS contributions, worker's comp and so on - exact numbers will vary by location.) The reason that this makes sense is that realistically, your typical dev ends up working somewhere in the region of 3,000 hours a year, regardless of how stupid it is to do so.
We're already seeing the consequence of this cost structure. Companies are offshoring any time they can find a way to do so. The companies that have accumulated profits stashed outside the USA because of destructively insane tax codes have yet more motivation to do exactly that. Your pretty vision of a union is going to do absolutely nothing to reverse that particular trend.
Footnote: nothing against Botswana. It's a beautiful place. But its currency and payscale is not what you'd exactly call the union worker's dream, when seen from Californistan.
(Score: 0) by Anonymous Coward on Sunday May 29 2016, @08:37PM
I can't wait to take my turn out on the picket line holding a sign that says something like
Oracle Corporation Does Not Meet Community Standards
while people with real work to do walk briskly past me on the sidewalk.
(Score: 2, Informative) by Anonymous Coward on Sunday May 29 2016, @09:48PM
You are thinking a 'Teamsters' or UAW type union. That is not what we need.
What we need is an "American Medical Association" or "American Dental Association" type union. Your doctor and dentists are in these unions. They are called "associations", but they are unions. They keep out all H1B doctors and dentists working for $15 / hr to replace all the Americans.
Yes, we might need to be 'licensed'. Imported software or software used in the USA might need to be licensed, just like medicines and dental procedures are today. At least it would work though, and would be done to 1st world standards..
(Score: 0) by Anonymous Coward on Sunday May 29 2016, @09:51PM
I think government officials at all levels would be skeptical of the need to protect the public from the menace of unlicensed computer programmers.
(Score: 0) by Anonymous Coward on Sunday May 29 2016, @10:47PM
I dunno, how many billions now have been lost due to info sec lapses and spectacular failings in security. Wouldn't be a hard sell I think...
Think of the children, think of the billions$$
(Score: 1, Insightful) by Anonymous Coward on Monday May 30 2016, @01:36AM
And exactly what about this will prevent the Botswana-based software economy? The elevated salaries? No ... wait ... maybe the reduced availability of developers? No, hang on ... how about the importation of software through the internet .... no, not that either.
It is hard to get a doctor to treat someone in Hartford, when the doctor is in Harare. Dentistry, even more so. But you could have developers in low earth orbit delivering working code to any point on the globe, and it wouldn't matter except that they'd need a different kind of coffee mug.
At best, you'd get government employed coders, all in a government coder union, while companies uprooted their code shops the same way Detroit moved manufacturing to Mexico. Sure, a few relict code shops would hang around, but if Coder Naidoo in Delhi worries you today, that's nothing compared to what gatekeeper style professional associations will do to the industry. The government can always make the argument that they need their code certified, but the exciting stuff will happen in India, China, or freaking Aruba. Just not here so much. Not any more.
Worse yet, what will it do to education? Will we have postgraduate code schools the way we have law schools and medical schools now? And what about kids who are self-taught? Do they just suddenly get cut off?
"No compiler for YOU!"
Yeah, nothing about this looks smart to me.
(Score: 2, Interesting) by Anonymous Coward on Sunday May 29 2016, @10:20PM
Good luck with that.
...especially getting it mentioned here.
I've submitted a bunch of labor-related items.
Invariably, they get deep-sixed by the editorial staff.
Rennes, France: Violent Rallies Against Labor "Reform" [soylentnews.org]
France Rises Up Against Anti-Labor Executive Order [soylentnews.org]
Uncle Sam Tells Verizon and Worker Unions to Settle Their Spat [soylentnews.org]
Verizon Strike: Hotel Pickets Worked, So Federal Judge Bans Them [soylentnews.org]
Update: Verizon Strikers React to Company's Ultimatum [soylentnews.org]
Workers Strip and Beat Up Air France Bosses Who Had Announced Plans to Lay Off 2,900 [soylentnews.org]
-- OriginalOwner_ [soylentnews.org]
(Score: 4, Insightful) by RamiK on Sunday May 29 2016, @11:35PM
It's too easy to outsource software internationally for programmers to unionize. Instead, consider focusing on liabilities for defective and insecure software while pushing towards regulations for open source software in governance and finance. That will create a huge local market that promotes quality over quantity and that can't outsource as easily.
compiling...
(Score: 0) by Anonymous Coward on Monday May 30 2016, @01:22AM
The American Medical Association has been mentioned in this (meta)thread.
The USA -could- have many more physicians per 100,000 Americans.[1]
Through lobbying, the AMA makes sure that that does NOT happen, thereby rationing medical care and keeping the cost high.
As an example of how they make this happen, the number of yearly medical school graduates in the USA remains essentially constant.
The major clout a union would have would be to bribe^W lobby politicians in the crooked system that exists.
If they were -really- ambitious, they could throw their resources behind the movement that is organizing against the crooked system:
Money is not speech; corporations are not people.
http://www.wolf-pac.com/the_plan [wolf-pac.com]
https://movetoamend.org/ [movetoamend.org]
[1] Note that Cuba *does* have lots of physicians and other medical care personnel because that is part of their ongoing Socialist revolution.
.
easy to outsource software internationally
How is the quality of that outsourced development?
From what I've heard, USAians end up correcting the numerous resulting flaws anyway.
...and the communication latency with someone on the other side of the globe doesn't help schedules.
(They're sleeping when we're awake.)
open source software in governance and finance
Amen.
...and lobbying and organizing outreach to other citizens by a union would help get that.
-- OriginalOwner_ [soylentnews.org]
(Score: 0) by Anonymous Coward on Monday May 30 2016, @03:29AM
From experience: the quality of software teams, both inside and outside the country, varies wildly. I've seen code from both inside and outside the country that was incredible - and some that was incredibly bad. Sorry, that's no defence against outsourcing.
And the communication latency thing is already reality for anyone in a large corporation, with distributed development. So that's nothing new.
Postscript:
If corporations aren't people, then I'm afraid neither are similar organisations such as unions, which means that their voices are similarly stilled. There will be a lot of politicians who will be dead set against cutting off their union-sourced funding and support. You see, the whole reason behind the corporations-being-persons thing is so that they can have their place in court, both as plaintiffs and defendants. This matters, because if there is no corporate veil, suddenly every corporation becomes no more than a glorified partnership, and shareholding becomes incredibly risky, because then every shareholder is on the hook for the misdeeds of the company. In case you were wondering, this is a bad idea. For reference, look at the way that resistance to shareholding and corporate personhood has messed up large parts of the arab world.
If you do have the corporate veil, on the other hand, the corporation becomes an active participant in the legal proceedings of the country, and as such has an identifiable, differentiable interest in the policy making of the country. If this can't happen for corporations, neither can it happen for unions (unless you write one hell of a tortured constitutional amendment, that will definitely not get endorsements because of its naked partisanship).
On the other topic, if money isn't speech, and isn't a proxy for speech, you had better have a plan to subsidise media because nobody's paying for communications. If, however, money is an enabler for communication, then preventing the spending of money on communication makes a nonsense of the idea of freedom of speech.
I guess what I'm saying is: be careful what you wish for. I'm pretty sure you will strongly dislike some of the consequences.
(Score: 0) by Anonymous Coward on Monday May 30 2016, @10:30PM
H1B.. it is the root of almost all the problems
And Globalists are the cause, SJWs are their tools. Now that our New World view is Ordered, let's discuss the solution: Nationalism.
(Score: 0) by Anonymous Coward on Sunday May 29 2016, @05:34PM
"Path-E-Tech Management be keeping us down!"
Yeah, whatever. If you don't like it, look to Wally. Passive aggressive work stoppage will solve all your problems, honest.
(Score: 2, Insightful) by Anonymous Coward on Sunday May 29 2016, @05:39PM
In the past I was to blame as much as anyone until I discovered and refined a basic set of practices that for the most part cause everything else to fall into place — at least in my experience. No promises. Here we go.
yeah, right ... hem ... that's exactly word-to-word what they were thinking when writing down the agile manifesto.
(Score: 1, Informative) by Anonymous Coward on Sunday May 29 2016, @07:02PM
The obligatory https://xkcd.com/927/ [xkcd.com]
(Score: 3, Insightful) by Anonymous Coward on Sunday May 29 2016, @11:18PM
People please, if you have a degree in Computer Science and don't write research papers, go back to school for a Software Engineering (SE) degree. They are completely different after the intro courses.
The quiet crisis unfolding in software development
That has existed since the dawn of programming. Go learn the history of the field. Silver bullets have existed just as long and are not the sole domain of management. See the early history of AI as an example.
Despite there not being a single shred of scientific evidence in favor of open office workspaces being a good idea
Actually there were studies and if you go to a school with a good SE degree you'll get to read about them, learn the pros and cons, and understand when open offices make sense and when they don't. You'll also learn when and how to apply which processes and how good teams can do good things no matter the process. This has all been studied and documented in case studies and research studies. Go read them. As a manager, all these things should be tools in your toolbox like how a programmer should know a bunch of different libraries and languages and when to use which.
This is mostly a compilation of common sense but I felt it needed to be compiled in one place for all those low level software development managers out there. I wish it had existed my first day as a software development manager.
It did exist, but it exists in books and in research from the 50s through 70s. Had you been a good SW manager instead of just pretending to be one, you would have looked up those books and read them. Instead it sounds like you wasted 6 years learning things you could have read from two books that were published decades ago. Same goes for that poster who said he has 45 years of 'experience' and believes there has never been a "true and successful Agile or Waterfall implementation." Learn from your mistakes. I bet throughout all those years there was a common element on all those failing projects: you. It sounds like you did nothing to help everyone improve year after year. You don't need to be buddies with all your teammates to successfully complete something. You're supposed to be mature professionals*, everyone doing their jobs and helping out when they can. Being buddies changes the focus of the workplace from "those guys do good work" to "those guys aren't as close as we are, screw them and help me". The skills to share technical info are not the same skills used to pass beers. You shouldn't rate your co-workers on their ability to suck up to everyone.
*For those unclear, being professional is how you act not what you wear.
(Score: 4, Interesting) by bitstream on Monday May 30 2016, @02:18AM
Which books would you consider essentials?
(Score: 0) by Anonymous Coward on Monday May 30 2016, @06:12PM
TAOCP Vol I-IV and Computer Architecture A Quantitative Approach, probably.
Good luck with those.
(Score: 3, Insightful) by jmorris on Monday May 30 2016, @12:22AM
Nice ideas for how to manage developers... so long as you are committed to maintaining the same shit deliverables.
The problems in the software world go far beyond any of that stuff. At the root is the explosion of code. Twenty years ago I could run Netscape Communicator on a 486 level machine with 40MB of ram. It wasn't exactly speedy but it did run. The Mate taskbar needs more that that on a modern machine. And it isn't just graphical desktops either. I'm running Fedora right now and rsyslogd's resident set is currently 35,856K. Why?
It isn't the inflation in codesize I'm complaining about exactly. It is why and how it happened: we slathered poorly thought out libraries and frameworks together with little understanding. Because almost nobody actually understands what is happening, only that they puzzled out the sparse to non-existent documentation, read examples and raw source enough they figured out how to graft what they were actually trying to write to enough existing code to make the damned thing build... and then moved on. I'm bitching specifically about the Linux world since I use that but while the docs are a little better in some ways on Windows and Mac the same problem apparently exists there. Is it any wonder that most of it rarely works and the average software of today is less secure than the worst of the bad old days of sendmail?
It is about time to quit this bullcrap of tossing code over the transom as soon as it builds and finding it running critical infrastructure weeks later. It is about time to settle some hard standards for core code, lock any new features out and then audit the holy hell out of it and include extensive test suites. Then start moving the bar up the stack. Eventually working toward 'getting it right and stopping' all the way up to things like http servers, html5 parsing and rendering, databases, backends to do double entry bookeeping, etc. Break up any monolithic project, even internal 'line of business' stuff into smaller, understandable parts that can be audited and have a fork stuck into them. As long as we are hell bent on rewriting the whole world every decade we are never going to actually finish anything. So everything is going to remain buggy, half assed crapware.
And it is doubtful complex object oriented codebases can ever be made safe, as nobody actually understands them. A major selling feature was that you weren't supposed to need to know, but of course decades of hard experience says otherwise. Such code will have to be split down into parts that communicate across simpler interfaces or just rewritten in better languages. Time to face reality, after a few decades it is still a lot harder to interface to a C++ library than a C one, and even harder still to do it safely. And for all the PR about code reuse, there is no more reusable library than a well made C library since literally every other language interops with it.
(Score: 0) by Anonymous Coward on Monday May 30 2016, @02:47AM
One problem with what you are talking about doing is that all the evil libraries strive to work with *everything* these days. Used to be you had a library / driver for this printer, this version of Adobe PDF, that graphics card and the sizes were smaller and more focused. Oh, wait, that fragmented landscape sucked too, just differently. Then some hot shot new fangled way of doing the same thing but doing it better because new hardware came along and screwed everything up.
No, I see no net gain in making the code smaller for most projects. Nor in re-writing a frick'n httpd unless you really REALLY have to. Nor in having an official "blessed" codebase that everyone must use because that would just lead to stagnation. Software dev is going the way disk drives went when RAID storage became popular. Mask the lower quality products with more layers. Started with compilers then moved to OSs managing your metal. Oh no, I have device drivers! Oh no, HALs are the death of good programming! Frameworks are a pipe dream! Interpreted languages / virtual machines are killing real programming. Full virtual machines are a fad, a proper OS is the way to go for real servers. PaaS / IaaS is for hipsters and won't ever work. There is a pattern here of making things more abstract and of people resisting.
Otherwise the article was spot on. And can only be implemented by someone at the authors level who beats their under managers upside the head until they actually are held accountable.
(Score: 2) by jmorris on Monday May 30 2016, @03:37AM
Kinda making my point for me. Yes we have all those abstractions and a software world that is trivial to hack. To date we have yet to see sufficient damage to demand we fix the problem but imagine what is going to happen in the next major war. Do you think we have abolished war? If not we have to plan on the economic damage possible by a determined nation state actor and plan accordingly. I'm asserting that there is simply no way we will ever build an IT infrastructure that can withstand such a determined assault by continuing to build systems and software the way we currently do it.
Nor in having an official "blessed" codebase that everyone must use because that would just lead to stagnation
Not at all. Instead of 'innovating' more features into the existing layer you would add a new library. Is there anything a C library needs that GLibc does not provide? If there are still any 'unimplemented' stubs go in and fix them, then declare it 'done'. But no, if a project isn't releasing new versions every few months it is considered 'dead' and instead of someone stepping up to take up the task of merging bug fixes and maintaining a repo somebody begins a new replacement project. But that doesn't stop any number of new libraries being released and eventually, if they are useful and good code, stabilized and frozen.
Officially freezing them should only come at the end of a detailed code review and a year or two of increasingly high bug bounties. The best case of course would be funding efforts to replace critical code with one last rewrite, a full DJB style 'provable' solution.
And would be really be so bad to kill the 'living standard' html5 idiocy and replace it with a real standard? This shit isn't forward or backward compatible. You can't get an actual book because publishers know it would be obsolete before they could commission a book, edit it and kill some trees to print it on. Web authors are forced to play an endless game of trying to stay in the happy middle where 'most' browsers display their pages. No, standardize the damned thing, put the standard in stone and force 'innovation' to move to other layers for a decade or so until we see new pressing needs. Then solve them in backward compatible ways if at all possible. We should be striving for a world where a browser could be placed in ROM based device and be viable for a decade or more. What we have now is upgrade every month and hope it is fast enough to avoid most of the exploits being widely abused in the field.
(Score: 0) by Anonymous Coward on Monday May 30 2016, @04:06AM
Great ideas. You go first. Can you get funding to "do some subsystem the right way", or re-do an existing one that is bloated and insecure? Better yet, make sure the sponsor agrees that the result should be put back into public repository (GNU style).
My experience has been in managing a few engineering programmers for the last ~25 years. We work on contract for big companies and it is extremely rare to find a customer that is willing to pay extra to sort out the problems with existing code. They all want their extra feature crammed in somehow.
(Score: 2) by jmorris on Monday May 30 2016, @05:22AM
I certainly don't see what is going to force sanity on the industry. Will probably take an actual attack and hundreds of thousands of casualties. Then we will do something stupid that also won't work in a panicked reaction and years later we might do something sane.
And some of those big customers DO have a clue, just not the ones in the tech business. Ever wondered why all that Cobol and Fortran is still running? Because it works. It is essentially an example of my "frozen code" idea in action.
(Score: 2, Insightful) by Anonymous Coward on Monday May 30 2016, @09:45AM
Argh! My head is about to explode! I find myself agreeing with jmorris.
(Score: 2) by DutchUncle on Wednesday June 01 2016, @07:00PM
"No Silver Bullet" . . . Go ahead, keep rediscovering these concepts. If only they were applied more often.