The bulging Dell XPS 13 keyboard and the solution

In 2018, tired of the lack of horsepower of my existing publishing company laptop, in use with White Cat Publishing, I went out and found a Dell XPS13 laptop on Ebay. I selected it because it was fairly powerful, and it could be used for video processing if we took it on vacation, and the keyboard had good reviews.

And when I first started using it, it ticked all of those boxes.

Fast forward to the beginning of this year, when I began to notice that the keyboard was bulging upwards on the left hand side. Most of the left hand side had a noticeable bulge in the D, C, E key area, extending down to the space bar. I had no idea why this was happening, but the laptop did seem to be hot on that side, so I concluded that it was due to internal overheating. I began to power the laptop when I was not actively using it.

The bulge in the keyboard slowly became worse, and started to affect the operation of the keyboard. The space key began malfunctioning, if I tried to use the left hand side of it, nothing happened. More annoyingly, shutting the laptop would engage CTRL Lock on the keyboard, and I could not get out of it using Windows 10 (this is an issue with Windows 10, but the coincidence of the issues was making me…not a happy bunny). The touch pad was also starting to become glitchy.

Now…I can think faster than I type. My typing speed is what limits my ability to rapidly get stuff down, so anything that slows down typing for me, is beyond annoying. Sadly, my better half can attest to the gradual disappearance of my patience with the laptop keyboard.

Also…the laptop would shut down without warning, thinking that the battery was low (no it was not, at least according to the on-screen power management information).

I had resigned myself to the reality that I was going to need to invest in a new laptop. Mary, probably fed up with my cursing swearing and chucking of objects, was researching new laptops online and through Costco.

My sanity was degrading. Something had to be done.

So…I began to look online using “Dell XPS 13 warped keyboard”.


The random shutting down of the laptop and the keyboard warp were caused by the same underlying issue.

The modern laptop, with no disk drive, and a lot of pressure to reduce the thickness to not much more than that of a tablet, is designed with an ultra-thin Lithium battery pack, which occupies the entire space between the keyboard and the back panel. There is no space to speak of inside a modern laptop case.

The back panel is made of thin metal. The keyboard base is made of very thin plastic.

The battery pack was failed, and when Lithium packs fail, they overheat and expand. With nowhere to go against the case bottom, the battery was pushing up the keyboard, progressively warping it and degrading its functionality.

So…a search for a battery pack showed lots of them available. I ordered one from Amazon. My thinking was, if the keyboard was thin, it would resume its normal shape after a new battery pack was fitted. With a new battery pack costing $65, this was worth a try. If the keyboard refused to un-warp, a new keyboard could be installed. Beyond that, it would make more sense to spring for a new laptop.

The installation of the new battery pack was fairly easy. Just a case of removing 8 screws from the metal base, pulling the base off the laptop. There are videos like this one on YoutTube that walk through the rest of the process.

So, after pulling the old battery pack, this is what it looks like.

The top side (next to the keyboard):

The pack should be totally flat where the cells are located. As you can see, that’s…not even remotely close to flat. Bulging like a way overweight bar-room boozer.

The bottom side (next to the case):

This side is even worse, but there is some clearance inside the case, so it assumed the contour of the case bottom. I suspect that the pack expanded into that space, then as the expansion became worse, it pushed the keyboard up.

So…new pack installed, and now…a flat keyboard with all the keys working properly.

For somebody who needs a good fast keyboard this is….Nirvana.





A story from my first professional job search

In 1977 I decided to change careers, or more correctly I decided that after 18 months of working in a factory making screen printing inks, after trying and failing to land a job in Geology, it was time to swap a dead end job for a “proper job”, preferably one involving the continual deployment of intellect.
After consultations with a career counsellor, I applied for a job as a computer operator with a brewing company in London. I was advised that computing was “the next big thing”. Since I couldn’t even get in the door to get interviewed by any corporation looking to hire geologists, I decided that I had nothing to lose.
At an appointed time, I took part in a phone interview with a company recruiter.

