Opinion: Don't buy hardware before a Proof of Concept

Just a short post today to call out something that I'm seeing again and again. It's where organizations purchase all their hardware and software platforms before they start to carry out a proof of concept. This is a very poor option.

I was reading the data strategy for a global company that I was doing consulting work for. They were proudly introducing the new strategy yet I was sitting looking at it, trying to work out what they were thinking. The first step of their plan was to buy everything they needed. The second step was to carry out a proof of concept to see how it would all work (presuming it would work suitably at all).

This is ridiculous.

In that case, I think what's happening is that the IT management wants to seem proactive, buying hardware and software platforms is what they are experienced at, and they want to look like they are "doing something".

Image by RawPixel
Image by RawPixel

Yet, invariably, this locks them into decisions that aren't in the best interests of the organization. Instead of making sensible decisions, they end up making decisions, based on what they have already committed to. And the more expensive that purchase was, the more they will try for years to justify the expenditure decision that they made. Every choice will later be taken, based upon how well it fits with their existing purchase.

Don't do this.

Do everything you can to carry out the proof of concept without buying anything that locks you into a decision path.

Opinion: Take career risks while you can

In the 1980's and 1990's, part of my time was spent as a lecturer and tech services manager at a university. I particularly loved working with final year students and their project work. At our regular meetings though, I also often got into discussion with the students about their career plans, as they were about to graduate. What amazed me was how many super-bright students were looking to take incredibly boring jobs working on ancient technologies, in what were basically programmer graveyards, and when I asked them why they were intending to go there, invariably they'd tell me that they thought those jobs would be long term and low risk.

So a bright twenty-one year old student with no kids, no mortgage or other real commitments, and nothing much in the way of ties, was selling their soul for a low risk job.

Don't do this !

Take career risks while you can!

I understand that once you have a partner, kids, mortgage, etc., you don't have the freedom to try things. I've seen people I work with who are so tied to receiving a pay every fortnight that they can't make good decisions about their careers.

Image by Kevin Delvecchio
Image by Kevin Delvecchio

But if that's not you, don't sell yourself and your future short.

If you're worried about taking a risk, ask yourself what is the worst possible thing you can imagine happening, and then ask yourself if there is any way you could survive it, even if it's painful. And if you could survive it, don't hesitate to try. Anything that happens probably won't be as bad as you've imagined anyway. More importantly, you might just fly.

Image by The Nigmatic
Image by The Nigmatic

No-one flies day one, not even birds. While you can, just try things.

One of the saddest things I hear from older people is regret for the things they felt they could have done but didn't try.

Image by Ozan Safak
Image by Ozan Safak

Don't let it be you with the regrets.

Opinion: Avoid annual subscription surprises for your customers

Yet again, a few days back, I received two invoices that showed I'd just paid (via PayPal fortunately) a pair of annual subscriptions. These are subscriptions that I thought were already cancelled, and we'd stopped using the products many months back.

The problem is that I've now spent quite a bit of my time, and quite a bit of the vendor's time trying to work out how to cancel and reverse them. For days now we've had emails going backwards and forwards between ourselves and the 3rd party that they use for provisioning/charging.

That's a serious waste of time for all three organizations, and it means that I now feel worse towards a product (and the company) that I've already stopped using. That makes it even less likely (not more) that I won't use it or them again.

Annual subscriptions and pre-approved payments are becoming somewhat of a cancer in our industry. I get the point of them when I'm signing up for something ongoing. But I do not get the point of pre-approved future payments when I'm buying something one-off.

Why do so many companies do this? And why do so many set auto-renewals without asking you? On many sites, it's almost (if not) impossible to buy something one off without having to go back into the account after the sale and nuke all the pre-approval and auto-renewal stuff.

Here's a hint: All of these actions come across to the customer as dodgy.

Surely you want your customers to want to deal with you and want to pay you, not to be feeling tricked into ongoing things, many of which are quite hard to reverse. Are the companies simply hoping for customer apathy?

At least if I pay for these things with something like PayPal, I could set myself a monthly reminder to go into my account and nuke anything that I don't want to be pre-authorizing. But I shouldn't need to do this.

Probably the biggest thing that suppliers with annual subscriptions could do is to send you a reminder that you are about to be billed, a few days before you are actually billed.

It's hard to believe that we've become so "pro-consent" about email addresses and haven't done that for payments. And the IT industry is one of the worst offenders.

It's time for this all to become much, much cleaner and simpler for the customer.

 

Opinion: DIY security is not security

I spend a lot of time working in software houses. One of the nastiest things that I see again and again and again, is developers attempting to roll their own security and authentication mechanisms.

