|
|
Home | Switchboard | Unix Administration | Red Hat | TCP/IP Networks | Neoliberalism | Toxic Managers |
| (slightly skeptical) Educational society promoting "Back to basics" movement against IT overcomplexity and bastardization of classic Unix | |||||||
|
|
Introduction was converted to a separate article due to increased volume. See Note on Fundamental Absurdity of IT Management
|
|
the goal of this page is to introduce into discussioon (and the debate about DevOps) a vital factor that the press tend to ignore -- institutional incompetence of IT management. this problem is somewhat similar to the problem of military incompetence. As French proverb aptly state: the problem with the generals is that we select them from among the colonels. The probem with It management is often much worse: we select them from accountants or supply management specialists. An interesting and immanent aspect of IT management is that due to the complexity of the environment, the higher the rank, the smaller the percentage of competent managers. This also has something to so with Peter Law. So the question that should be asked is not why arise why incompetence is so widespread, but why there are exceptions. Is requirement of competence (whihc encompass both managment competence and technical competence) is asking for too much ? The promotion system definitely reinforces professional ignorance. That's a known fact. Political operatives who play court games well have better chances. This represents corruption of the worst kind, corruption of institutional purpose. Its result is that they know little and care less about their field. Their areas of expertise are in acquiring resources and playing the courtier. Basically, promotion becomes a high school popularity contest. Hubris is virtue. The beancounters have won. Norman Dixon’s book, “On the psychology of military incompetence”, is a valuable model for this sort of analysis. As to the military promotion system, a high degree of political acuity is absolutely required from our senior leadership. Generals may be military leaders, but they also lead huge bureaucracies and are dependent on Congress and the Executive Branch, A politically blind general would be steamrolled by those competing interests and probably be completely ineffective as a result.
that means that instead of technical expertise, other factors such as politicla acument and willingness to please that aloow a person to climb the management ladder and acquire more authority and, eventually, responsibility. And if that particular manager displayed little to no technical ability or architectural vision, it raises doubt as to whether those of his subordinates do either. Bozos bread bozos as Steve Jobs once observed.
Please understand that epic technical incompetence of higher level IT management implementing DevOps is more common than you would think. It is actually typical, because the ultimate goal is to cut costs not to improve the It capabilities. What is typical is over-reliance of consultants (who mercilessly fleece those jerks), technical fads, promotion of cronies and fighting for territory (territorial games). All of those are just different manifestations of two core problems that is immanent DevOps implementation in large corporations -- incompetence and absurdity.
Absurdity is connected with the fact that the current environment is already way to complex for mere mortals to master. DevOps introduces additional "layers of indirection" and makes this environment even more complex. In essence DevOps is a high demand techno cult which ahs a lot of common with religious high demand cults.
There is also another side of technical incompetence -- the systemic rise of various types of careerists, authoritarians (especially double high authoritarians) and psychopath (especially female sociopaths) in IT management ranks. While authoritarians do not directly belong to the category of psychopaths they are no less, if not more, destructive. They are also much more numerous (approximately 4% of psychopaths vs. approximately 20% of authoritarians by some estimates). See
The death and life question of working during DevOps transition in large corporate IT is: how to survive with this absurd environment and incompetent leadership? as well as "How to work within DevOps IT model ? with all its warts.
More complex question is about value of working in large corporations, including large corporate IT departments. Here my message is mixed. There are some unique opportunities within large corporations IT departments that you can't find elsewhere (so please don't assume that I am a simplistic nihilist), but you need to know quite a lot about how complex organization function to survive and prosper in such an environment.
Social skills that are typically severely underdeveloped in many talented programmer and sysadmins are of crucial importance. Learning them is also "life and death" issue, if you intend to survive during and after DevOps implementation. Platitudes about authoritarianism, incompetency, bueracracy and absurdity of environment aren't enough.
I hope that the selection of articles below might be of some limited help.
Dr. Nikolai Bezroukov
|
|
Switchboard | ||||
| Latest | |||||
| Past week | |||||
| Past month | |||||
 |
 |
 |