I apparently passed the interview, because I was then summoned to an interview in London with the data centre manager for the brewing company.
Respendent in a newly-purchased suit that did not really fit me properly (having high shoulder points, a short torso and long legs, one of my mistakes that Iwould rectify later in his life as I actually learned something about clothing deportment), bright-eyed and bushy-tailed, I set off for London to attend the interview.
Underestimating journey times, he arrived 20 minutes late. Black mark. 
The interview with the data centre manager was going well, or so I thought. Then the interviewer set a trap.
“Do you consider yourself to be well-organized?” he asked. 
“Yes”, I replied blithely.
“Then why were you 20 minutes late for this interview?” He ostentatiously settled back in his seat and stared across the table at me.
I considered my options. One of the options was to bullshit, but my primitive DNA did not want to embrace it.
“I underestimated the journey time to this location” I said. “I learned something”.
The data centre manager smiled slightly. He nodded.

Then the line of questioning went in a different direction.
The following week, I received a phone call from the recruiter.
“The company does not want to hire you as a computer operator” he began. 
Uh oh, I thought, the lateness to the interview has doomed me.
“They do however want to hire you as a computer programmer”. 

The job was in a different location, and at a higher salary.
In due course, I arrived in London and took up the job as a programmer. A few months later, I actually met the data centre manager who had interviewed me. In a hallway conversation with him, he told me that he did not hold the lateness against me, because I had not attempted to bullshit my way out of the predicament. (They had also decided that I would be a better fit for the programmer job).

Life Lessons
1. Never bullshit. It catches up with you…sooner (probably) or later
2. You may not get the job you originally applied for. You might get a different job instead. You might even get a better job. 


Two great confusions in IT delivery

In my lengthy time in IT solution delivery, I consistently see two great confusions that, on many delivery and support teams, impede, prevent and degrade delivery quality.

The two confusions are a result of the inability of many people to conceptualize and abstract solution spaces.

  1. Process vs. Procedures

I consistently get asked to review or revise process documentation. When I examine the documentation, it rapidly becomes apparent that the documentation spends almost all of its time defining HOW an activity is performed, not WHAT activity is performed. In addition, the documentation does not specify any other essential activity that I would expect to find in a process definition such as Pre and Post-conditions, Inputs and Outputs etc.

Normally, when I point out that the document is really a procedure document, I am greeted with one or a combination of 2 responses:

  • The document is a process document, and what am I talking about (Confusion of process with procedure)
  • Why write a process document anyway? People just need to be told what to do (I want to cut corners)
2. Requirements vs. Design

I am often given documents that purport to be Requirements Definition documents, only to rapidly find that the document contains references to UI design, report design, operational procedures etc.

None of those artifacts and content items are anything to do with Requirements. They are the implementation of the requirements. When I try to explain this, the most common response I get is “that is what the client wants”. It then becomes apparent that, in most cases, the delivery team are order takers for the client, so if the client says “I want you to create a document that supposedly covers everything we need to know”, they obediently create a jack-of-all-trades-master-of-none document that is not only difficult to read, but also fails to properly elicit Requirements, jumping straight into solution design.

So What Are the Causes?

In both of the above scenarios, there are two underlying drivers for the mindset that led to the creation of mutant many-headed documents that are not what they purport to be.

  1. Inability to conceptualize and abstract

This is a classic blind spot. Like critical thinking, abstraction and conceptualization are “soft” skills that are often overlooked, in the same way that people management skills are often overlooked when promoting technical contributors to leadership roles. They are not easy to teach, and then it takes time for people to develop and hone them. (DISCLOSURE – I learned on the job as i became a business analyst).

2. Impatience to get to “working code”

I once became involved in a rather spiky dispute with a Project Manager on a new development project. From the very beginning of the project, it was clear that the PM was not a fan of Analysis at all. He was constantly pushing me to end Analysis and move to Design. When I moved to Design, he was pushing me to move to coding. In the process he engaged in some rather juvenile sniping, including quips like “you clearly don’t want to actually do any work on this project”.

The real underlying issue, as I soon realized, was that he saw the only useful deliverable of the project as code that appears to work. Nothing else mattered a damn as far as he was concerned. I never determined whether this was a result of his client stakeholders having the view that code was all that matters, since he never let me spend enough time with the client to form a view. He was definitely a controller.

This viewpoint, I have realized, is very common in a lot of IT delivery contexts. “Screw Analysis and Design, let’s just code” or “they’re paying for code, not documents” are common attitudes, made worse by the move to Agile and DevOps, which appears to many IT teams to eliminate All The Upfront Shit that they hate. Like requirements elicitation, analysis and planning. Many coders hate anything that gets in the way of coding.

