Please or Register to create posts and topics.

Never leave a developer with your website's access without supervision

My mom loves garden and flowers.

And I always remember as a kid she'd only get a gardener when she was around.
"Otherwise, they'll make a mess", she'd say.

Same exact thing when hiring developers.
You always want to be around when they're working on your website.

I was writing on another topic some minutes ago and as soon as I hit the button "publish", and the forum was gone (luckily I almost always hit "control A (select all) / control C (copy all)" before hitting "post").

Then I checked the website, and it was a huge mess.

Then I went to check the admin area, and it was empty.

I checked the plugins, and they were all de-activated.
And then I realized why:

Had I been*

To find out the possible issue with a non-critical plugin that was already misbehaving, he deactivated all other plugins.

That meant no forum, no course, and an almost un-usable website.

Almost like telling someone "I found the issue with your strange noise from the engine: I removed the engine completely, and the noise is gone. Here's your working car back now".

The very least you can do is to tell a developer in advance: "don't activate any plugin without asking me, and don't deactivate anything without asking me first.
And if you need to make major changes, please speak to me about it".

But sometimes that's not enough.
And if you're dealing with open tickets, someone new might get that ticket and won't read the previous posts anymore -exactly what happened here-.

So, best of all, don't give access to the live website to anyone unless strictly necessary and unless they know exactly what they're going to do.
Prepare a staging environment for them, and send them there to experiment and troubleshoot.

Have you read the forum guidelines for effective communication already?

That must have been scary!

This developer must have become too focused on fixing the plugin and forget that you have users on your website.
Technical problems sometimes require a lot of focus, so the developer could have become single-minded on debugging the plugin issue.

That being said, the developer has really poor software engineer practices.

Lucio probably has experience with the workflow of deploying software.
Because he mentioned about cutting down plugins for faster response time and maintainability.
But I would like to touch on this topic more so that everyone on this forum can avoid such issues in the future.

This is not meant to be a comprehensive post.
Software engineering is a whole subject by itself.

Standard Practice

This web page is a good guide for deployment best practices.
As you mentioned, there should be a staging environment.

In practice, there are usually 3 stages to developing, testing and deploying new code.

  1. Development Environment – developer writes new code and tests locally
  2. Staging Environment – developer merges new code into the staging environment for further quality assurance and testing
  3. Production Environment – once all the quality assurance tests are passed, merge the robust code into the production environment

The developer should have switched off all the plugins and test on his own development environment.

When he is confident, he should merge his code with the staging environment.
Best to hire an independent quality assurance tester to run tests on this new code in the staging environment.

Once all the tests are passed, then the code is uploaded to the production environment.
Dangerous tests should not be done in the production environment! (Most of the time)

Screening Developers 

Screening developers about their development process will alleviate pain.
See if they understand this workflow.
Ask if they have Github/Gitlab, and check out their projects.
This is a sign that they understand proper development practices. (Not full-proof)

Technical Debt

Sloppy developers also create technical debt in the long run.
The codebase gets messier and becomes unmaintainable.

Quote from the website Red Earth Design on November 30, 2020, 12:15 pm

Technical debt is a metaphor that equates software development to financial debt. Imagine that you have a project that has two potential options.

One is quick and easy but will require modification in the future. The other has a better design, but will take more time to implement.

In development, releasing code as a quick and easy approach is like incurring debt – it comes with the obligation of interest, which, for technical debt, comes in the form of extra work in the future. Taking the time to refactor is equivalent to paying down principal. While this takes time in the short run, it also decreases future interest payments.

Wordpress core is known to have technical debt.
Its plugins are also known to contain some as well.
This may explain why plugins may become increasingly incompatible with one another.

Yeah, all your work gone in a matter of minutes, not the best feeling :).

Great post, Matthew, and great point on "technical debt".

That's why it's best to stick with one great developer -or one great head of engineering if you're a company- for as long as possible.

The worst is hiring several different developers for short-term gigs.
The incentive with short-term hiring is to be as quick possible, fix the issue right now, and who cares what happened in the past -or what will happen in the future-.
So they'll all be throwing at the issue whatever code seems to make it work, without checking what's been done previously, and you end up with a patchwork of code lying around.

Have you read the forum guidelines for effective communication already?

 

Quote from Lucio Buffalmano on December 1, 2020, 5:13 pm

Yeah, all your work gone in a matter of minutes, not the best feeling :).

 

Absolutely terrible, though at least it emphasizes the severe necessity of backups. If one never experienced something like this, and were sloppy with backups, absolute disaster may strike at some point.

 

Reminds me of a financially sucessful friend who got scammed by someone we both knew and considered to be a friend at that time – he lost something in the low five figures, but eventually accepted it and concluded that it was an expensive, painful but necessary coaching.

 

If it hadn’t happened at this point he would still be a bit naive and may very well had ended up loosing in the six figures down the road later to someone else – as especially financial sucessful people attract all kinds of parasites.

 

 

Quote from Lucio Buffalmano on December 1, 2020, 5:13 pm

That's why it's best to stick with one great developer -or one great head of engineering if you're a company- for as long as possible.

 

Very reasonable what you both write on this. Short term fixes are like putting a bucked under a leaking roof, which may help momentarily, but it only surpresses the symptoms and doesn’t compare with a more fundamental approach to solve the actual problem.

 

Anon: Reminds me of a financially sucessful friend who got scammed. he lost something in the low five figures, but eventually accepted it and concluded that it was an expensive, painful but necessary coaching. If it hadn’t happened at this point he would still be a bit naive and may very well had ended up losing in the six figures down the road

That's some powerful reframing.

If you feel like it's possible to share some details, and that knowing about it could help others avoid similar scams, happy to hear.

Have you read the forum guidelines for effective communication already?
Quote from Lucio Buffalmano on December 3, 2020, 12:49 pm

That's some powerful reframing.

If you feel like it's possible to share some details, and that knowing about it could help others avoid similar scams, happy to hear.

 

Yes he got over it and it truly was a lesson for him - but also for everyone else who knew about it.

I would like to tell the whole story, though think I shouldn't - but I wrote what I think were the key takeaways with a few details in the hidden part of the forum here.