Dec 19, 2016 | theregister.co.uk
Get real – it's not all about developers and DevOps
Listen to some DevOps evangelists talk, and you would get the impression that IT operations teams exist only to serve the needs of developers. Don't get me wrong, software development is a good competence to have in-house if your organisation depends on custom applications and services to differentiate its business.
As an ex-developer, I appreciate the value of being able to deliver something tailored to a specific need, even if it does pain me to see the shortcuts too often taken nowadays due to ignorance of some of the old disciplines, or an obsession with time-to-market above all else.
But before this degenerates into an 'old guy' rant about 'youngsters today', let's get back to the point that I really want to make.
All of the hype around software and developers, which tends to significantly skew even the DevOps discussion, runs the risk of creating the perception that IT ops is just a necessary evil. Indeed, some go so far as to make the case for a 'NoOps' world in which the public cloud magically takes care of everything downstream once developers have 'innovated' and 'created'.
This kind of view comes about from people looking through the wrong end of the telescope. Turn the thing around and look up close at what goes on in the world of ops, and you get a much better sense of perspective. Teams operating in this space are not just there to deploy the next custom software release and make sure it runs quickly and robustly - in fact that's often a relatively small part of what they do.
This becomes obvious when you recognize how much stuff runs in an Enterprise IT landscape - software packages enabling core business processes, messaging, collaboration and workflow platforms keeping information flowing, analytics environments generating critical business insights, and desktop and mobile estates serving end user access needs - to name but a few.
Vital operationsThere's then everything required to deal with security, data protection, compliance and other aspects of risk. Apart from the odd bit of integration and tailoring work - the need for which is diminishing with modern 'soft-coded', connector-driven solutions - very little of all this has anything to do with development and developers.
A big part of the rationale for modernising your application landscape and migrating to the latest flexible and open software packages and platforms is to eradicate the need for coding wherever you can. Code is expensive to build and maintain, and the same can often be achieved today through software switches, policy-driven workflow, drag-and-drop interface design, and so on. Sensible IT teams only code when they absolutely have to.
And coming back to operations, you are sadly mistaken if you think that the public cloud makes all challenges and requirements go away. If anything, the piecemeal adoption of cloud services has made things more complex and unpredictable from an integration and management perspective.
There are all kinds of valid reasons to keep an application sitting on your own infrastructure anyway - regulation, performance, proximity to dependent solutions and data, etc. Then let's not forget the simple fact that running things in the cloud is often more expensive over the longer term.
Against this background, an 'appropriate' level of custom development and the selective use of cloud services will be the way forward for most organisations, all underpinned by a well-run data centre environment acting as the hub for hybrid delivery. This is the approach that tends to be taken by the most successful enterprise IT teams, and the element that makes particularly high achievers stand out is agile and effective IT operations.
This isn't just to support any DevOps agenda you might have; it is demonstrably a key enabler across the board. Of course if you work in operations, you will know already intuitively know all this. But if you want some ammunition to spell it out to others who need enlightenment, take a look at our research report entitled IT Ops and a Digital Business Enabler; more than just keeping the lights on . This is based on input from 400 Senior European IT professionals. ®
Paul SmithI think this is one fad that has run its course. If nothing else, the one thing that cloud has brought to the software world is the separation of software from the environment it runs in, and since the the Ops side of DevOps is all about the integration of the platform and software, what you end up with in a cloudy world is a lot of people looking for a new job.Anonymous CowardJohn 104For decades developers have been ignored by infrastructure vendors because the decision makers buying infrastructure sit in the infrastructure teams. Now with the cloud etc vendors realize they will lose supporters within these teams.
So instead - infrastructure vendors target developers to become their next fanboys.
E.g. Dear developer, you won't need to speak to your infrastructure admins anymore to setup a development environment. Now you can automate, orchestrate the provisioning of your containerized development environment at the push of a button. Blah blah blah, but you have to buy our storage.
I remember the days when every DBA wanted RAID10 just because thats what the whitepaper recommended. By that time storage technology had long moved on, but the DBA still talked about Full Stripe Writes.
Now with DevOps you'll have Developers influencing infrastructure decisions, because they just learned about snapshots. And yes - it has to be all flash - and designed from the ground up by millenials that eat avocado.
Re: DevOps was never supposed to replace OperationsJohn 104Yes, DevOps isn't about replacing Ops. But try telling that to the powers that be. It is sold and seen as a cost cutting measure.
As for devs learning Ops and vice versa, there are very few on both sides who really understand what it takes to do the others job. I have a very high regard for Devs, but when it comes to infra, they are, as a whole, very incompetent. Just like I'm incompetent in Dev. can't have one without the other. I feel that in time, the pendulum will swing away from cloud as execs and accountants realize how it isn't really saving any money.
The real question is: Will there be any qualified operations engineers available or will they all have retired out or have found work elsewhere. It isn't easy to be an ops engineer, takes a lot of experience to get there, and qualified candidates are hard to come by. Let's face it, in today's world, its a dying breed.
Very NiceNice of you to point out what us in Ops have known all along. I'm afraid it will fall on deaf ears, though. Until the executives who constantly fall for the new shiny are made to actually examine business needs and processes and make business decisions based on said.
Our laughable move to cloud here involved migrating off of on prem Exchange to O365. The idea was to free up our operations team to allow us to do more in house projects. Funny thing is, it takes more management of the service than we ever did on premises. True, we aren't maintaining the Exchange infra, but now we have SQL servers, DCs, ADFS, etc, to maintain in the MS cloud to allow authentication just to use the product. And because mail and messaging is business critical, we have to have geographically disparate instances of both. And the cost isn't pretty. Yay cloud.
|
|
|
May 17, 2017 | theregister.co.uk
Linus Torvalds believes the technology industry's celebration of innovation is smug, self-congratulatory, and self-serving. The term of art he used was more blunt: "The innovation the industry talks about so much is bullshit," he said. "Anybody can innovate. Don't do this big 'think different'... screw that. It's meaningless.
In a deferential interview at the Open Source Leadership Summit in California on Wednesday, conducted by Jim Zemlin, executive director of the Linux Foundation, Torvalds discussed how he has managed the development of the Linux kernel and his attitude toward work.
"All that hype is not where the real work is," said Torvalds. "The real work is in the details."
Torvalds said he subscribes to the view that successful projects are 99 per cent perspiration, and one per cent innovation.
As the creator and benevolent dictator of the open-source Linux kernel , not to mention the inventor of the Git distributed version control system, Torvalds has demonstrated that his approach produces results. It's difficult to overstate the impact that Linux has had on the technology industry. Linux is the dominant operating system for servers. Almost all high-performance computing runs on Linux. And the majority of mobile devices and embedded devices rely on Linux under the hood.
The Linux kernel is perhaps the most successful collaborative technology project of the PC era. Kernel contributors, totaling more than 13,500 since 2005, are adding about 10,000 lines of code, removing 8,000, and modifying between 1,500 and 1,800 daily, according to Zemlin. And this has been going on – though not at the current pace – for more than two and a half decades.
"We've been doing this for 25 years and one of the constant issues we've had is people stepping on each other's toes," said Torvalds. "So for all of that history what we've done is organize the code, organize the flow of code, [and] organize our maintainership so the pain point – which is people disagreeing about a piece of code – basically goes away."
The project is structured so people can work independently, Torvalds explained. "We've been able to really modularize the code and development model so we can do a lot in parallel," he said.
Technology plays an obvious role but process is at least as important, according to Torvalds.
"It's a social project," said Torvalds. "It's about technology and the technology is what makes people able to agree on issues, because ... there's usually a fairly clear right and wrong."
But now that Torvalds isn't personally reviewing every change as he did 20 years ago, he relies on a social network of contributors. "It's the social network and the trust," he said. "...and we have a very strong network. That's why we can have a thousand people involved in every release."
The emphasis on trust explains the difficulty of becoming involved in kernel development, because people can't sign on, submit code, and disappear. "You shoot off a lot of small patches until the point where the maintainers trust you, and at that point you become more than just a guy who sends patches, you become part of the network of trust," said Torvalds.
Ten years ago, Torvalds said he told other kernel contributors that he wanted to have an eight-week release schedule, instead of a release cycle that could drag on for years. The kernel developers managed to reduce their release cycle to around two and half months. And since then, development has continued without much fuss.
"It's almost boring how well our process works," Torvalds said. "All the really stressful times for me have been about process. They haven't been about code. When code doesn't work, that can actually be exciting ... Process problems are a pain in the ass. You never, ever want to have process problems ... That's when people start getting really angry at each other." ®
|
|
|
May 16, 2017 | soleil.wikia.com
The Technocult, also known as the Machine cult is the semi-offical name given by The Church of the Crossed Heart to followers of the Mechanicum faith who supply and maintain virtually all of the church's technology, engineering and industry.Although they serve with the Church of the Crossed Heart they have their own version of worship that differs substantially in theology and ritualistic forms from that of The Twelve Angels . Instead the Technocult worships a deity they call the Machine god or Omnissiah. The Technocult believes that knowledge is divine and comes only form the Omnissiah thus making any objects that demonstrate the application of knowledge , i.e machinery, or contain it (books) holy in the eyes/optical implants of the Techcult. The Technocult regard organic flesh as weak and imperfect, with the Rot being veiwed as a divine message from the Omnissah demonstrating its weakness, thus making its removal and replacement by mechanical, bionic parts a sacred process that brings them closer to their god with many of its older members having very little of their original bodies remaining.
The date of the cults formation is unknown, or a closely guarded secret...
|
|
|
May 16, 2017 | www.allaboutagile.com
1. Saying you're doing Agile just cos you're doing daily stand-ups. You're not doing agile. There is so much more to agile practices than this! Yet I'm surprised how often I've heard that story. It really is remarkable.
... ... ....
3. Thinking that agile is a silver bullet and will solve all your problems. That's so naiive, of course it won't! Humans and software are a complex mix with any methodology, let alone with an added dose of organisational complexity. Agile development will probably help with many things, but it still requires a great deal of skill and there is no magic button.
... ... ...
8. People who use agile as an excuse for having no process or producing no documentation. If documents are required or useful, there's no reason why an agile development team shouldn't produce them. Just not all up-front; do it as required to support each feature or iteration. JFDI (Just F'ing Do It) is not agile!
David, 23 February 2010 at 1:21 am
So agree on number 1. Following "Certified" Scrum Master training (prior to the exam requirement), a manager I know now calls every regular status meeting a "scrum", regardless of project or methodology. Somehow the team is more agile as a result.
Ironically he pulled up another staff member for "incorrectly" using the term retrospective.
Andy Till, 23 February 2010 at 9:28 am
I can think of far worse, how about pairing with the guy in the office who is incapable of compromise?
Steve Watson, 13 May 2010 at 10:06 am
Kelly
Good list!
I like number 9 as I find with testing people think that they no longer need to write proper test cases and scripts – a list of confirmations on a user story will do. Well, if its a simple change I guess you can dispense with test scripts, but if its something more complex then there is no reason NOT to write scripts. If you have a reasonably large team of people who could execute the tests, they can follow the test steps and validate against the expected results. It also means that you can sensibly lump together test cases and cover them with one test.
If you dont think about how you will execute them and just tackle them one by one off the confirmations list, you miss the opportunity to run one test and cover many separate cases, saving time.
I always find test scripts useful if someone different re-runs a test, as they then follow the same process as before. This is why we automate regression so the tests are executed the same each time.
John Quincy, 24 October 2011 at 12:02 am
I am not a fan of agile. Unless you have a small group of developers who are in perfect sync with each other at all times, this "one size fits all" methodology is destructive and downright dangerous. I have personally witnessed a very good company go out of business this year because they transformed their development shop from a home-grown iterative methodology to SCRUM. The team was required to abide by the SCRUM rules 100%. They could not keep up with customer requirements and produced bug filled releases that were always late. These developers went from fun, friendly, happy people (pre-SCRUM) [who NEVER missed a date] to bitter, sarcastic, hard to be around 'employees'. When the writing was on the wall a couple of months back, the good ones got the hell out of there, and the company could not recover.
Some day, I'm convinced that Beck through Thomas will proclaim that the Agile Manifesto was all a big practical joke that got out of control.
This video pretty much lays out the one and only reason why management wants to implement Agile:
grumpasaurus, 9 February 2014 at 4:30 pm
It's a cycle of violence when a project claims to be Agile just because of standups and iterations and don't think about resolving the core challenges they've had to begin with. People are left still battling said challenges and then say that Agile sucks.
|
|
|
Jun 06, 2014 | www.infoq.com
Rachel Shannon-Solomon suggests that most enterprises are not ready for DevOps, while Gene Kim says that they must make themselves ready if they want to survive.Rachel Shannon-Solomon, a venture associate at At Work-Bench, has recently written a blog post for The Wall Street Journal entitled DevOps Is Great for Startups, but for Enterprises It Won't Work-Yet , arguing that while DevOps is appealing to startups, there are important stumbling blocks in the path of DevOps adoption within the enterprise.
While acknowledging that large companies such as Google and Facebook benefit from implementing DevOps, and that "there is no lack of appetite to experiment with DevOps practices" within "Fortune 500s and specifically financial services firms", Shannon-Solomon remarks that "there are few true change agents within enterprise IT willing to affect DevOps implementations."
Shehas come to this conclusion basedon "conversations with startup founders, technology incumbents offering DevOps solutions, and technologists within large enterprises."
Shannon-Solomon brings four arguments to support her position:
- Siloed structures and organizational change . According to Shannon-Solomon, enterprises create siloed structures between teams because that's how large organizations maximize value results, and one of DevOps'main purpose is to bring thosesilos down. Sometimes a large company relies on another vendor for operational support, and such vendors "tend to bring their own degree of siloing." Also, it is expensive for an enterprise to invest into "holistic solutions to facilitate DevOps" after they "invested heavily on integration for existing solutions."
- Buy vs. build. The tools needed to implement a DevOps culture are lacking. While some of the tools can be provided by vendors and others can be created within the enterprise, a process which takes a long period of time, "there is a marathon of organizational change and restructuring that must occur before such tools could ever be bought or built."
- Vendors of DevOps solutions acknowledge that when selling to the enterprise, they are trying to sell a cultural revolution. According to Shannon-Solomon, it is hard to introduce DevOps to development teams because Vendors need to first win over individual developers with the efficiency of their solution, for example, by initially eschewing procurement and offering a sandbox environment directly to developers to test out the environment.
Selling DevOps toolkits to the enterprise means facing the well-documented challenges of navigating procurement and a mindset currently more primed to build than buy DevOps tools.
- Return on investment . Shannon-Solomon cites a senior IT professional working at an investment bank saying that his company "has not been very successful at tracking DevOps projects occurring within individual business units using homegrown tools, and any evaluation of a project's success has been limited to anecdotal assessments and perceived results."
Shannon-Solomonends her post wondering "how long will it be until enterprises are forced to accept that they must accelerate their experiments with DevOps" and hoping that "more individual change agents within large organizations may emerge" in the future.
|
|
|
Jun 05, 2013 | Slashdot
"What developers see as iterative and flexible, users see as disorganized and never-ending.
This article discusses how some experienced developers have changed that perception. '... She's been frustrated by her Agile experiences - and so have her clients.
"There is no process. Things fly all directions, and despite SVN [version control] developers overwrite each other and then have to have meetings to discuss why things were changed. Too many people are involved, and, again, I repeat, there is no process.' The premise here is not that Agile sucks - quite to the contrary - but that developers have to understand how Agile processes can make users anxious, and learn to respond to those fears. Not all those answers are foolproof.
For example: 'Detailed designs and planning done prior to a project seems to provide a "safety net" to business sponsors, says Semeniuk. "By providing a Big Design Up Front you are pacifying this request by giving them a best guess based on what you know at that time - which is at best partial or incorrect in the first place." The danger, he cautions, is when Big Design becomes Big Commitment - as sometimes business sponsors see this plan as something that needs to be tracked against.
"The big concern with doing a Big Design up front is when it sets a rigid expectation that must be met, regardless of the changes and knowledge discovered along the way," says Semeniuk.' How do you respond to user anxiety from Agile processes?"
Shinobi
Agile summed up (Score:5, Funny)
Agile is to proper software engineering what Red Bull Flugtag is to proper aeronautic engineering....
Nerdfest
Re: doesn't work
As TFA points out, that always works fine when your requirements are *all* known an are completely static. That rarely happens in most fields.
Even in the ones where it does it's usually just management having the balls to say "No, you can give us the next bunch of additions and changes when this is delivered, we agreed on that". It frequently ends up delivering something less than useful.
MichaelSmith
Re: doesn't work (Score:5, Insightful)
The problem with Agile is that it gives too much freedom to the customer to change their mind late in the project and make the developers do it all over again.
ArsonSmith
Re: doesn't work (Score:4, Insightful)
...but they can be trusted to say what is most important to them at the time.
No they can't. If you are delivering to customer requests you will always be a follower and never succeed. You need to anticipate what the customers need. As with the I guess made up quote attributed to Henry Ford, "If I listened to my customers I'd have been trying to make faster horses." Whether he said it or not, the statement is true. Customers know what they have and just want it to be faster/better/etc you need to find out what they really need.
AuMatar
Re: doesn't work (Score:5, Insightful)
It frequently is. It doesn't matter what methodology you use -- if you change major features/priorities at the last minute it will cost multiple times as much. Yet frequently customers expect it to be cheap because "we're agile". And by accepting that change will happen you don't push the customers to make important decisions early, ensuring that major changes will happen, instead of just being possible.
ebno-10db
Re: doesn't work (Score:5, Interesting)
"Proper software engineering" doesn't work.
You're right, but you're going to the other extreme. The problem with all methodologies, or processes, or whatever today's buzzword is, is that too many people want to practice them in their purest form. Excessive zeal in using any one approach is the enemy of getting things done.
On a sufficiently large project, some kind of upfront design is necessary. Spending too much time on it or going into too much detail is a waste though. Once you start to implement things, you'll see what was overlooked or why some things won't work as planned. If you insist on spinning back every little change to a monstrously detailed Master Design Document, you'll move at a snail's pace. As much as I hate the buzzword "design patterns", some pattern is highly desirable. Don't get bent out of shape though when someone has a good reason for occasionally breaking that pattern or, as you say, you'll wind up with 500 SLOC's to add 2+2 in the approved manner.
Lastly, I agree that there is no substitute for good engineers who actually talk to and work with each other. Also don't require that every 2 bit decision they make amongst themselves has to be cleared, or even communicated, to the highest levels. If you don't trust those people to make intelligent decisions (including about when things do have to be passed up) then you've either got the wrong people or a micromanagement fetish. Without good people you'll never get anything decent done, but with good people you still need some kind of organization.
The problem the article refers to about an upfront design being ironclad promises is tough. Some customers will work with you, and others will get their lawyers and "systems" people to waste your time complaining about every discrepancy, without regard to how important it is. Admittedly bad vendors will try and screw their customers with "that doesn't matter" to excuse every screw-up and bit of laziness. For that reason I much prefer working on in-house projects, where "sure we could do exactly what we planned" gets balanced with the cost and other tradeoffs.
The worst example of those problems is defense projects. As someone I used to work with said: In defense everything has to meet spec, but it doesn't have to work. In the commercial world specs are flexible, but it has to work.
If you've ever worked in that atmosphere you'll understand why every defense project costs a trillion dollars. There is absolutely no willingness to make tradeoffs as the design progresses and you find out what's practical and necessary and what's not. I'm not talking about meeting difficult requirements if they serve a purpose (that's what you're paid for) but being unwilling to compromise on any spec that somebody at the beginning of the project pulled out of their posterior and obviously doesn't need to be so stringent. An elephant is a mouse built to government specifications.
Ok, you can get such things changed, but it requires 10 hours from program managers for every hour of engineering. Conversely, don't even think about offering a feature or capability that will be useful and easy to implement, but is not in the spec. They'll just start writing additional specs to define it and screw you by insisting you meet those.
As you might imagine, I'm very happy to be back in the commercial world.
Anonymous Coward
Re: doesn't work (Score:2, Interesting)
You've fallen into the trap of using their terminology. As soon as 'the problem' is defined in terms of 'upfront design', you've already lost half the ideological battle.
'The problem' (with methodology) is that people want to avoid the difficult work of thinking hard about the business/customer's problem and coming up with solutions that meet all their needs. But there isn't a substitute for thinking hard about the problem and almost certainly never will be.
The earlier you do that hard thinking about the customer's problems that you are trying to solve the cheaper, faster and better quality the result will be. Cheaper? Yes, because bugfixing that is done later in the project is a lot more expensive (as numerous software engineering studies have shown) Faster? Yes, because there's less rework. (Also, since there is usually a time = money equivalency, you can't have it done cheap unless it is also done fast. Higher quality? Yes, because you don't just randomly stumble across quality. Good design trumps bad design every single time.
... ... ...
ebno-10db
Re: doesn't work (Score:4, Interesting)
Until the thing is built or the software is shipped there are many options and care should be taken that artificial administrative constraints don't remove too many of them.
Exactly, and as someone who does both hardware and software I can tell you that that's better understood by Whoever Controls The Great Spec in hardware than in software. Hardware is understood to have physical constraints, so not every change is seen as the result of a screw-up. It's a mentality.
I'll also admit that there is a tendency to get sloppy in software specs because it is easier to make changes. Hardware, with the need to order materials, have things fabbed, tape out a chip, whatever, imposes a certain discipline that's lacking when you know you can change the source code at anytime. Being both, I'm not saying this is because hardware engineers are virtuous and software engineers are sloppy, but because engineers are human (at least some of them).
ebno-10db
Re: doesn't work (Score:2)
http://www.fastcompany.com/28121/they-write-right-stuff
This is my evidence that "proper software engineering" *can* work. The fact that most businesses (and their customers) are willing to save money by accepting less from their software is not the fault of software engineering. We could and did build buildings much faster than we do today, if you are willing to make more mistakes and pay more in human lives. If established industries and their customers began demanding software at that higher standard and were willing to pay for it like it was real engineering, then maybe it would happen more often.
Impressive stuff, and not unique to the space shuttle. Fly-by-wire systems are the same way. You're talking DO-178B [wikipedia.org] Level A stuff. It works, and it's very very expensive. If it was only 10x the cost of normal software development I'd be amazed. I agree that way too much software is poorly planned and implemented crap, and part of the reason is that nobody wants realistic cost estimates or to make the difficult decisions about what it's supposed to do up-front. But what you're talking about is aerospace quality. You couldn't afford a car or even a dishwasher made to those standards.
donscarletti
Re: doesn't work (Score:3)
260 people maintaining 420,000 lines of code, written to precise externally provided specifications that change once every few years.
This is fine for NASA, but if you want something that does roughly what you need before your competitors come up with something better, you'd better find some better programmers.
|
|
|
May 15, 2017 | blog.appdynamics.com
In light of all the hype, we have created a DevOps parody Series – DevOps: Fact or Fiction .
For those of you who did not see, in October we created an entirely separateblog(inspired by this ) – however decided that it is relevant enough to transform into a series on the AppDynamics Blog . The series will point out the good, the bad, and the funny about IT and DevOps. Don't take anything too seriously – it's nearly 100% stereotypes : ).
Stay tuned for more DevOps: Fact or Fiction to come. Here we go
|
|
|
Apr 15, 2014 | jeffknupp.com
How 'DevOps' is Killing the DeveloperThere are two recent trends I really hate: DevOps and the notion of the "full-stack" developer. The DevOps movement is so popular that I may as well say I hate the x86 architecture or monolithic kernels. But it's true: I can't stand it. The underlying cause of my pain? This fact: not every company is a start-up, though it appears that every company must act as though they were. DevOps
"DevOps" is meant to denote a close collaboration and cross-pollination between what were previously purely development roles, purely operations roles, and purely QA roles. Because software needs to be released at an ever-increasing rate, the old "waterfall" develop-test-release cycle is seen as broken. Developers must also take responsibility for the quality of the testing and release environments.
The increasing scope of responsibility of the "developer" (whether or not that term is even appropriate anymore is debatable) has given rise to a chimera-like job candidate: the "full-stack" developer. Such a developer is capable of doing the job of developer, QA team member, operations analyst, sysadmin, and DBA. Before you accuse me of hyperbole, go back and read that list again. Is there any role in the list whose duties you wouldn't expect a "full-stack" developer to be well versed in?
Where did these concepts come from? Start-ups, of course (and the Agile methodology). Start-ups are a peculiar beast and need to function in a very lean way to survive their first few years. I don't deny this . Unfortunately, we've taken the multiple technical roles that engineers at start-ups were forced to play due to lack of resources into a set of minimum qualifications for the role of "developer".
Many HatsImagine you're at a start-up with a development team of seven. You're one year into development of a web applications that X's all the Y's and things are going well, though it's always a frantic scramble to keep everything going. If there's a particularly nasty issue that seems to require deep database knowledge, you don't have the liberty of saying "that's not my specialty," and handing it off to a DBA team to investigate. Due to constrained resources, you're forced to take on the role of DBA and fix the issue yourself.
Now expand that scenario across all the roles listed earlier. At any one time, a developer at a start-up may be acting as a developer, QA tester, deployment/operations analyst, sysadmin, or DBA. That's just the nature of the business, and some people thrive in that type of environment. Somewhere along the way, however, we tricked ourselves into thinking that because, at any one time, a start-up developer had to take on different roles he or she should actually be all those things at once.
If such people even existed , "full-stack" developers still wouldn't be used as they should. Rather than temporarily taking on a single role for a short period of time, then transitioning into the next role, they are meant to be performing all the roles, all the time . And here's what really sucks: most good developers can almost pull this off.
The Totem PoleGood developers are smart people. I know I'm going to get a ton of hate mail, but there is a hierarchy of usefulness of technology roles in an organization. Developer is at the top, followed by sysadmin and DBA. QA teams, "operations" people, release coordinators and the like are at the bottom of the totem pole. Why is it arranged like this?
Because each role can do the job of all roles below it if necessary.
Start-ups taught us this. Good developers can be passable DBAs, if need be. They make decent testers, "deployment engineers", and whatever other ridiculous term you'd like to use. Their job requires them to know much of the domain of "lower" roles. There's one big problem with this, and hopefully by now you see it: It doesn't work in the opposite direction.
A QA person can't just do the job of a developer in a pinch, nor can a build-engineer do the job of a DBA. They never acquired the specialized knowledge required to perform the role. And that's fine. Like it or not, there are hierarchies in every organization, and people have different skill sets and levels of ability. However, when you make developers take on other roles, you don't have anyone to take on the role of development!
An example will make this more clear. My dad is a dentist running his own practice. He employs a secretary, hygienist, and dental assistant. Under some sort of "DentOps" movement, my dad would be making appointments and cleaning people's teeth while trying to find time to drill cavities, perform root canals, etc. My dad can do all of the other jobs in his office, because he has all the specialized knowledge required to do so. But no one, not even all of his employees combined, can do his job.
Such a movement does a disservice to everyone involved, except (of course) employers. What began as an experiment aimed at increasing software quality has become a farce, where the most talented employees are overworked (while doing less, less useful work) and lower-level positions simply don't exist.
And this is the crux of the issue. All of the positions previously held by people of various levels of ability are made redundant by the "full-stack" engineer. Large companies love this, as it means they can hire far fewer people to do the same amount of work. In the process, though, actual development becomes a vanishingly small part of a developer's job . This is why we see so many developers that can't pass FizzBuzz: they never really had to write any code. All too common a question now, can you imagine interviewing a chef and asking him what portion of the day he actually devotes to cooking?
Jack of All Trades, Master of NoneIf you are a developer of moderately sized software, you need a deployment system in place. Quick, what are the benefits and drawbacks of the following such systems: Puppet, Chef, Salt, Ansible, Vagrant, Docker. Now implement your deployment solution! Did you even realize which systems had no business being in that list?
We specialize for a reason: human beings are only capable of retaining so much knowledge. Task-switching is cognitively expensive. Forcing developers to take on additional roles traditionally performed by specialists means that they:
- aren't spending their time developing
- need to keep up with an enormous domain of knowledge
- are going to burn out
What's more, by forcing developers to take on "full-stack" responsibilities, they are paying their employees far more than the market average for most of those tasks. If a developer makes 100K a year, you can pay four developers 100K per year to do 50% development and 50% release management on a single, two-person task. Or, simply hire a release manager at, say, 75K and two developers who develop full-time. And notice the time wasted by developers who are part time release-managers but don't always have releases to manage.
Don't Kill the DeveloperThe effect of all of this is to destroy the role of "developer" and replace it with a sort of "technology utility-player". Every developer I know got into programming because they actually enjoyed doing it (at one point). You do a disservice to everyone involved when you force your brightest people to take on additional roles.
Not every company is a start-up. Start-ups don't make developers wear multiple hats by choice, they do so out of necessity. Your company likely has enough resource constraints without you inventing some. Please, don't confuse "being lean" with "running with the fewest possible employees". And for God's sake, let developers write code!
Enno • 2 years agoSome background... I started life as a dev (30years ago), have mostly been doing sysadmin and project tech lead sorts of work for the last 15. I've always assumed the DevOps movement was resulting in sub-par development and sub-par sysadmin/ops precisely because people were timesharing their concerns.Zakaria ANBARI -> Enno • 2 years agoBut what it does bring to the party is a greater level of awareness of the other guys problems. There's nothing quite like being rung out of bed at 3am to motivate a developer to improve his products logging to make supporting it easier. Similarly the admin exposed to the vagaries of promoting things into production in a supportable, repeatable, deterministic manner quickly learns to appreciate the issues there. So DevOps has served a purpose and has offered benefits to the organisations that signed on for it.
But, you're right. Pure DevOps is no more efficient or sensible than pure Agile (or the pure Extreme Programming or the pure Structured Programming that preceeded it). The problem is purists and ideological zealotry not the particular brand of religion in question. Insistence on adherence to dogma is the problem as it prevents adoption of flexible, 'fit for purpose' solutions. Exposure to all the alternatives is good. Insisting that one hammer is ideal for every sort of nail we have and ever will have is not.
totally agree with you !DevOps Reaper • 2 years agoI'm very disappointed to see this kind of rubbish. It's this type of egocentric thinking and generalization that the developer is an omniscient deity requiring worshiping and pampering that prevents DevOps from being successful. Based on the tone and your perspective it sounds like you've been doing DevOps wrong.spunky brewster -> DevOps Reaper • a month agoA developer role alone is not the linchpin that keeps DevOps humming - instead it's the respect that each team member holds for each discipline and each team member's area of expertise, the willingness of the entire team to own the product, feature delivery and operational stability end to end, to leverage each others skills and abilities, to not blame Dev or Ops or QA for failure, and to share knowledge.
There are developers who have a decent set of skills outside of development in QA, Operations, DB Admin, Networking, etc. Equally so, there are operations engineers who have a decent set of skills outside of operations in QA, Development, DB Admin, networking, etc. Extend this to QA and other disciplines. What I have never seen is one person who can perform all those jobs outside of their main discipline with the same level of professionalism, experience and acumen that each of those roles require to do it well at an Enterprise/World Class level.
If you're a developer doing QA and operations, you're doing it because you have to, but there should be no illusion that you're as good in alternate roles as someone trained and experienced in those disciplines. To do so is a disservice to yourself and your organization that signs your paycheck. If you're in this situation and you'd prefer making a difference rather than spewing complains, I would recommend talking to your manager and above about changing their skewed vision of DevOps. If they aren't open to communication, collaboration, experimentation and continual improvement, then their DevOps vision is dysfunctional and they're not supporting DevOps from the top down. Saying your DevOps and not doing it is *almost* more egregious than saying the developer is the top of a Totem Pole of existence.
he prefaced it with 'crybabies please ignore' It's his opinion. That everyone but the lower totem pole people agree with so.. agree to disagree. I also don't think being at the bottom of the totem pole is a big f'in deal. If you're getting paid.. embrace it! So many other ways to enjoy life! The top dog people have all the pressure and die young! 99% of the people on earth dont know the difference between one nerd and another. And other nerds are always going to be egomaniacs who will find some way to justify their own superiority no matter what your achievements. So this kind of posturing is a waste of time.Pramod • 2 years agoAmen to that!!carlivar • 2 years agoI think there's a problem with your definition of DevOps. It doesn't mean developers have to be "full-stack" or do ops stuff. And it doesn't mean "act like a startup." It simply means, at its basis, that Developers and Operations work well together and do not have any communication barriers. This is why I hate DevOps as a title or department, because DevOps is a culture.StillMan -> carlivar • 2 years agoLet's take your DentOps example. The dentist has 3 support staff. What if they rarely spoke to the dentist? What if they were on different floors of the building? What if the dentist wrote an email about how teeth should be cleaned and wasn't available to answer questions or willing to consider feedback? What if once in a while the dentist needed to understand enough about the basics of appointment scheduling to point out problems with the system? Maybe appointments are being scheduled too close together. Would the patients get backed up throughout the day because that's the secretary's problem? Of course not. Now we'd be getting into a more accurate analogy to DevOps. If anything a dentist's office is ALREADY "DentOps" and the whole point of DevOps is to make the dev/ops interaction work in a logical culture that other industries (like dentists) already use!
I would tend to agree with some of that. Being able to trouble shoot network issues using monitoring tools like Fiddler is a good thing to be aware of. I can also see a lot of companies using it as a way to make one person do everything. Moreover, there are probably folks out there that perpetuate that behavior by taking on the machismo argument.spunky brewster -> carlivar • a month agoBy saying that if I can do it that you should be able to do it too or else you're not as good of a developer as I am. I have never heard anyone outright claim this, but I've seen this attitude time and time again from ambitious analysts looking to get a leg up, a pay raise, and a way to template their values on the rest of the team. One of the first things that you're taught as a dev is that you can't hope to know it all.
Your responsibility first and foremost as a developer is the stability and reliability of your code and the services that you provide. In some industries this is literally a matter of life and death(computers in your car, mission critical medical systems). It doesn't work for everyplace.
Ole Hauris -> Sørensen • 2 years agoI wouldn't want to pay a receptionist 200k a year like a dentist though. Learn to hire better receptionists. Even a moderately charming woman can create more customer loyalty, and cheaper, than the best dentist in the world. I want my dentist to keep quiet and have a steady hand. I want my receptionist to engage me and acknolwedge my existence.
I want my secretary to be a multitasking master. I want my dentist not to multitask at all - OUCH!
Good points, I tend to agree. I prefer to think of DevOps as more of a full-stack team concept. Applying the full-stack principle at the individual levels is not sustainable, as you point out.ceposta Ole Hauris Sørensen • 2 years ago +1.The full-stack DevOps team will have team members with primary skills in either of the traditional specialties, and will, over time, develop decent secondary skills. But the value is not in people constantly content switching - that actually kills efficiency. The value is in developers understanding and developing an open relationship with testing and operations - and vice versa. And this cooperation is inhibited by putting people in separate teams with conflicting goals. DevOps in practice is not a despecialization. It's bringing the specialists together.
Julio • 2 years agoThe more isolated or silo'd developers become, the less they realize what constitutes delivering software, and the more problems are contributed to the IT process of test/build/release/scale/monitor, etc. Writing code is a small fraction of that delivery process. I've written about the success of devops and microservices that touches on this stuff because they're highly related. The future success of devops/microservices/cloud/etc isn't related to technology insofar as it is culture: http://blog.christianposta....
Thanks for the post!
Cody • 2 years agoInteresting points were raised. Solid arguments. I identified with this text and my current difficulties as developer.
Great article and you're definitely describing one form of dysfunctional organisation where DevOps, Agile, Full Stack, and every other $2 word has been corrupted to become a cost cutting justification; cramming more work onto people who aren't skilled for it, and eho end up not having any time to do what they were hired as experts for!Zac Smith • 6 months agoBut I'd also agree with other posters that it's a little developer centric. I'm a terrible programmer and a great DBA. I can tell you most programmers who try to be DBAs are equally terrible. It's definitely not "doing the job of the receptionist" 😄
And we shouldn't forget what DevOps is meant to be about; teams making sure nobody gets called at night to fix each other's messes. That means neither developers with shitty deployments straight to production nor operations letting the disks silently fill because "if it ain't C: it ain't our problem."
I know of 0 developers that can manage a network of any appreciable scale.spunky brewster Zac Smith • a month agoIn cloud and large enterprise networks, if there were a totem (which there isn't) using your methodology would place the dev under the network engineer. Their software implements the protocol and configuration intent of the NE. Good thing the whole concept is a pile of rubbish. I think you fell into the trap you called out which is thinking at limited scale.
It's true. We can all create LAN's at home but I wouldn't dare f with a corporate network and risk shutting down amazon for a day. Which seems to happen quite a bit.... maybe they're DEVOPPING a bit too much.David Rawk Zac Smith • 6 months agoI tend to agree.. they are not under, but beside.. Both require a heap of skill and that includes coding.. but vastly different code.Wilmer • 9 months agoJeff Knupp is to one side of the spectrum. DevOps Reaper is to the other side.ישראל פרוכטר Wilmer • 8 months agoEnno is more attune to what is really going on. So I won't repeat any of those arguments.
However I will ask you to put me in a box. What am I?
I graduated as a Computer Engineer (hybrid between Electrical Engineering and Computer Science). I don't say that anymore as companies have no idea as to what that means. So I called myself a Digital Electronics and Software Engineer for a while. The repeated question was all too often: "So what are you, software or hardware?"
I spent my first few years working down from board design, writing VHDL and Verilog, to embedded software in C and C++, then algorithms in optimization with the CUDA framework in C, with C++ wrappers and C# for the logic tier. Then worked another few year in particle physics with C++ compute engines with x86 assembly declarations for speed and C# for WPF UIs.After that I went to work for a wind turbines company as system architect where is was mostly embedded and programming ARM Cortex microprocessors, high power electronics controls, custom service and diagnostics tools in C#. Real-time web based dashboards with Angular, Bootrap, and the likes for a good looking web app.
Nowadays I'm working with mobile first web applications that have a massive backend to power them. It is mostly a .NET stack form Entity Framework, to .NET WebAPI, to Angular power font ends. This company is not a start up but it is a small company. Therefore I wear the many hats. I introduced the new software life cycle with includes continuous integration and continuous deployment. Yes, I manage build servers, build tools, I develop, I'm QA, I'm a tester, I'm a DBA., I'm the deployment and configuration manager.If you are wondering I have resorted to start calling a full stack developer. It has that edgy sound that companies like to hear. I'm still a young developer. I've only been developing for 10 years.
In my team we are all "Jack of all Trades" and "Masters of Many". We switch tasks and hats because it is fun and keep everyone from getting bored/stuck. Our process is called "Best practices that work for this team".
So, I think of myself as a software engineer. I think I'm a developer. I think I'm DevOps, I think I'm QA.
I join you with the lack of title, we don't need those titles (only when HR people are involved, and we need to kind of fake our persona anyhow...)Matt King • a year agoLets start with that DevOps didn't come from startups. It came from Boeing mainly, and a few other major blue chip IT shops, investing heavily in systems management technology around the turn of the century. The goal at the time was simply to change the ratio of servers to IT support personnel, and the re-thinking and re-organizing of development and operations into one organization with one set of common goals. The 'wearing many hats' thing you discuss is a feature of startups, but that feature is independent of siloed or integrated organizations.BosnianDolphin • 2 years agoI prefer the 'sportzing' analogy of basketball and football. Football has specialist teams that are largely functionally independent because they focus on distinct goals. Basketball has specialist positions, but the whole team is focused on the same goals. I'm not saying one sport is better than the other. I am saying the basketball mentality works better in the IT environment. Delivering the product or service to the customer is the common goal that everyone should be thinking about, and how the details of their job fits into that overall picture. It sounds like to me you are really saying "Hey, its my job and only my job to think about how it all fits together and works"
Secondly, while it is pretty clear that the phrase 'full stack engineer' is about as useful as "Cloud Computing", your perspective that somehow developers are the 'top' of the tree able to do any job is very mistaken. There are key contributors from every specialty who have that ability, and more useful names for them are things like "10x", or "T-shaped". Again, you are describing a real situation, but correlating it with unrelated associations. It is just as likely, and just as valuable, to find an information architect who can also code, or a systems admin that can also diagnose database performance, or an electrician that can also hang sheetrock. Those people do fit your analogy of 'being on top', because they are not siloed and stovepiped into just their speciality.
The DevOps mindset fosters this way of thinking, instead of the old and outdated specialist way of thinking you are defending. Is it possible your emotional reaction is fear based against the possibility that your relative value will decrease if others start thinking outside their boxes?
Interesting to note that Agile also started at Boeing, but 10 years earlier. I live in the startup world of Seattle, but know my history and realize that much of what appears new is actually just 'new to you'(or me), and that most of cutting edge technology and thinking is just combining ideas from other industries in new ways.
Safespace Scooter • 2 years agoAgree on most points, but nobody needs DBA - unless it is some massive project. DBA people should pick up new skills fast.
The problem is that developers are trained to crank out code and hope that QA teams will find problems, many times not even sure how to catch holes. DevOps trains people to think critically and do both. It isn't killing developers, it is making them look like noobs while phasing them out.strangedays Safespace Scooter • a year agoYeah, good luck with that attitude. Your company's gonna have a good'ole time looking for and keeping new developer talent. Because as we all know, smart people love working with dummies. I'd love to see 'your QA' team work on our 'spatial collision algorithm' and make our devs "look like noob". You sound like most middle management schmucks.Manachi • 2 years agoFantastic article! I was going to start honing in on the points I particularly agree with but all of it is just spot on. Great post.Ralli Soph • 9 days agoFunniest article so far on full stack. It's a harsh reality for devs, because were asked to do everything, know everything, so how can you really believe QA or DBA can do the job of someone like that? There is a crazy amount of hours a fullstack dev invests in aquiring that kind of knowledge, not to mention some people are also talented at their job. Imagine trying to tell the QA to do that? Maybe for a few hours someone can be a backup just in case something happens, but really it's like replacing the head surgeon.spunky brewster • a month agoThe best skill you can learn in your coding career is your next career. Noone wants a 45 year old coder.hrmilo • 3 months agoI see so much time wasted learning every new thing when you should just be plugging away to get the job done, bank the $$, and move on. All your accumulated skills will be worthless in a decade or so, and your entire knowledge useless in 2 decades. My ability to turn a wrench is what's keeping me from the poor house. And I have a engineering degree from UIUC! I also don't mind. Think about a 100 week as a plumber with OT in a reasonably priced neighborhood, vs a coder. Who do you think is making more? Now I'm not saying you cant survive into your 50's programming, but typically they get retired forcefully, and permanently.. by a heart attack!
But rambling aside.. the author makes a good point and i think is the future of big companies in tech. The current model is driven by temporary factors. Ideally you'd have a specialized workforce. But I think that as a programmer you are in constant fear of being obsolete so you don't want to be pigeon-holed. It's just not mathematically possible to have that 10,000 hour mastery in 50 different areas.. unless you are Bill Murray in Groundhog Day.
A developer who sees himself at the top of a pyramid. Not surprising, your myopic and egotistical view. I laugh at people who code a few SELECT statements and think they can fill the DBA role. HA HA HA. God, the arrogance. "Well it worked on my machine." - How many sys admins have heard this out of a developers mouth. Unfortunately, projects get stuck with supporting such issues because that very ego has led the developer too far down the road to turn back. They had no common sense or modesty to call on the knowledge of their Sys Ops team to help design the application. I interview jobs candidates all the time calling themselves full stack simply because they compliment their programming language of choice with a mere smattering of knowledge in client-side technologies and can write a few SQL queries. Most developers have NO PERCEPTION of the myriad intricacies it takes to get an application from their unabated desktop with its FULL ADMIN perms and "unlimited resources", through a staging/QA environment, and eventually to the securely locked down production system with limited and perhaps shared or hosted limited resources. Respect of your support teams, communication and coordination, and the knowledge that you do not know it all. THAT'S being Full Stack and DevOps sir.spunky brewster hrmilo • a month agothere's always that one query that noone can do in a way that takes less than 2 hours until u pass it off to a real DBA.. its the 80/20 rule basically. I truly dont believe 'full stack' exists. It's an illusion. There's always something that suffers.Ivan Gavrilyuk • 6 months ago IThe real problem is smart people are in such demand we're forced to adapt to this tribal pre-civilization hodgepodge. Once the industry matures, it'll disappear. Until then they will think they re-invented the wheel.
'm confused here. DevOps roles are strictly automation focused, at least according to all job specifications I see on the internet. They don't need any development skills at all. To me it looks like a new term for what we used to call IT Operations, but more scripting/automation focused. DevOps engineer will need to know Puppet, Chef, Ansible, OS management, public cloud management, know how to set up monitoring, logging and all that stuff usual sysadmin used to do but in the modern world. In fact I used to apply for DevOps roles but quickly changed my mind as it turned out no companies need a person wearing many hats, it has absolutely nothing to do with creating software. Am I wrong?
Mario Bisignani Ivan Gavrilyuk • 4 months ago
It depends on what you mean with development skills. Have you ever tried to automate the deployment of a large web application? In fact the scripts that automate the deployment of large scalable web applications are pretty complex softwares which require in-depth thinking and should follow all the important principles a good developers should know: components isolation, scalability, maintainability, extensibility, etc..Valentin Georgiev • 10 months ago1k% agree with this article!TechZilla • a year agoSuccessful DevOps doesn't mean a full stack developer does it all, that's only true for a broken company that succeeded despite bad organization. For example, Twitter's Dev only culture is downright sick, and ONLY works because they are in the tech field. Mind you, I still believe personally that it works for them DESPITE its unbalanced structure. In other words, bad DevOps means the Dev has no extra resources and just more requirements, yea that sucks!....Adi Chiru • a year agoBUT, on the flip,
Infrastructure works with QA/Build to define supportable deployment standards, they gotta learn all the automatic bits and practice using them. Now Devs have to package all their applications properly, in the formats supported by QABuild's CI and Repositories (that 'working just fine' install script definitly doesn't count). BUT the Dev's get pre-made CI-ready examples, and if needed, code-migration assistance from the QA/Build team. Pretty soon they learn how to package that type of app, like a J2EE Maven EAR, or a Webdeploy to IIS.... and the rest should be hadled for them, as automaticlly as possible by the proactive operations teams.
Make sense? This is how its supposed to work, It sounds like your left alone in a terrible Dev Only/heavy world. The key to DevOps that is great, and everybody likes, vs. more work... is having a very balanced work flow between the teams, and making sure the pass-off points are VERY well defined. Essentially it requires management that cut the responsibility properly, so they have a shared interest in collaborating. In a Dev heavy organization, the Devs can just throw garbage over the wall, and operations has to react to constant problems... they start to hate each other and ..... Dev managers get the idea that they can cut out ops if they do "DevOps", so then they throw it all at you like right now.
Max Börebäck • a year agoI see in this post so much rubbish and narrow mindedness, so much of the exact stuff that is killing any type of companies. In the last 10 years I had many roles that required of me, as a system engineer, to come in and straighten out all kind of really bad compromises developers did just to make stuff work.
The role never shows the level of intelligence or capabilities. I've seen so many situations in the last 10 years when smart people with the wrong attitude and awareness are too smart for anyone's good and limited people still providing more value than a very smart ones acting as if he is too smart to even have a conversation about anything.
This post is embarrassing for you Jeff, I am sorry for you man.... you just don't get it!
A developer do not have to do full stack, the developer can continue with development, but has to adopt some things for packaging,testing, and how it is operated.Peperud • a year ago
Operations can continue with operations, but has to know how things are built and packaged.
Developers and operations needs to share things like use the same application server for example. Developer needs to understand how it is operated to make sure that the code is written in a proper way. Operations needs to adopt in the need for fast delivery and be able to support a controlled way of deploying daily into production.
Here is a complementing post I have around the topic
http://bit.ly/1r3iVffVery much agree with you Jeff. I've been thinking along these lines for awhile now...Lenny Joseph • a year agoI will share my experience , I started off my career teaching Programming which included database programming (Oracle-pl/sql, SQL Server-transact sql) which gave good insights into database internals which landed me into DBA world for last 10 years . During these 10 years where i have worked in technology companies regarded as top-notch , I have seen very smart Developers writing excellent application codes but missing out on writing optimized piece to interact with the database. Hence, I think each Job has a scale and professionals of any group can not do what the top professionals of other group can do. I have seen Developers with fairly good database internals knowledge and I have dbas writing code for their automation which can compares well with features of some commercial database products like TOAD. So , generalization like this does not hold.ceposta • a year agoBTW.. "efficiency" is not the goal... "DG • a year agoDevOps and the Myth of Efficiency, Part I
The idea that there is a hierachy of usefulness is bunk. Most developers are horrible at operations because they dislike it. Most sysadmins and DBAs are horrible at coding because they dislike it. People gravitate to what interests them and a disinterested person does a much poorer job than an interested one. DevOps aims to combine roles by removing barriers, but there are costs to quality that no one likes to talk about. Using your hierarchy example most doctors could obtain their RN but they would not make good nurses.Lana Boltneva • 2 years agoSo true! I offer you to check this 6 best practices in DevOps too http://intersog.com/blog/ag...Jonathan McAllister • 2 years agoThis is an excellent article on the general concepts of DevOps and the DevOps movement. It helps to identify the cultural shifts required to facilitate proper DevOps implementations. I also write about DevOps.. I authored a book on implementing CI, CD and DevOps related functions within an organization and it was recently published. The book is aptly titled Mastering Jenkins ( http://www.masteringjenkins... ) and aims to codify not only the architectural implementations and requirements of DevOps but the cultural shift needed to propery advocate for the proper adoption of DevOps practices. Let me know what you think.Chris Kavanagh • 2 years agoI agree. Although I'm not in the business (yet), I will be soon. What I've noticed just playing around with Vagrant and Chef, Puppet, Ansible is the great amount of time to try and master just one of these provisioners. I can't imagine being responsible for all these roles you spoke of in the article. How can one possibly master all of them, and be good at any of them?Sarika Mehta • 2 years agohmmm.... users & business see as one application.... for them how it was developed, deployed does not matter.... IT is an enabler by definition... so DevOps is mostly about that... giving one view to the customer; quick changes, stable changes, stable application....Hanut Singh • 2 years agoFrankly, DevOps is not about developers or testers... it is about the right architecture, right framework... developers/testers anyways do what is there in the script... DevOps is just a new scripts to them.
For right DevOps, you need right framework. architecture for the whole of the program; you need architecture which is built end to end and not in silos...
Quite the interesting read. Having worked as a "Full Stack" Developer , I totally agree with you. Well done sir. My hat is tipped.Masood • 2 years agoSoftware Developer write code that business/customer useDaniel • 2 years ago
Test Developer write test code to test SUT
Release Developer write code to automate release process
Infrastructure developer write code to create infrastructure automatically.
Performance Developer writes code to performance test the SUT
Security Developer writes code to scan the SUT for security
Database Developer write code for DBSo which developer are you thinking DevOps going to kill?
Today's TDD world, a developer (it could be anyone above) needs to get out of their comfort zone to makes sure they write a testable, releasable, deployable, performable, security complaint and maintainable code.
DevOps brings all this roles together to collaborate and deliver.
You deserve an award.....Mash -> Dick • 2 years agoWhy wouldn't they be? What are the basic responsibilities that make for a passable DBA and which of those responsibilities cannot be done by a good developer? Say a good developer has just average experience writing stored procs, analyzing query performance, creating (or choosing not to create, for performance reasons) indexes, constraints and triggers, configuring database access rights, setting up regular backups, regular maintenance (ex. rebuilding indexes to avoid fragmentation)... just to name a few.SuperQ Mash • a year agoI'm sure there's several responsibilities that DBA's have that developers would have very little to no experience in, but we're talking about making for a passable DBA. Developers may not be as good at the job as someone who specializes in it for a living, but the author's wording seems to have been chosen very carefully.
Yup, I see lots of people trying to defend the DBA as a thing, just like people keep trying to defend the traditional sysadmin as a thing. I started my career as a sysadmin in the 90s, but times have changed and I don't call myself a sysadmin anymore, because that's not what I do.
Now I'm a Systems Engineer/SRE. My mode of working isn't slamming software together, but engineering automation to do it for me.
But I also do QA, Data storage performance analysis, networking, and [have a] deep knowledge of the applications I support.
|
|
|
May 15, 2017 | www.upguard.com
DevOps and I sort of have a love/hate relationship. DevOps is near and dear to our heart here at UpGuard and there are plenty of things that I love about it . Love it or hate it, there is little doubt that it is here to stay. I've enjoyed a great deal of success thanks to agile software development and DevOps methods, but here are 10 things I hate about DevOps!#1 Everyone thinks it's about Automation.
#2 "True" DevOps apparently have no processes - because DevOps takes care of that.
#3 The Emergence of the "DevOps' DevOp", a pseudo intellectual loudly spewing theories about distantly unrelated fields that are entirely irrelevant and are designed to make them feel more intelligent and myself more inadequate:
"The Copenhagen interpretation certainly applies to DevOps"
"I'm modeling the relationship between Dev and Ops using quantum entanglement, with a focus on relative quantum superposition - it's the only way to look at it. Why aren't you?"
#4 Enterprise Architects. They used to talk about the "Enterprise Continuum". Now they talk about "The Delivery Continuum" or the "DevOps Continuum". How about talking about the business guys?
#5 Heroes abound with tragic statements like "It took 3 days to automate everything.. it's great now!" - Clearly these people have never worked in a serious enterprise.
#6 No-one talks about Automation failure...it's everywhere. i.e Listen for the words "Pockets of Automation". Adoption of technology, education and adaptation of process is rarely mentioned (or measured).
#7 People constantly pointing to Etsy, Facebook & Netflix as DevOps. Let's promote the stories of companies that better represent the market at large.
#8 Tech hipsters discounting, or underestimating, Windows sysadmins. There are a lot of them and they better represent the Enterprise than many of the higher profile blowhards.
#9 The same hipsters saying their threads have filled up with DevOps tweets where there were none before.
#10 I've never heard of a Project Manager taking on DevOps. I intend on finding one.
What do you think - did I miss anything? Rants encouraged ;-) Please add your comments.
|
|
|
May 15, 2017 | testingthemind.wordpress.com
DevOps. The latest software development fad. Now you can be Agile, use Continuous Delivery, and believe in DevOps.Continuous Delivery (CD), the act of small, frequent, releases was defined in detail by Jez Humble and Dave Farley in their book – Continuous Delivery: Reliable Software Releases Through Build, Test, and Deployment Automation. The approach makes a lot of sense and encourages a number of healthy behaviors in a team. For example, frequent releases more or less have to be small. Small releases are easier to understand, which in turn increases our chances of building good features, but also our chances of testing for the right risks. If you do run into problems during testing then it's pretty easy to work out the change that caused them, reducing the time to debug and fix issues.
Unfortunately, along with all the good parts of CD we have a slight problem. The book focused on the areas which were considered to be the most broken, and unfortunately that led to the original CD description implying "Done" meant the code was shipped to production. As anyone who has ever worked on software will know, running code in production also requires a fair bit of work.
So, teams started adopting CD but no one was talking about how the Ops team fitted into the release cycle. Everything from knowing when production systems were in trouble, to reliable release systems was just assumed to be fully functional, and unnecessary for explanation.
To try to plug the gap DevOps rose up.
Now, just to make things even more confusing. Dave Farley later said that not talking about Ops was an omission and CD does include the entire development and release cycle, including running in production. So DevOps and CD have some overlap there.
DevOps does take a slightly different angle on the approach than CD. The emphasis for DevOps is on the collaboration rather than the process. Silos should be actively broken down to help developers understand systems well enough to be able to write good, robust and scalable code.
So far so good.
The problem is we now have teams saying they're doing DevOps. By that they mean is they make small, frequent, releases to production AND the developers are working closely with the Ops team to get things out to production and to keep them running.
Sounds good. So what's the problem?
Well, the problem is the name. We now have a term "DevOps" to describe the entire build, test, release approach. The problem is when you call something DevOps anyone who doesn't identify themselves as a dev or as Ops automatically assumes they're not part of the process.
Seriously, go and ask your designers what they think of DevOps. Or how about your testers. Or Product Managers. Or Customer Support.
And that's a problem.
We've managed to take something that is completely dependant on collaboration, and trust, and name it in a way that excludes a significant number of people. All of the name suggestions that arise when you mention this are just ridiculous. DevTestOps? BusinessDevTestOps? DesignDevOps? Aside from just being stupid names these continue to exclude anyone who doesn't have these words in their title.
So do I hate DevOps? Well no, not the practice. I think we should always be thinking about how things will actually work in production. We need an Ops team to help us do that so it makes total sense to have them involved in the process. Just take care with that name.
Is there a solution? Well, in my mindwe're still talking about collaboration above all else. Thinking about CD as "Delivery on demand" also makes more sense to me. We, the whole team, should be ready to deliver working software to the customer when they want it. By being aware of the confusion, and exclusion that some of these names create we can hopefully bring everyone into the project before it's too late.
|
|
|
Amazon.com
Mr. Ford Greene EsqOne of the most important books for the 21st century,
March 31, 2005
God. The God of Science, The God of Papal Infallibility, The God of National Security, The God of Family Values, The God of Buddhist Selflessness, The God of Unconditional Love. What are they good for? Absolutely nothing.
The Guru Papers elegantly identifies the masks that power uses to hide its abuse of others. Authoritarianism is the exercise of authority which, presuming an unquestioning obedience, can tolerate neither question nor challenge, meeting either with disregard or punishment. Assiduously distinguishing the everyday exercise of authority - living life and making choices amongst the propositions it presents - from the bullying domination intrinsic to the type of power unwilling to recognize an equal, the authors carefully dissect the threads which, woven together, comprise the cloth of abuse. Whence abusiveness flows, certain features are invariably present.
When a "leader" sets up an ideological standard of perfection or purity that no human being can attain, and our consequent failure of such attainment becomes the raison d'etre for a double standard of treatment whereby the leader gives orders and we obey them, we have lost our freedom, particularly if we believe it is for our own good.
Whenever one pole of a duality is identified as essential to good living and the other pole leads to evil, behind that mask an authoritarian moralist weaves his tale positing that which he believes is most important, that which he says is God. Gurus and religions, politicians and governments, educators and schools, parents and families, and lovers and spouses frequently equate evil with selfishness and goodness with selflessness and sacrifice. They say if I am sufficiently sincere and pure of heart, I will sacrifice what I want for what they tell me is best. Thus, I will be a better man.
There is little difference between the cult leader who demands allegiance to the unproven presumption of his godliness, and the lover who, crying "let me be myself," claims his imperfections should be accepted without limit in the name of unconditional love. When a moral demand for sacrifice is made in the name of something sacred, be it the Immaculate Conception or an Idealized Lover, one best be brave and ask one's questions. If such courage is met with punishment or disregard, one better run. If one does not, one's conduct will communicate that there is something wrong, and it's not with the other guy.
The essence of authoritarianism attacks the inner certainty of individuals by claiming that it knows a superior, more moral path. It not only condemns an individual's assertion of self as selfish and wrong, but also is unwilling to engage in dialogue which does not adopt an unquestioning regard for that which it deems sacred. If an individual adopts this moral dichotomy, he can only mistrust himself as inferior. This, Alstad/Kramer say, is the purpose of authoritarian control: to generate internal self-mistrust which makes the individual available to imposition of control by an external authority.
They correctly expose the deception that such externally imposed control is benevolent. According to Kramer/Alstad, authoritarian persons are never benevolent because such persons use others for their own selfish purposes while lying about it, saying they are not, if they are saying anything at all. "Do as I say, not as I do; and if you dare question what I do, you are questioning what all good people know is beyond reproach. You, too, would have respect if only you were a good person. Since you are not, you must do as I say. It is for your own good." Such is the circle of authoritarian ideology.
The language of authoritarianism is the language that Orwell named double-speak. There's no Orwellian double-speak in this book, just hard-hitting practical logic that rips the guts out of sacred cows that have fed too long in pastures provided by a naive and idealistic population. Such a populace, wanting to be good, denies that someone who directs their focus on great and beautiful-sounding ideals could be ripping them off, as was one of Hitler's more notable tricks.
Thus, the book shows how both the willingness to psychologically dominate, and to surrender to such, are embedded in one another. The dominating and the dominated persons both believe in an unattainable and essential purity which requires extreme sacrifices, both in its name, as well as for its attainment. One person makes the sacrifice, after the other has convinced him he must, erstwhile he would be morally condemned as selfish and self-centered for having disobeyed the other who claims to know best.
The Guru Papers recognizes that both self-centeredness and selflessness exist - you cannot purge the self of selfishness - and must work together in oneself in balance. It forcefully argues why intelligent negotiation is life-affirming whereas dumb submission invites death. It meticulously dissects the myriad protean tricks authoritarianism employs to maneuver its subjects into place and keep them there. Access to information and accountability for one's conduct are essential for the brave new world that might emerge if the reptant strain of authoritarianism in humankind does not destroy this world first in the name of knowing better.
The book says listen to yourself and if you are degraded or expelled for asking questions, recognize that the inadequacy lies with the authoritarian character, not with you. The Guru Papers makes the authoritarian predicates accountable and exposes them when they are not. It's about time!
Amazingly insightful, though miss-titled., October 10, 2012
By Mr. Serpent "Mr. Serpent" (Tennessee)This books is only ostensibly about "gurus". (Thankfully) and largely about authorities, the authoritorians who love them, and how power structures and hierarchies necessitate an authoritarian structure. Thus authority isn't necessarily bad or stifling, but as it's a conduit of power, it's a lightning rod for abuse and manipulation.
This book explores a myriad of relationships, the hierarchies they involve, and the nature of surrender to authority and how love is often confused with submission. The book isn't "about" cults, religion, family relationships and rolls, etc, as it involves all of these and much, much more. People who would tell you that it's essentially Krishnamurti is like saying the bible is largely about Job. This nearly 400 page tome is not Krishnamurti rehashed.
Hell, one can point to any one section and say that there is a resemblance to any given philosopher. For example, the section explaining how selfless love and unconditional love is an illusion that necessarily ignores ego, the reference in "I" love you, is Ayn Rand's Objectivism explained without the contentious takes on altruism and selfishness. ("It is what it is" rather than "A = A".) IMO it's an important work, and sadly, not well known.
|
|
|
Magnificent., June 3, 2007
By M. Harris (New Zealand) - See all my reviews
`On the psychology of military incompetence' is officially on the list of books that Army personnel aren't allowed to read, but since I was given this was a retired general, reading it seemed like the thing to do. I'm pleased I did.To be frank, non-military personnel might not admire its sheer brilliant powers of deductive observation. As soon as I had read it I started to panic as I saw the caricatures played out around me. I then started to spot them in myself, and began to panic harder. I suspect this book is designed to give oneself (if you happen to be in the military) a bit of a fright, and to encourage introspection.
Anyway, it's a brilliant book that's simply chock-full of theories, explanations and uncomfortable questions. I think the uncomfortable questions are the most valuable, but you have to read for yourself to discover if you think the same. And you should read it - it should be required reading for Officer Cadets right up to Generals, and civilians should read it as well - after all, you're the ones ultimately in charge of us gun-slinging types, yes?
A serious look at a deadly problem, March 19, 2007
By In the Middle of the Road (Connecticut)For most people, including most of today's amateur theorists on the events of the day, war is something akin to moving toy soldiers around. What they know of military matters is all too akin to cheering for a sports team. They want someone with a can do spirit and the willingness to charge into stiff resistance. Take that hill no matter what the cost. Fight to the death. A lot of horse manure.
War is a deadly business and there is probably no war in which incompetence was not afoot, whether in losing or in winning. Mix incompetence and a failure to understand the technology of war and you have WWI. The reality is that incompetence is as pervasive in the military as it is in the corporate world. And if we must fight wars, we should have a reasonable expectation tht the people who direct that effort have some idea of waht they are about. Dixon is concerned primarily with generalship.
I first read this when it was first published in the UK at least a couple of decades ago. It filled an important gap in the range of serious reading on both the military and organization behavior. As another reader notes, this is just organization behavior mil101.Most corporations are still organizing along military lines and that cuts through titles like team leader and associate. It is hard business to make it work right and too many times in the military, there is a failure of competence.
The fields o fhte world are littled with the remains of those who died through bad generals. Dixon reflects some of his own military experience in the British Army, including WWII, before he entered the Psychology field. There is a British emphasis, but the approach is generally and applies broadly to any military. And the examples he cites are among those that are studied deeply for implications. He covers the field from the intellectual capability of generals to a chapter that for the sake of review rules must be labeled as Bull droppings.How do we deal with incompetent leadership? That is one of the questions Dixon addresses. It probably should be extended to political leaders given their power over warmaking.
In our day, we are assaulted with people who accuse their opponents of micromanaging war in Iraq. A decade or two from now, it may be somewhere else. But what we began doing in Vietnam was executive branch micromanaging and that was greatly expanded during the Iraq fiasco to the point that many left senior ranks. We look closely at our generals, but can we afford to go to war without understanding the competence gap that we might have in political leadership..
Irreverent, superbly written, interdisciplinary, enlightenin, September 29, 1998
By A CustomerDixon is a former artillery officer, Sandhurst graduate, and self-described authoritarian personality, who left the Army and became a clinical psychologist. He uses both sets of experiences to analyze why officers in armies throughout history--mostly British, but the principles are generally applicable--have fallen into a stereotypical pattern of incompetence specific to senior military leaders. Much of the reason, he believes, derives from personality development, but the book is refreshingly devoid of psychobabble and is written in an astonishingly clear style. A real eye-opener, after which military history will not be quite the same to the reader again.
|
|
|
February 28, 2012 | Blind Bat News
"The direct causes of the nuclear accident were the unpreparedness of Tokyo Electric Power…and the government's lack of a sense of responsibility."-Koichi Kitazawa, lead investigator
A Japanese government sanctioned independent investigation has revealed gross incompetence in the wake of the March, 2011, nuclear disaster at Fukushima Daiichi. It also says that Tokyo Electric made the situation worse!
Six investigators interviewed more than 300 people, including Japanese and U.S. government officials. However, officials at Tokyo Electric refused to co-operate with the investigators! They have just published their findings, February 28, 2012.
The report calls government response "off the cuff", and "too late" (as I was posting last year)! The nuclear power plant operator, Tokyo Electric Power Company (TEPCo), was ill prepared for a nuclear disaster, despite decades of telling locals they were prepared (as I posted last year). The Japanese government, especially the Nuclear and Industrial Safety Agency, failed to ensure the proper training for nuclear disaster response (as I posted last year). The report also blames Japan's complicated system of delegating authority and responsibility. No one knew who was supposed to do what regarding the disaster; from top national government officials down to sub-contractors working for TEPCo (again, as I posted last year).Things were so bad that local governments have been taking the initiative to try and deal with things like relocating residents, and decontamination efforts, with little help from the national government (again, I posted).
Also, many of the discoveries of radiation contamination came as a result of individuals and private groups, who took it upon themselves to pay for testing things like dirt, water, and even food, like beef, sold in grocery stores (again, I). It was local governments who discovered farm crops to be contaminated (posted last year). The report also says that information coming from the private sector to government officials was insufficient to make proper decisions. TEPCo officials simply dragged their feet when it came to dealing with specific issues, like cooling systems being shut down, and vents not being opened. Not only did TEPCo drag their feet, but the investigators found that there was a back up cooling system that was functional, but TEPCo never used it!!! Although Japan's government has a crisis management policy, the investigators said it is totally useless!
|
|
|
ZDNet
For additional background, it's helpful to look at the 2006 National Audit Office report (emphasis added below):
The single payment scheme is not a large grant scheme compared to some government programmes, but the complexity of the EU Regulations, the complex way in which the Department planned to implement them in England, combined with the deadlines required to implement the scheme for 2005, made it a high risk project. By choosing to integrate the scheme into a wider business change programme, the Agency added to its already considerable challenges.
Many of the Agency's difficulties arose, however, from:
- underestimating the scale of the work needed to implement the scheme;
- over optimistic progress reporting; and
- governance structures which, in practice, proved overly complex, and the absence of clear metrics, arising from the lack of appropriate management information that would have allowed the oversight boards to measure progress objectively.
By the end of March 2006 implementation of the single payment scheme had cost £46.5 million more than the Agency had anticipated in its November 2003 business case. The implementation of the single payment scheme and the wider business change programme had cost £258.3 million, will not achieve the level of savings forecast, and there is risk of substantial costs for disallowance by the European Commission. The farming industry has also incurred additional costs, 20 per cent of farmers have experienced stress and anxiety as a result, and five per cent of respondents to our survey said they have considered leaving farming.
MANAGEMENT RESPONSIBILITY
The level of RPA mismanagement can hardly be over-estimated. As a small example, representing a broader pattern, see this House of Commons testimony (section EV8), by Johnston McNeill, former RPA boss, during an inquiry into the SPS debacle (emphasis added below):
Had we known that there was going to be that [level of claimant and land registration] volume, we could have looked at the volumes that the system could handle; whereas we could only look at the normal requirements. When we specified this system in 20034, when we were talking to Accenture, we had had a lengthy contract procurement and specification. We were specifying without any understanding of SPS requirements. We were specifying on our normal business requirements.
Although government incompetence has played a role, Accenture's involvement in this mess should not be ignored. Commenting on Accenture, a House of Commons investigating committee stated on page 5 (emphasis added below):
Accenture witnesses appeared to have been well schooled in not venturing comment on matters which they deemed were beyond their contractual observations. This attitude denied the Committee an important perspective on the way the SPS project was being run from the standpoint of a company at the heart of the venture. We regard this as an unacceptable attitude from a company of international repute and which may still aspire to work with UK government in other areas.
In evidence submitted to the House of Commons, Accenture denied responsibility for the problems, saying that (emphasis added below):
As has been widely acknowledged by numerous commentators and experts, significant IT enabled business change programmes can be difficult to manage. There have been many examples of problem projects in the public and private sectors in recent years with difficulties attributed to poorly defined requirements, changing business needs and lack of business involvement and preparedness that can lead to delivery difficulties.
NAO RECOMMENDATIONS
To address the issues, the National Audit Office offers these suggestions:
We recommend that the Agency:
- recovers high value overpayments to farmers (such as those over £25,000) as soon as practicable;
- brings its key offline databases into the single payment scheme IT system to make its forecasts more accurate and reliable;
- in the event that the European Union makes policy changes to the scheme, explores whether its existing IT systems would be able to accommodate such changes without the need for major redesign of the application. If the system is unlikely to be able to accommodate such changes, the Agency should notify its Management Board and the Department of the risks accordingly and update farmers once a revised timetable can be defined;
- draws on the good practices we identified from the IT systems supporting the German model of the single payment scheme on how to keep claimants informed about the progress of their claims, and the online processes already available to German farmers to transfer entitlements; and
- learns lessons from implementation of this IT system, to take account of best practice. In particular, the Agency should:
- use appropriate off the shelf rather than bespoke software whenever practicable, after considering business needs and scheme complexity, because bespoke software is costly to develop, needs to be thoroughly tested, and takes more time to implement;
- avoid offline systems, on which the main IT system depends;
- align the system to business needs, rather than the business to the system needs, applying caution to any significant movement away from tried and trusted business methods to accommodate the IT system; and
- ensure the system specifications retain a realistic level of flexibility to cope with future changes.
MY ANALYSIS
The National Audit Office recommendations listed above illustrate the extent to which basic IT best practices were not followed. Consider this as well:
- RPA developed custom software, rather than use off-the-shelf products. What was Accenture's role in this decision? It's precisely the kind of issue I addressed in a blog post called Consulting's dirty little secret, which explained how consulting companies can gain financial benefit when a project becomes larger and more complex than expected.
- RPA created databases in which data was stored in computers disconnected from the main system, despite the fact the main system depended on that data to function properly. Such issues force questions around who designed this system, from both technical and business perspectives, and how experienced these folks actually were.
- In general, the entire situation represents poor planning and project management taken to new heights of incompetence. Despite complexities in aligning UK practices with EU policies, both RPA and Accenture designed and executed a system based on poor practices, lack of experience, and world-class levels of bad planning.
IMPACT ON VICTIMS
This situation is different from many government IT failures, where money is wasted but innocent victims don't suffer personal injury. In this case, delayed and incorrect payments have directly affected farmers depending on subsidies to maintain their operations. In the words of Roger Williams, Liberal Democrat from Wales:
Farmers have found it difficult to accommodate problems with cash flow. Mention has been made of paying bills, but at the end of this week interest payments will be due on most accounts. That money will be taken out of the farmers' accounts. They will not have to make a conscious decision about it; the money will be removed from their accounts. That may take them above the level that they have agreed with their banks, and they will suffer the financial consequences-not just additional interest, but the other costs involved.
The BBC further reports on the damage caused to farmers:
Farmers in the East are being forced to the brink of bankruptcy by the Government's failure to pay their subsidies.
Many are struggling to survive while awaiting money from the Single Payment Scheme (SPS).
Johnston McNeill, former head of the RPA, eventually apologized for his agency's role in the disastrous situation:
"I deeply regret that we in the RPA and I as chief executive were not able to make payments to farmers in the targeted timetable". He said he was "saddened by the consequences".
Unfortunately, apologies coming from a man who earned £250,000 per year (about US$500,000), while inflicting such damage on his constituency, leave only a bereft and hollow sound.
|
|
|
May 4, 1997 | www.pluslicens.se
DILBERT MEANS BUSINESS. The (anti-)hero of one of the most successful comic strips of our time is an icon for office workers everywhere - the only character property that speaks to business through multiple media outlets including the daily comic-strip, an award-winning web site and a best-selling publishing program.
Anybody who works in an office or deals with bureaucracy relates to Dilbert's plight. Created by Scott Adams, Dilbert addresses issues ranging from office-envy/challenges to new technology - and the mayhem they produce. Dilbert features a rich cast of characters, including his sidekick Dogbert, his inept Boss, and his co-workers Wally and Alice. Primary target group for the property is adults 18-49 years old - affluent, educated and technology savvy.
The Dilbert daily comic strip appears in 2.000 newspapers in 65 countries worldwide in 25 different languages. More than 20 million Dilbert books and calendars have been sold in North America alone; several titles cumulatively spending over one year on The New York Times Best Seller List. The Dilbert Principle is categorically the best selling business book of all time.Dilbert was also the first syndicated comic strip character to officially go online, and the strip was the first to contain its creator's e-mail address. The award-winning web site The Dilbert Zone attracts millions of visitors each month. A Dilbert television series premiered in 1999, with Scott Adams and Larry Charles (Mad About You, Seinfeld) as executive producers.
Working as a computer engineer, Scott Adams started drawing Dilbert doodles to "enliven boring staff meetings". The character soon became so popular that other people at the company started using the character in their presentations. A "name-the-nerd" contest soon followed, and Dilbert was the obvious winner. After a few years, a contract was made with United Media, and Dilbert - "a composite of my co-workers during the years", Adams says - went from doodles to dailies.
Since then, Scott Adams has been awarded several prestigious prizes, including the National Cartoonist Society's Reuben Award for Outstanding Cartoonist of the Year and Best Newspaper Comic Strip (1997); Prix d'Excellence for Dogbert's Top Secret Management Handbook from the Maxim Business Club, Paris (1998), and the prize for Best International Comic Strip at the International Comic-Salon, Erlangen, Germany (1998).
Says Emmy Award winning Larry Charles, writer/producer of the Dilbert TV series: "Dilbert is a big Kafkaesque story of a little, logical man in a big, illogical world". In an environment where all bosses and many co-workers are heartless and stupid parasites, Dilbert stands out as the engineer with an active imagination and a His true love? Technology. Dilbert loves technology for the sake of technology; In fact, he loves technology more than people – he'd rather surf the Internet than Waikiki.
Dilbert's dog Dogbert is no man's best friend. His not-so secret ambition is to conquer the world and enslave all humans - whom he feels have been placed on this earth to amuse him. Dig deep enough below his fur, and you'll find a cynical, arrogant conniving little mutt with his paw on the pulse of the absurdity of corporate culture.
|
|
|
Years ago in Cleveland I saw the musical "How To Succeed in Business Without Really Trying," mail clerk J. Pierpont Finch's hilarious romp up the corporate ladder. I remember using that experience as a take-off point for a sermon on business ethics - with the president and vice-president of the Cleveland Chamber of Commerce in the congregation. I was young and foolhardy then. Now I am old and foolhardy -- as once again I attempt to enter a world in which I have had little experience, but about which I have many opinions.
Cartoonist Scott Adams in his strip Dilbert has updated "how to succeed" and created a primer on how not to succeed in business and in life. The Dilbert Principle is that "the most ineffective people are moved to the place where they can do the least amount of damage: management."
In Gilbert on Dilbert I suggest instead the Gilbert Principle - that our most important real life task is management - the management of meaning in our lives.
I am convinced that good cartoonists, as few others, have their pulse on the Zeitgeist - the spirit of the times.
Scott Adams' cartoon critique of management has become the talk of the town. Dilbert's boss comes in for most abuse. For example, Adams parodies a management buzz word, reengineering, about which the boss says, "Everybody's doing it. We'd better jump under the bandwagon before the train leaves the station." Mixed metaphors are always dangerous.
Have you ever written a mission statement? Been there, done that. In another strip he satirizes the omnipresent mission statement, which he defines as "a long awkward sentence that demonstrates management's inability to think clearly."
The Boss says, "I took a crack at writing a 'mission statement' for our group.
'We enhance stockholder value through strategic business initiatives by empowered employees working new team paradigms.'"
Dilbert: "Do you ever just marvel at the fact we get paid to do this?"
The Boss: "Did anybody bring donuts?"
One of Adams' E-mail correspondents demonstrated the observation that Dilbert is more documentary than satire. "My boss actually said to me 'Let's bubble back up to the surface and smell the numbers.' I had no idea what it meant." As Adams says, "No matter how absurd I try to make the comic strip, I can't stay ahead of what people are experiencing in the workplace."
Though he was fired from his job in corporate America, Adams personally thinks that corporate downsizing often does make the workplace more efficient - fewer workers means less time to waste on idiotic pursuits like vision statements, meetings and reorganizations - he nonetheless makes that phenomenon the target of many of his barbs.
One strip begins with a boss announcing he will be using humor to ease tensions caused by trimming the work force.
'I've decided to use humor in the workplace. Experts say humor eases tension which is important in times when the workforce is being trimmed. "Knock, knock," says the boss.
"Who's there?" asks a hapless worker.
"Not you anymore," responds the grinning boss.
But Adams' cynicism about human nature does not stop with the boss. Co-workers also seem to be caught up in this absurd work culture. A group of workers gather around another's desk.
One says,
"We're sorry to hear you're getting laid off, Bruce. We calculated that if ten of your friends here took ten percent pay cuts, then the company can keep you."
Bruce: "Gosh! You'd do that for me?"
"No, we're here to look at your office furniture."
What is the gospel according to Dilbert? There are times when Scott Adams becomes a prophet, skewering perceived injustice, mocking dehumanizing practices that are too close to reality for comfort. He writes about a familiar corporate mantra: "'Employees are our most valuable asset.' On the surface this statement seems to be at odds with the fact that companies are treating their "most valuable assets" the same way a leaf blower treats leaves. How can this apparent contradiction be explained?"
He treats this issue in a cartoon in which the boss admits he was mistaken that "employees are our most valuable asset." Actually, he explains, "they're ninth." "Eighth place?" someone asks. "Carbon paper," says the boss.
After a particular "downsizing" there were unused work cubicles which the company decided to hire Dogbert Construction to retrofit them and rent them out to the state as a prison.
Dilbert: "I don't think it's fair to put convicts in our spare cubicles."
Dogbert: "Don't be such a bigot. These people have made one little mistake. Otherwise, they're just like employees."
Dilbert: "I think there are a few differences."
Dogbert: "Yeah, their health care is better."
How are we to assess Adams? Is he prophet or embittered employee getting back at his former bosses? I think Adams is no prophet but a social critic. He has a totally cynical view of human nature. His characters are not suffering from paranoia, people are out to get them -- from the boss to the stockholders to their fellow-workers. These characters are totally self-interested, with no discernible trace of altruism.
One reporter asked him, "Are you as cynical as you seem?" "Yes. I don't think what I'm doing is based on rage, but I'm terribly amused by the absurd.
The absurdity stands out more in a business setting because there's an expectation that people will act rationally. But people aren't rational."
Whether or not Dilbert is true to life, it is close enough that millions of people read it daily. In one survey of workers indicate that 87% say their workplace is a "pleasant environment," but Adams responds, "If you're in an absurd situation and you're not changing it, then you define it as being OK."
And it is true that more than 70% of workers report stress on the job, suggesting that there may well be a kind of suppressed rage in America's workplaces. Dilbert's problem is that he is totally dehumanized by his work environment. Certainly my conversations with many of you indicate that working isn't what it used to be - that work has become an ordeal - that it is robbing people not only of their time, but also of their human dignity.
For such people Dilbert is a pleasant catharsis. But Adams has been roundly criticized by more radical cartoonists as being "on the side of the ruling class," betraying "millions of insecure and beleaguered office workers" who consider him their champion. It is "not very radical commentary to say 'Boy, aren't bosses dumb.' There's no analysis, even in a goofy way, of why bosses act the way they do.
It's 'Boy is my boss dumb,' but not 'Boy, is this huge company stupid for doing this merger and laying off half its employees and devastating the local economy and shipping the jobs to Mexico or Indonesia.' Criticizing stupid bosses without putting them in context is like complaining because it gets dark at night without understanding that the earth revolves around the sun. It's a really limited view. It doesn't go anywhere. It's just a safety valve."
I confess I am somewhat suspicious of Adams' credentials as the prophet of the workplace. I withhold that status from anyone who in critiquing the corporation has become one, anyone who proudly admits he has always wanted "to make as much money as I could....If you can write on it, if it will hold a label, it's a prime target for licensing. You can't get to overexposure without getting to filthy rich first."
What is disturbing in Dilbert is the relative equanimity with which the office workers accept their plight. Passivity is their chief character trait. They seem to be automatons who do not so much live in, as simply respond to, their environment.
One wonders if painting this humorous picture of their ineptitude, their shallowness of life, their willingness to go along with absurdity, is a step on the way to ending the insanity. Or does it simply help them deal with it by laughing at it?
After all, CEO's and management consultants post the cartoons on their office bulletin boards - how penetrating can this critique be if the targets simply divert the satirical arrows with a laugh? Adams says they always think he's pointing the finger at somebody else. Does Dilbert merely co-opt workers who ought to be struggling to humanize their work environment instead of making the best of their dehumanization?
Adams seems to be ambivalent on his role. On the one hand he defends himself by saying "anything which can be mocked will not last...." but who is to say it won't last? And, on the other, he says, "My goal is not to change the world. My goal is to make a few bucks and hope you laugh in the process." He is hoisted on the petard of his own cynicism.
What is going to stop our thoughtless, dangerous, headlong dash into the 21st century in which work once more becomes drudgery - albeit a high tech one - a drudgery which increasingly consumes our lives.
In the mid-1990's the Apple Macintosh development team wore T shirts proclaiming "90 hours a week and loving it!" Is that the kind of brave new world we want? We seem caught up in a momentum about which many of us complain, but about which we seem to be able to do little or nothing. We accept the new oppression with nary a critical word - so fearful are we for our jobs.
Now the cartoonist, of course, is not really supposed to be a social revolutionary, but is Adams helping sustain a workplace environment which so often saps the human spirit by merely encouraging us to laugh at it?
Or is he launching a long-overdue conversation about the place of work in human life? Is Adams helping or hindering our headlong dash into the brave new world where we live faster and faster, with more and more, for less and less meaning?
In 1987 social critic Jeremy Rifkin uttered these prophetic words:
"We have quickened the pace of life only to become less patient. We have become more organized but less spontaneous, less joyful. We are better prepared to act on the future but less able to enjoy the present and reflect on the past."
Is that to be the culmination of our evolution as spiritual creatures? That our work will suck the life force from us, as it did for Scott Adams. Are you happy in your work? Does it add meaning to your life? If so, good. If not, what are you, what can you, do about it?
The Dilbert solution of supine acquiescence in absurdity is a spiritually fatal position. It is a study in how not to succeed in the business of life. Adams offers us no hope. The Gilbert principle is that we need to manage the meaning of our lives in the workplace - for it is there, increasingly, that humanity's fate is being decided. It would not be not enough for me to endure the absurdity of the workplace, to find a humorous "haven in a heartless world." It is our task to make that world less heartless.
Sources:
Business Week, 5/27/96, 46.
U.S. News and World Report, 4/22/96, 77.
Fortune, 5/13/96, pp. 99-110.
Newsweek, 8/12/96, pp. 52-57.
Windows, 5/95, reprinted in Utne Reader, 7-8/95, 88-9.
Salon - on line
USA Weekend, 7/26-28/96, 10, and 3/21-23/97, 18.
Rochester Democrat & Chronicle, 2/23/97, 1E.
|
|
|
TechRepublic
Last week, I asked for your thoughts about the usefulness of regularly scheduled One-on-One meetings with your subordinates, for an upcoming column I'm writing.
I got some great emails from you, but I thought this response from Margaret Thorpe best captured both the upside and downside of such meetings:
Not long ago I worked with a manager who knew the buzzwords but not the substance of the job. Yes, he scheduled one on ones but the team soon came to realize that he was simply going through the motions and over time he would show up for about 10% of these meetings. When he did appear he had no agenda or interest in the outcome. Finally he simply added these meetings to his schedule but neglected to invite his team -- the schedule was truly "for show" and satisfied his superior. What a waste!
Too many IT managers haven't learned to manage people and use low-tech people skills. Sometimes you'll see managers spending this sort of time with only a favored employee or two - to the envy and distrust of the rest of the team. It's OK to have favorites, but don't neglect the others when you have one on ones.
There are immense benefits to conducting one on ones. Simply getting to know and spending time with an employee is one of the best predictors of good management-employee relations. Understanding how an employee works and what the employee can do can help a manager deploy work more effectively and use resources where they can best operate. When a manager pays attention to his team using one on ones, she can develop an overall view of the projects and work and more effectively plan and schedule his teams work and run interference as needed.
|
|
|
Institutional incompetence defends itself by portraying all observation of its effects as "Conspiracy Theories". This defense mechanism is now, itself, an institution. Moreover it is an institution that is extraordinarily effective at protecting incompetence in all institutions (including itself).
Part of the problem is that almost all institutional incompetence derives from faulty incentive structures, so it is easy to impute to the critic the claim that such incompetence is not incompetence at all but, rather, is self-interest.
The critic is hard-pressed to deny this (except insofar as such self-interest is unenlightened hence incompetent in that meta-sense) and is thence imputed to "theorize" a "conspiracy" of self-interested individuals as the basis for the maintenance of the institutionalized incompetence. Again, the critic may not have put forth nor even have thought of such a theory but he is hard-pressed to disprove that a "conspiracy" -- in some sense -- is at work so he cannot very well vigorously deny such a theory.
This vulnerability of the critic is then viciously attacked. This all goes on within a subtext of the conversation so it is a rare critic that recognizes how the burden of proof has been shifted from the institutionally incompetent needing to prove that the critic has theorized a "conspiracy" (which, of course, would require defining "conspiracy") to the critic needing to prove that such a "conspiracy" (the definition of which is, after all, in the mind of the institutionally incompetent) is clearly out of the question despite the vagueness of the term multiplied by the lack of information with which to support or deny even a clear definition.
Google matched content |
Corporate Governance and Managerial Incompetence: Lessons from Kmart Apr 30, 1996
Ineptitude Definition of Ineptitude by Merriam-Webster
Rank Incompetence The American Conservative
Society
Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers : Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism : The Iron Law of Oligarchy : Libertarian Philosophy
Quotes
War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda : SE quotes : Language Design and Programming Quotes : Random IT-related quotes : Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce : Bernard Shaw : Mark Twain Quotes
Bulletin:
Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 : Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law
History:
Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds : Larry Wall : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS : Programming Languages History : PL/1 : Simula 67 : C : History of GCC development : Scripting Languages : Perl history : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history
Classic books:
The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month : How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite
Most popular humor pages:
Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor
The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D
Copyright © 1996-2021 by Softpanorama Society. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.
FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.
This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...
|
|
You can use PayPal to to buy a cup of coffee for authors of this site |
Disclaimer:
The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.
Last modified: April, 23, 2019
