Today I wanted to call out a common mistake that I see at websites all over the country. Don't add pages to your website if you're not going to update them.
I'm particularly talking about pages with names like "News", "Articles", "Blog Posts", etc. They're often added when someone first builds a website and is full of hope for how it will be used.
And then it isn't.
I've lost count of how many sites I visit where there's a News section and when I visit it, there are two or three entries, often years apart. Or worse, there are a few entries from five years ago when the website was first created.
This makes your company look worse than if you didn't have those pages at all, so remove them.
Old Social Media and Blog Posts
I see a similar issue at companies that I consult at. I watched tools like Yammer being introduced, and the CEOs obliging someone, by making a post or two. And then the CEO is never heard from again.
It's the same if your website has a link to the CEO's blog. If it does, there had better be a bunch of pretty current content, or you should remove it.
The worst version of links to blog posts, is when the only posts are ones that apologise for not posting lately, and promising to post more regularly. And then that last post was two years ago and there's been nothing since.
It's simple: don't have these deadwood links in your sites. It's not the front door that you want to show to the world.
I was working with another client recently, and they were changing the working IT environments for their staff. What struck me as odd was that they called the new environments the Modern ones.
Modern was actually the name of the environment. I'm sure they currently see the environments as the modern ones, but soon enough, it won't be modern or new, and then the name looks really, really odd. In a few years' time, they'll have more recent ones, and it then gets tricky. Are they then the Even More Modern environments?
I see it a lot in IT, and I always think it's pretty naive to call something Modern or New.
I'm OK with those words in the marketing (like in the Windows 3.1 main image above), but not in the product or object name.
Please don't do this.
I work with a number of clients in a variety of industries. I'm constantly amazed by the larger companies that simply do everything they can to avoid paying for things that they should be paying for.
I'll give you two simple examples.
Many companies use TeamViewer. It's easy to use and it works well for what it's intended for. However I'd say that over 90% of the clients are using it as the free personal edition that says all over it for non-commercial use. I don't get why companies that are turning over tens of millions of dollars, or who are managing billions of dollars of other people's funds struggle to pay the correct licensing for basic utilities that they depend upon.
In the online course creators' groups that I'm part of, people are highly protective of their own intellectual property and endlessly concerned about people pirating courses. Yet when the same people need some graphical work, or they need some B-roll video, or they need a video recording and editing tool, the first thing they always expect is to find a free tool.
It's simple: if you want these types of tools to exist, please be prepared to pay for them.
I do quite a bit of online shopping. One thing that many sites have implemented, is an attempt to recapture your attention when you've added items to a shopping cart, and then abandoned the cart.
This is seen as a feature in many implementations of carts for online stores.
Given it's so common now, I've also found that many can be manipulated. For example, one clothing store that I like, will send me a reminder about my abandoned cart one day later. Often at that point, they'll make an additional offer, like free shipping.
But that's so predictable that every time I shop there, I put items in the cart, abandon them, and wait to see what deal is offered.
First lesson: Don't be predictable on this.
Now I'm sure that some purchasers are hesitant, and a simple reminder will get them to purchase.
But what many sites don't seem to "get" though, is that I will often have abandoned the cart for a reason. Something wasn't clear or something wasn't quite what I wanted.
I've noticed that none of the sites ever ask me why I've abandoned the cart. There is an enormous amount of value that they could learn if they just asked that question.
Instead, they annoy me, by continuing to send me reminders about my abandoned cart, without ever addressing my concern or hesitation.
Second lesson: Don't just pester people about abandoned carts. Ask they why or how you can help. You might be surprised by what you learn.
There's another annoying trend that I want to call out. Every single day, I receive emails like this:
I'm sure others get them too. Now I'm sure Tatyana is a lovely lady who's just trying to do her job and struggling to find business for her company. But I haven't the slightest interest in what she's offering.
Now I used to respond to these, and just say "No thanks" or "No interest".
Then I started saying "No thanks. Please don't spam".
But now I get so many of these per day that I just don't have the time to be responding to them. (I'm glad I'm not in the remote web development business).
So what's changed?
Now what's changed, is they've started spamming me for not responding to their spam.
Really? So now I'm getting anywhere up to 50 or 60 percent more mail from these people, because I didn't respond to their previous mail.
And some aren't done then. They'll keep sending it over time. Some even start to get nasty about not getting a response.
There's probably some sales coaching course somewhere that tells them that this is a good idea. It's not.
Please don't do this!
As I work at different client sites, I see a lot of discussion about the cost of cloud-based services, in comparison with on-premises or self-hosted equivalents. One aspect that always seems to be forgotten is opportunity cost.
So many times, I see people comparing raw incremental costs of virtual machines in the different environments. Invariably they aren't making an apples vs apples comparison. They aren't considering staff costs, training costs, power, real estate, support costs, etc.
But a really big one for me is the difference in opportunity costs. Let me give you an example.
I was working at a client site where we decided to test an application's interaction with Availability Groups in SQL Server. I asked if I could spin up a few servers in Azure to try it. I was told that that wasn't their policy and that they'd provision me servers to work with locally.
- It took four weeks to get a quote for the hardware.
- It then took six weeks for the hardware to arrive.
- Then I was told it would be another four weeks delay because they couldn't take a power outage to install them in the racks.
I wish I was joking.
This had added over three months delay in the project. So much could have been achieved in the meantime. If we had done that in Azure, I could have had the work complete by the next day.
There's no easy measure for the cost of the lost opportunity but it's significant. Don't ignore it when comparing costs.
On our SQL Down Under email list today, someone asked:
My title is DBA but my job is more into SQL Developer, fixing data involved in applications. Do you think if I study Power BI that I can get a better job?
I get asked this sort of question regularly, particularly from traditional DBAs who see their roles disappearing.
The most basic answer is to adapt what you're doing across to roles that are still in need like data modelling, query performance tuning, DB design in general, etc. However, I wanted to make some more broad recommendations for those considering something more radical.
Over the years, when I've been asked this, I point out that a key advantage of BI is that it tends to appeal to the people who pay the bills.
If you work on core business systems like invoicing, order entry, accounting, and so on, you can have a rewarding career. However, you'll be spending your life working in what the organisation sees as a cost of doing business. And that's something that they want to minimise.
The higher you can move higher up the IT ladder (in terms of value to the business), the better funded your projects usually are, and the more interesting your role is likely to be.
A simple example, let's consider a company like Amazon. The people who do all their IT for core order processing, shipping, etc. will have busy and probably interesting jobs. But their life will be full of head count restrictions, budget cuts, and an endless desire to minimise their costs. To get funded, most new projects will need to show that they lead to a reduction in existing costs.
Then consider the people who do the "hey you bought this, I really think you should consider this as well" code.
I can't say for sure, but I'd almost guarantee their projects are funded at an entirely different level, largely because they can directly affect the profitability of the company. New projects in these areas are much more likely to be seen as investments. They will also be likely to attract funding from outside the normal IT chain of command, probably from the Marketing team.
(I've seen predictions years ago that most of IT will eventually report to Marketing).
That advice has worked well for us, and still works now, but it's yesterday's advice, and now I see things differently.
Tomorrow's corporate battles, and even potentially the survival of the companies will be largely based around their ability to implement AI.
The first generation of AI was all about super-specialists, deep thinking, and looking for breakthroughs. It was owned by the 7 big corporations working in AI and their association to a handful of universities doing advanced work in the area.
This next phase of AI (following on from the development of deep learning) is all about implementing these current AI concepts, and applying them to so many aspects of business and the community. Even though the biggest wins will come to those who own the big data sets, there are and will continue to be amazing opportunities for commercialising existing AI concepts.
Our most interesting projects today are ones that are based around AI tooling, that's letting us solve business problems that we simply could not have solved any other way, at least not economically.
And if you want an area that's crying out for short to medium term wins, that's security.
The problems in this area are now almost already completely out of hand. There are estimates that this year alone, there will be shortages of hundreds of thousands of IT security people, but we're talking about serious security people. And this is going to get much worse.
The only foreseeable way to solve most IT security issues is via AI.
I'm not too worried about retraining now but if I was in my 30's or 40's, aiming directly at the intersection of AI and advanced IT security would seem a really safe bet.
Most developers and analysts today are fairly aware of the impacts of technical debt. As technical debt grows, it takes longer and longer to get real customer or end-user work done. Worse, more and more time is spent triaging and squashing bugs. And one interesting aspect of technical debt is old tooling.
I've written before about modern not being a synonym for better, but there comes a point where you need to modernise your tooling, even if it seems to be doing the job.
For me, the most tell-tale sign is when the author of the tools has apparently moved on from being interested in the tool. No matter how good a tool was, it needs to keep moving forward as requirements and operating environments evolve.
I deal a lot with Microsoft applications, and I often see these signs:
- People from the development team seem to have moved on to new jobs
- No-one is posting blog posts about what's happening
- The tool stops turning up on conference sessions, Channel 9 videos, Azure Fridays, etc.
- The flow of new features slows to a trickle or stops
If you ask the company, the tool is still supported and not going anywhere, but given the interest has moved on, you probably should too. I can only imagine that there's a desire to avoid upsetting anyone who's made a commitment to using the tool.
Many people refer to this type of tool as abandonware.
There are times though, when sudden spurts of life appear. A classic example is the work that was done on SQL Server Reporting Services in the 2016 edition. (I'll write more about SSRS another day)
What I really wanted to mention today though is another nearly-hidden downside of using old tools, as a form of technical debt. And that's your ability to find staff. You do not want to underestimate the impact of this.
Today, I was reading about a large company in Europe with untold millions of lines of classic ASP code, embedded with VB. They can't work out how to move forward now.
I feel for them. I've done work with customers where their entire code base was in VB.NET and ASP.NET WebForms. At least that was a step up from classic ASP. They had many hundreds of developers. Even if you're a stalwart who loved the tooling, you need to stop and as yourself where you are going to find staff who'll share that love.
Developers who desperately need an income (and thus a job), and are living from pay to pay, might work for you. But developers who have any options at all, aren't likely to do that.
You'll find it harder and harder to locate good people who want to work for you. You'll end up paying them much, much more than would otherwise be appropriate, and you'll end up lowering your standards for whom you're prepared to employ.
From the point of view of a prospective staff member, do you really want to have your resume showing you starting with that code today?
And if you really are willing to do any coding for the pay, why not learn COBOL and cash in? It won't take that long to learn, and there's still plenty of work around for those wanting to write it.
I regularly enter passwords into websites, and am told after I've entered a new password, that I can't use any special characters.
If I see a site that won't deal with special characters properly, it immediately makes me think there's some pretty poor coding going on under the covers. Very likely, the developers haven't thought through how the parsing of requests, etc. should be handled.
It's not just special characters either. Requiring short passwords is another red flag.
And if you're still using complexity rules (like at least one upper, one lower, one numeric, etc.), read the NIST recommendations on this:
If your website won't allow special characters in passwords, or reasonably long passwords (like a passphrase), it's an indication of poor coding, and it also makes you look like a potentially good target for attacks.
It certainly doesn't make your company look good.
Don't do this!