The mindset of “let’s just code” may make developers happy, but it ensures that the ceiling on delivery quality is limited, since failure to understand the scope and depth of solution domains is precisely the sort of failure that causes projects to go way beyond budget and timescale, as the terrible truth dawns “shit, this is much more complicated than we thought”.

So What Do We Do?

Training in abstraction and conceptualization is not common, especially in the business analysis domain, which is where Requirements elicitation resides in a lot of sequential development organizations. Business Analysts are often selected on the basis that they are solution SMEs, not necessarily based on actual analysis skills. Process vs. Procedure is a fundamental conceptual lens that ought to be taught also. However, it also falls into the same blind spot as Requirements vs. Design, for the same reasons.

Training in these skills forms part of a process-focussed delivery organization, which values WHAT is done as much as HOW it is done. This is not common, in an era where the first response to cost-cutting demands is often the axing of process and QA teams, on the grounds that the projects can do all of the work. This usually leads to a long slow deterioration in delivery quality, which then requires at least as much time to repair.

Get it right upfront, by valuing processes and the skill of conceptualization, and you will be rewarded in the medium-term. You will also be able to impress the client. Clients tend to respond to IT vendors who have clearly done their analysis homework, as long as it is well-presented.


The subtleties of a hostile work environment

There have been many books and articles published about toxic work environments. A lot of the discussion is around the tendency of corporations to tolerate bad behavior from employees who are (correctly or not) perceived as successful. Bob Sutton has attacked this tendency with his “No Asshole Rule” writings.
When one uses the phrase “toxic work environment”, the image portrayed is usually one of out-of-control dysfunctionality. There is a lot of writing about work environments being “dysfunctional”. However, that term by itself is imprecise, and absent any clarification, almost meaningless.
I prefer to adopt a more nuanced approach of dividing dysfunctional work environments into two main categories.

1. Toxic
2. Hostile

Toxic environments are those where activities are occurring that meet one or more of the following criteria:

– Illegal
– unethical
– Capricious wilful abuses of power (bullying, intimidation, denigration either publicly or privately)
– Sexual harrassment
– Discrimination based on protected classes (ethnicity/culture, sexual orientation, religion)

By the way, “unethical” need not necessarily involve an action that is prohibited by Ethics guidelines or other rule books. I tend towards the rule that if an action looks and/or sounds bad if you have to explain it later, it is probably (at the least) unethical.
The legally significant phrase “Hostile work environment” usually refers to environments that meet one or more of the criteria listed above. The activities listed above, in many jurisdictions, are legally actionable, and can result in punitive action by the courts against the corporation.
However, a work environment can still be toxic, for more subtle reasons which, while they do not meet the criteria for being legally actionable, still result in a poorly-functioning workplace.
Hostile Environments are environments where the culture and attitudes of the majority of leadership and team members are actively and consistently undermining the communicated aims and objectives of the organization, or change management efforts within the organization

– Overt sabotage (up to and including insubordination)
– Covert sabotage (lack of committment, enthusiasm, avoidance of activities that form part of a change project, instruction of teams to not collaborate)
– Lack of respect and attention directed towards leaders and team members in the organization perceived as agents of change (especially if those leaders or team members are new to the organization, or if they are from a different part of the organization)

Hostile environments are not generally described as such. Some people operating in those environments may recognize that the environment dysfunctionality is resulting in under-achievement. However, many people in the environment are in denial, since to them, the normal characteristics of the environments are features, not bugs.
A lot of hostile dysfunctionality is based on negative views and attitudes towards people or groups who are perceived as “Others”, or, as a memorable phrase once summed it up, “Not one of Us”. That may encompass one or more of the following:

– new employees and leaders
– groups that contain members who have poor social skills
– groups whose role is part of a “check and balance” process, such as quality assurance, auditing, financial management
– anybody from “head office”
– consultants and contract staff
– people perceived as agents of change