Spend a moment and think about how many security incidents the big companies (Google, Apple, Microsoft, etc.) have had over the years. Now think about how much effort they've put into doing it right, yet they still have issues at times.

The scary part about trying to do this yourself is that you often don't even know how scary what you are doing is.

Apart from the ones who do a reasonable job of password hashing, etc. I also see a surprising number who still store plain text passwords, or think that applying some "special algorithm that they wrote" to "encrypt" passwords or other private information is acceptable.

It's not.

I cringe every time I see someone who's written a algorithm that does obfuscation on a value before storing it. Worse is when they refer to it as "encryption" within the organization.

So my post today is just a simple plea:

Please don't do this.

The minute you find yourself writing "encryption algorithms" or authentication code, just stop. Just because you think you've got away with it for years, don't tell yourself that you don't have an issue.

I've seen the outcome at sites where this all goes wrong, and it's not pretty. You do not want to be anywhere near it when the finger-pointing starts. It all ends in tears.

Image by Tom Pumford
Image by Tom Pumford

 

 

Opinion: Design your own job

One of the software houses that I've done some work for over the years has had a number of unexpected issues with their clients and had to shed quite a lot of their staff. This is always a concerning time and I'm seeing a lot of worried and unhappy people. Either they don't think  their jobs will last, or they are upset at having been moved to roles that they don't want.

Many see no option but to try to stick it out, even if they hate what they're doing.

When I was young, the perceived wisdom was that it was best to get a job with a large company, as they have the stability for long term employment. I saw friends heading into banks, government departments, and Fortune 500 companies.

Image by Jordan Andrews
Image by Jordan Andrews

I'm sure there was a time long ago where this worked but I think the concept of stable employment at large companies is almost illusory nowadays. In so many organizations that I deal with, I see pretty regular churn, and whole teams of good people discarded, almost at a whim.

By comparison, my friends that have created their own jobs have had by far the most stable and  satisfying careers. Many have built something up and are still doing it, even if the specifics have evolved over time. The other argument for larger companies has been that higher income can be achieved, yet many who have created their own jobs have now earned far more than if they'd joined a large company.

One of the beauties of being in these companies only on a part-time contract basis, is not being concerned when these seismic changes occur with organizations.

The way that I see the world evolving, I think it will be more important than ever to be in control of your own destiny. While it can be useful to get a good grounding in a business area from a larger company (to perhaps get a better understanding of the norms and professional standards of your industry), your future is likely to be brighter if you take care of it yourself, rather than outsourcing it to the whims of some company that you don't control.

You need to be prepared to also take on the responsibility of your own career development ie: get yourself trained on useful areas, keep across new technologies, learn new skills. Be prepared to invest in yourself, not be someone who is whinging because your company isn't developing your career the way you'd like.

And while you're at it, find something that you love to do.

Over time, I can see there being far less traditional 9-5 full-time job roles available, particularly at the lower-skilled end of the market. Don't be one of the "oh woe is me – who will give me a job now?" people.

Design your own job; take the initiative to make it happen. It may take a while but start today; invest in yourself, and take control of your own future.

DevOps: Thoughts on Microsoft’s Acquisition of Github

I have many friends who would have checked the calendar when they first heard that Microsoft was buying Github. They would have guessed it was April 1st.

I think it’s another pretty bold strategic move by Satya Nadella.

It’s been interesting to see all the naysayers coming out of the woodwork to beat up on the idea of Microsoft owning Github, as though it was going to be the death of Github. Almost every single time I hear a justification though, it is based on their opinion of Microsoft or something they did often decades ago.

People outside the Microsoft camp seem genuinely unaware of the seismic changes that have happened within Microsoft in recent years. As someone who has worked with them and followed them closely for decades, I can tell you that it is a very, very different company now. If your opinion of them is based on anything more than a few years old, it’s time to re-evaluate your stance.

Microsoft is already a heavy user of Github, and is the largest contributor to open source software on the planet.

But more importantly, their acquisition puts Github into a solid financial position that it did not have before. Github was pretty much at a crossroads, had a few suitors, but in any rational evaluation, Microsoft was the best positioned for this.

From Microsoft’s point of view, I can see how it will beautifully mesh with many ongoing changes within the company, particularly as things like Azure Functions take hold. It also provides more certainty for existing Github enterprise customers, and will introduce a whole new raft of enterprise level customers to Github.

The one big concern that I have is around identity. This is an area that Microsoft hasn’t yet sorted out. There are still too many issues with Microsoft Accounts vs Organizational Accounts and so on. There needs to be a good plan to integrate the Github identity system.

Opinion: When building an SaaS application, you're only as good as your weakest SLA

The industry is clearly trending quite quickly towards Software as a Service (SaaS) applications. Rather than building monolithic chunks of code, new applications are often constructed by combining a variety of platform services, themselves usually delivered as Platform as a Service (PaaS) offerings.

