IT and Tech

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 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

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.

Doubt and caveats and their role in trust building

A number of years ago, I was fired off a consulting gig.
Anybody who is a consultant knows that this is always a possibility. Consultants are hired guns, and can be un-hired, sometimes on a whim.
I tend to think that, to use an old sports coach joke, there are two types of consultants; those who have been fired, and those who will be fired.
The manner in which I was fired from this assignment (no, I did not get fired from my employer – the client simply rejected me) was a story in itself, mainly because of the bizarre way in which it was communicated.
However, one of the reasons that was given to me was that I was “too non-committal”. Apparently this was because, when asked if my team could do something that had not been previously agreed, I would say “let me evaluate that and I will get back to you”. To me, this was commonsense. I had a full plate of transition for a Testing tower. If I had said Yes to everything, I would have been an integrity-challenged fool.
The problem was that many of the people working on this transition from in-house IT to a service provider (my employer) were from India, and their cultural instinct was to say Yes to anything they were asked to do. So, the client would go to another group, and ask “Can you do X?” and the Indian delivery teams would say “yes of course”. Then they would go away and try to work out exactly what it was they had said Yes to (I kid you not. Myself and a work colleague actually overheard them around a coffee machine trying to decide what they had just said Yes to after one meeting. Amusing and frightening at the same time).
So, according to the client, I was not helpful, because I was non-committal.
I was reminded of this when reading this essay about how doubt build trust. To me, the basic idea is somewhat obvious. Especially when you consider the historical contempt that people profess to hold for “yes men”. However, many people say Yes to loaded or leading questions when they should demur or ask for time to reflect. I routinely say “let me think about that for a moment” when asked questions. If people think that makes me slow, or dim-witted, well, I guess they can think that while I go on my merry way. Facebooktwitterredditpinterestlinkedinmail

Uber and the Dot Com meltdown – deja vu all over again?

I arrived in the USA in the Fall of 1998, at a time when a revolution was being plotted in start-up rooms, and pitched to eager venture capital firms and private wealth funds.
What was to become known as the Dot Com era was beginning. With the appearance of usable web interfaces around 1996, the Big Idea that germinated in boardrooms was that all manner of business interactions, instead of being conducted face-to-face in what were termed “brick and mortar” locations, or via telephone, would occur via web sites.
The premise was that disruptive innovation was coming to business with consumers via internet-based interaction.
A lot of people loved the idea. In my industry sector at the time, airlines, hotel chains and transportation service providers were rubbing their hands in glee at the thought of being able to sell direct to the public. They were, as they saw it, impeded financially by having to sell via intermediaries such as GDS vendors and travel agents, who all took a percentage of their revenues. With this new model, who needed the grasping middleman? Suddenly, another words was on a lot of people’s lips. Disintermediation.
From my new IT perch in the USA, I watched over the next 2 years as the Dot Com era showed up, grew exponentially, crested, and then imploded. Like all bubbles, it burst spectacularly, with most Dot Com startups being shuttered, sometimes after burning through horse-choking piles of cash before failing (hello WebVan).
There were a whole host of reasons why Dot Com turned out to be a bubble, ranging from ludicrous over-optimism, a total lack of realism (who knew that building scaleable web sites could be..well, kind of difficult), and the presence in the mix of a fair number of bullshitting charlatans all uttering variants of the mantra “if you build it, they will come”.
The Dot Com era is now far enough away in many rear-view mirrors to have been almost forgotten by many people in and outside of IT and Tech. This is not surprising, given the well-documented (and somewhat necessary) tendency of humans to remember Good Stuff and mysteriously fail to remember Bad Stuff.
It is certainly far enough away for start-ups to be able to collect large amounts of VC cash and proceed to burn through it at a merry rate. Just like the Dot Com era, many VC-backed businesses today may never be profitable. I am still trying to fathom if Twitter can ever make money, given that it cannot regulate content, and as I keep saying, all free internet sites eventually suffer from UseNet Syndrome.
One of the most-funded startups toaday is Uber. Like many Dot Com-era businesses, Uber’s value statement is based on disruptive innovation – the ability to call up a taxi ride online, have it arrive quickly, and pay either online or in person. Uber has been expanding rapidly for a few years now. As is normal for what looks like a disruptive technology (certainly disruptive if you are a cab driver in a big city), Uber’s expansion has run into roadblocks, some of them related to the reality that legislation does not have the ability to handle disruptive innovation. Just like the drone/UAS industry, many cities and states are not set up to facilitate an internet-based ride-hailing business, and some of them are hostile (see Austin TX).
However, at the end of the day, Uber has to make money, or it is ultimately doomed. The problem is that it may never be able to make money. Uber’s strategy clearly involves transitioning in the future from owner-driven cars to autonomous vehicles, thus eliminating another intermediary source of cost (the driver). However, given the comment I made about legislation not keeping up with technology, it is not clear how soon that can happen.
This article makes the claim that Uber is actually doomed with its current business model, and may end up as another WebVan. The money paragraph is this one:

…Uber lost at least $2 billion in 2015, a shocking deficit it followed last year with a loss of $2.8 billion — a number that didn’t even include its star-crossed attempt to break into the Chinese market. Much of those losses had come in the form of subsidies: Uber was paying bonuses to drivers to get them on the road and keep them there, while subsidizing rides for users by charging well below the true cost. The idea was to get people so addicted to the Ubering lifestyle that the app would be baked into their lives, to such a degree that no one would much care if and when the subsidies went away and the price went up. Or Uber would simply drown its competitors in cash until the advent of autonomous cars got rid of its biggest cost: drivers.

It’s the Dot Com era all over again – a start-up flush with VC cash is clearly willing to endure massive short-term losses (the amounts of money that Uber is prepared to lose are making WebVan’s losses look like chump change), in the hope of establishing a dominant market position. Baked into the whole current business model is one of the oldest tricks of an aspiring business monopolist (predatory pricing), coupled with an optimistic belief that a disruptive technology (autonomous vehicles) will ride in and Save The Day.
My humble opinion is that Uber cannot succeed as a buisness because it relies on too many cards in its poker deck falling its way. Uber’s claimed market capitalization of up to $60bn is a polite fiction for a business that is losing $2bn a year. Anybody who believes that probably also believes in rainbow pixieland and unicorns, and deserves to be parted from their money.


Healthprose pharmacy reviews