new employees and leaders
A common process with new employees and leaders is to require that they “prove themselves”. For leaders, that is usually spelled out by existing leadership if the new leader is from outside the organization.
There should be defined, agreed and measurable success criteria for all new employees. However, the impactful informal social criteria are never documented, even though these may comprise many of the organization’s expectations of the new employee.
There is a reason why they are never documented of course. Firstly, they are hopelessly subjective. Secondly, they provide a covert measurement mechanism, one which the incumbent group members control, which is un-moderated by leadership. “We don’t care what THEY think, this is what WE think” can become the prevailing ethos.
This implied measurement process can encompass anything from “does he laugh at our jokes”, through to the requirement that the new employee behave and operate exactly like other group members. (If the employee has been hired as a change agent, you can probably understand how stupidly unproductive that second requirement might be).
New leaders are often imposed on an organization to correct what leadership sees as a serious leadership or operational deficiency, so they immediately (to use an old Biblical saying) have the Mark Of Cain. what I have discovered is the most critical skill they can deploy is that of active listening. If a leader is seen to be actively trying to understand how the current organization functions, they will be much better regarded than if they are seen as not interested, and just there to immediately turn the whole place upside down. Leaders who consistently make uninformed decisions soon suffer a loss of credibility.
The “prove yourself” ethos is dangerous, since it amounts to the imposition of informal, undocumented and non-meeasurable social and behavioral expectations on the new employee. The new employee is expected to “fit in”, “understand how we work” etc. etc.
If the employee is seen to not be “one of us”, then there is a wide variety of tactics that the rest of the group can deploy to obstruct or impede the contributions and actions of that employee.
The actions are usually subtle. They include work-related actions such as not copying the person on emails or meeting invites, not attending meetings called by the person, not responding to requests for information or assistance, through to more overt social signalling actions such as not inviting the person to lunch, celebrations or other social events.
The inevitable conclusion, at least some of the time, is that several months down the line incumbent people and teams are whining that Joe or Mary “does not fit in”, or, in the classic Orwellian Doublespeak language that is prevalent, is “not a team player”.
This is where strong leadership needs to be able to politely but firmly challenge the conclusion, including asking whether the process being followed is even fair or equitable. Sometimes, in highly social environments, people may need to be reminded that the workplace is not an extension of the local bar or neighborhood association, and that feelings are not a substitute for facts.

groups with poor social skils
When I became embedded into software development in the early 1980s it became clear that a lot of software developers had poor social skills. They were introverts, who wanted to be left alone to code. They hated meetings, were uncomfortable dealing with customers, and sometimes showed all of the symptoms of social anxiety, even in 1:1 situations. Software development groups in many corporations were, for a while, stuffed full of those kinds of people.
The situation has changed over the last 20 years, as agile methods have converted previously isolated and siloed development teams into constant-interaction groups, where hiding in the corner behind multiple monitors is less of an option. However, a significant percentage of people in around IT are still poor in social situations, which makes them reluctant group members. Many highly creative people fall into this category, especially if they have brains that operate differently (such as people with Aspergers Syndrome, which can go undiagnosed for a long time).
Sensitive management is needed to avoid driving gifted people out of organizations. Note, however, that dickery and behaving like an asshole are not likely to be excused by rationalizations like “well, he is shy”.

“check and balance” groups
These groups are always likely to have assimilation and trust issues, since they often exist to ensure that members of an organization consistently perform activities that they don’t like doing. Classic examples are legal compliance, quality assurance and documentation, and, the bane of many IT delivery projects, the PMO.
Skilful, diplomatic leadership in these groups is vital to ensuring that the group is accepted, not just from a work management viewpoint, but also from a personal viewpoint. Bombastic, imperious and demanding leadership in these kinds of groups will tend to result in the group, its members and its work being avoided by the organization. After all, nobody wants to constantly be told “do this or I will report you”.

anybody from “head office”
Almost by default, anybody from a higher-level group in the organization, who shows up to work with team members, will be seen as one of the following:

– a spy
– an agent of (unwelcome) change

This instinctive emotional reaction can only be ameliorated by open, honest and truthful communication about why the person or group is there, and their role. The communication has to meet all of those criteria, and

    there must not be any divergence between rhetoric and reality

. If any divergence becomes apparent, the person or team will immediately be seen as an unwelcome outsider, and the organization will begin to organize to obstruct the perceived goals of the visitor(s).
For example, if a team from head office arrives to perform what is portrayed as a process audit, but it becomes clear that the team is actually identifying groups and individuals who can be dispensed with, that will most likely result in the organization rapidly withdrawing engagement and co-operation. Lower-level employees have a lot less tolerance for bullshit and duplicity than most corporate leaders. The reason why a lot of lower-level people stay at lower levels is often because they either found out (by hard experience) or decided that they were not going to be able to tolerate the levels of bullshit, mendacity and political manouvering that would be required for them to advance. That does not make them naive or stupid. Some of them are just as smart as senior leaders. They just have no tolerance for bullshit, and they have well developed bullshit detectors that can detect a rhetoric-reality gap a long way away.