Any application layers that you build above these services though, are only as good as the underlying services. And that's where things can go very, very wrong quite quickly.

I was at a software house recently where the management that I talked to said they couldn't ever be offline for more than about four hours. In fact, anything more than two hours would be a problem. The IT people at the same place told me that backups of their primary database were taking over eight hours, and that restores would be longer. I'm often left wondering if these groups of people within the same company even talk to each other. Clearly there was an expectation gap.

Image by Paula May
Image by Paula May

I was also recently working at another ISV (Independent Software Vendor) that was looking to provide a SaaS offering, and were offering their end customers an SLA (service level agreement) that said they'd always be back up and running within 4 hours. But the data centers that they were depending upon had an SLA showing that loss of a region could involve an outage of one full week. (And the customer data could not go to another region)

What makes this worse is the current trend for many of these services to be impenetrable by phone or for anything urgent.

One of our suppliers had a major outage last week because one of their own suppliers (NameCheap) had decided (incorrectly) to disable their DNS entry because of spam reports. So our supplier was offline, and could do nothing except email NameCheap's support team and hope they would respond soon. They told us that there was no way for them to call NameCheap.

But even if that's the case, NameCheap isn't alone on this. It's a common trend. If you are building any sort of SaaS offering though, you need to realize that you are only as good as your weakest link (or in this case, SLA).

A new day – another hosting provider – I have high hopes

For many years, I was blogging at sqlblog.com and I was a big fan of what Adam Machanic and Peter DeBetta had done there. Eventually though,  community server was on its last legs, and WordPress seemed the obvious platform for a blog. Fellow MVP Adam Machanic made it really easy for me to migrate to a WordPress site with a tool that he had created.

I headed off to BlueHost with high hopes, but those hopes just haven't been fulfilled. I've had a number of times that things just stop; it's hard to get to the bottom of what's causing it; the support is really glacial at times (ever had a chat with someone who is having a conversation with 10 other people at the same time?); and it turned out that what's broken was something that apparently I was responsible for but didn't even know existed.

All I wanted for the blog was a managed service.

So today is the start of a new period. I've headed to Site Ground. Their reputation for service seems great; they claim to really have a managed WordPress service; and they seem pretty easy to deal with.

My initial sales and migration experiences have both been very positive. Prompt, courteous, and in clear English. Their offer to transfer the content for free was a major bonus. I worked out how long that was going to take me over our current Internet connection and figured it was better to let them do it. I have to say it was pretty seamless.

I have high hopes again, and I'll let you know later if those hopes were warranted.

Fix: Re-enable iPhone Microphone Access in Skype for Business

The other day, I joined a Skype for Business call from the Microsoft Regional Director program that I'm part of.

I was using my iPhone and I chose to use the web option to connect. I'd say it must have flipped me across to using Skype for Business anyway. (It is installed on my phone).

I thought there would be a large number of people in the meeting, and that we'd be muted the whole time, so when it asked if it was OK for the app to use the microphone, I said "no". Clearly I should have just left myself muted instead of disabling microphone access.

Once, I got into the meeting though, I found it was a relatively small group of people on the call, so I set about trying to re-enable the microphone. Try as I might, I couldn't find any way within the app to do that. It showed me unmuted but still wouldn't let me speak.

I then presumed that it must be a setting in the iPhone that had been turned off. I looked in Settings, for the Skype for Business application, and didn't see it. I tried the settings for Skype and they had no effect. I even restarted the whole phone, and re-entered the meeting. Still nothing.

For the life of me, I couldn't work out how to re-enable microphone support in the app.

Turns out the reason is simple. I was looking in the right place. I had looked down the application list, but as they are shown alphabetically, I was looking down near "S".

This is where it was:

In the list, Skype for Business is just labelled "Business".  I've got a lot of apps, and there's zero chance that I would have thought to look there.

Hope it helps someone else.

 

General: PowerPoint – sorry we couldn't find slide1.PNG – Unexpected space

Today, we were having trouble saving a PowerPoint slide deck as a set of PNG files.

The error message said:

Sorry we couldn't find slide1.PNG. Is it possible that it was moved, renamed, or deleted?

After trying to copy the slides into another deck to replace the original deck, the same problem existed. Saving in PPTX format was fine. Curiously, saving individual slides was also fine.

I found a few blog posts online that said it might be to do with an embedded period in the filename. That wasn't the case but it gave me the clue that I needed.

The filename had a space before the .PPTX. This caused the error above. Removing the space fixed the issue. So if you see this issue, check if there is any nonstandard issue with your filename.

Hope that helps someone (including me the next time I run into the issue and can't remember what the problem was).