consultants and contract staff
I have lost count of the number of times I have heard people say things like “doesn’t matter, he’s only a contractor”, usually when attempting to justify or rationalize a capricious or punitive action aimed at a contract or temporary resource.
I have worked in organizations that treated temporary workers and consultants as, quite literally, a lower form of life, putting them in small work areas with poor facilities, and denigrating or ignoring them.
Given that one of the best ways in which you can actually ensure that a person will be a good contributor to the organization is to hire them on a temporary contract, and then make them an employee, it should be obvious why this approach is counter-productive. In the UK, when I worked in IT, companies that treated contractors poorly had…wait for it…major problems not only attracting contract staff, but also tended to have poor quality employees.

agents of change
The idea that agents of change are bad actors is a pervasive one in organizations that are not prepared for or not committed to a change that is being implemented. The agents of change are seen as not having the interests of the organization at heart. This is particularly true if those change agents are consultants or third party organizations. Many people have learned over the years how to pretend to embrace change while actually doing nothing, “waiting out” the inevitable failure of the change management initiative and its replacement by a new initiative that is likely to also fail. Once several successive change management initiatives fail, the chances of any subsequent one failing are greatly increased.

All of the sub-optimal behaviors discussed above can be remediated by leadership. However, leaders need to be prepared and able to understand what is really happening on the ground in corporations, particularly when trying to change the overall culture of the organization. Flying visits are never a substitute for spending time observing behaviors. Facebooktwitterredditpinterestlinkedinmail

The convoluted history of Digital Rights Management

Digital Rights Management (DRM) was a concept that evolved in the mid to late 1980s as a means of securing artifact copyright in the digital era.
I was exposed to early attempts at DRM earlier than this, as PC software vendors struggled to prevent unlicensed copying of software programs. The attempts, involving the spending of increasingly larger amounts of money on increasingly complex copy-protection schemes, were largely unsuccessful. Nerds and hackers love nothing better than a large business stating confidently “our copy protection scheme is unbreakable”. That’s like waving a red flag in front of an angry bull, or red meat in front of a pride of lions. Once the hackers had done their jobs, the copy protection schemes were mostly circumvented, and the end of the attempts came when PC software prices fell to a point where the RoI for illegal copying became unfavorable.
This article explains the history of what is now known as DRM. It’s a long story. Facebooktwitterredditpinterestlinkedinmail

Logical Campaign Part 2- the company owner is running away

I previously posted Mike Hind’s investigation into the superficially plausible website Logical Campaign, masquerading as a Marketing and reputation management firm, but with a website comprising mostly stolen or plagiarized content and images. The site was also pumping out Brexit propaganda.
After Mike’s initial expose, the leading figures and supporters of Logical Campaign started going into hiding.
Now the UK company behind Logical Campaign is apparently being closed down in a hurry by the owner:

Clearly the rats are leaving the sinking ship. The true identity of the owner/founder of Logical Campaign remains unknown, but as Mike asks more questions, it becomes clear that his online profile is mostly weapons-grade fabrication. Facebooktwitterredditpinterestlinkedinmail

Innovation inhibitors in corporations – modern reality

I see “innovation campaigns” and change management initiatives all of the time in corporations. Most of them never achieve any positive results. In the worst case, failed change management initiatives increase cynicism and depress morale further.
Innovation and change, like morale, are things that all leaders in all corporations will agree they always need more of. However, innovation and change are very slippery items. Like the wind, you know they are there, but they can head in all directions, and are difficult to steer, and even more difficult to capture and grow.
Having watched the trends in IT solution delivery and service provisioning in corporations in the USA and Europe for over 30 years, I have come to some conclusions about why so many corporations are currently struggling with innovation and change initiatives.
Leaving aside the approaches to fostering innovation, which are often bizarre and superficial, there are several underlying current pervasive dynamics that have the power to totally derail all attempts at fostering innovation and implementing organizational and/or cultural change.

1. Psychological Safety
One of the best ways in which a corporation can ensure that innovation is suppressed is to make it clear that the reward for taking risks or attempting new approaches is to be penalized by Exile or by being made redundant. The organization shows little or no tolerance for failure.
This article explains the concept of psychological safety extremely well.
It is up to leaders to create a climate where taking risks is not immediately shut down, and failures of innovation are not immediately punished. Whenever I hear leaders commenting to the effect that “our culture is risk-averse”, I immediately begin to worry that they are stewards of a climate where nobody with any sense of self-preservation is likely to propose any sort of innovation or change.

2. The offshore delivery work fiction
Most IT delivery organizations have been relentlessly reducing staffing levels for decades, often sending work offshore, where it is often performed poorly, at which point the remaining onshore team members have to “paper over the cracks” in order to elevate quality levels to an acceptable level for the client or end-users. (By the way, this “acceptable” level is often way below the previous quality level that was provided to the client). The result is a corporate fiction that the work is being performed offshore. In reality it is being bodged offshore, and fixed up onshore by a small number of over-worked resources. Those resources are usually too busy to even think about visiting the restroom, never mind engaging in innovation.

3. Reduction in SME coverage and predominance of tacit knowledge
Over the last 15 years I have seen groups progressively slimmed down to the point where only one person is a SME for key areas of the solution. If that person is (say) killed in a road accident this upcoming weekend, the organization will be in a dangerous place starting on Monday.
However, a one-person SME, in the current climate, will not willingly train another person to be a SME, since that introduces a risk (as the SME sees it) that the organization can WFR them in favor of the newly-trained SME.
If the request is to train an offshore person to become a SME, well, if you are the corporate leadership expecting willing participation from the onshore resources, you are below naive.
Ditto documentation of processes. When a person perceives that their employer is looking for an excuse to WFR them, they are going to make damn sure that their business and technical knowledge remains implicit and tacit, not explicit and documented. The default in that sort of climate is that Knowledge is Indispensability. It is probably not true, but that is how employees will see it, and, like just about any employee, they will behave in a “circle the wagons” way to protect their position.

A culture of innovation, like credibility, requires constant renewal and attention to detail. Just as credibility can be severely or degraded by one perceived failure to deliver on promises or committments, innovation interest and engagement can be severely impacted and driven down to zero by one incident where innovators were seen to be punished for failures. Facebooktwitterredditpinterestlinkedinmail

The “government is so inefficient” shibboleth

Amongst self-identfied conservative and fans of what they term “small government”, it is almost an article of faith that the private sector is more efficient than the government.
(ASIDE – there is a good reason why I used air quotes in the above sentence, since I long ago noticed that many self-confessed fans of “small government” are only fans of that idea when they come across the government spending money on Stuff They Do Not Approve Of, otherwise they are perfectly OK with governments spending money. Lots of money).
One of the classic ways in which people instinctively opposed to government try to bolster their arguments is by pointing to the ineffiencies and waste that occur in IT projects within government. If they are better-informed, they usually throw in one or two notorious examples of pas failures that made it into the public domain.
There is only one problem with the argument.
The private sector is just as inefficient at IT solution delivery. In fact, based on my being involved with both the government and public corporations over the last 38 years, I can state anecdotally that waste, inefficiency, duplication, bungling, cost overruns and out of control projects are just as common in corporate IT. Some of the worst and most expensive failures that sort of made it into the public domain (such as the Confirm travel industry program), consumed hundreds of millions of dollars for next to no result or value.
There is, however, one big difference. Failures in corporations are more often and easily swept under the carpet or into a box marked “amnesia”. I have seen multiple instances of failed delivery programs being carefully spun as successes, “re-scoped”, or subjected to any one of a number of soothing outbreaks of corporate Doublespeak, in order to pretend that the whole damn thing never really happened.
In the case of government, especially at the state and federal level here in the USA, that tends to be less easy to manage, since elected representatives like nothing more than to rake government officials and leaders over the coals in public about a waste of taxpayer’s money. It is a form of ritualistic blood sport, allowing said elected representatives to preen, strut and intimidate in front of the media, as they engage in virtue signaling to their electorates that they are Relentless Stewards of The Public Purse.
Whether those public ritualistic floggings actually yield any positive results is doubtful. Excoriating in public is never a positive motivational strategy; it is about one half step removed from the old saying “the beatings will continue until morale improves”.
The underlying point here, however, is that when people complain about “waste” in government IT, they are conveniently overlooking that the levels of waste are just as bad in the private sector. The truth is that the issues with large-scale IT delivery are many and difficult to solve, no matter where the projects are being executed. Software development and delivery as an activity stream just does not scale well.

Healthprose pharmacy reviews