10 Modern Software Over-Engineering Mistakes

Few things are guaranteed to increase all the time: Distance between stars, Entropy in the visible universe, and Fucking business requirements. Many articles say Don’t over-engineer but don’t say why or how. Here are 10 clear examples.



Two other great articles linked in that one:

Refactoring — Not on the backlog!/

Write code that is easy to delete, not easy to extend.

Speeding up AngularJS apps with simple optimizations

  • Before diving into code, consider how to best architect your application to avoid performance challenges that dirty-checking faces in large quantities of Objects.

  • Be mindful of ng-repeats — how much data are you expecting back? How much weight is that going to add to Angular’s $digest cycle?

  • Not everything needs to be “Angular.” In Directives there are many cases we need to work with pure DOM.

  • Keep checking out the Angular project on GitHub, as there are often some great hidden features that can be found from upcoming releases. That’s how I came across the “bind once” functionality.

  • The more $$watchers there are, the slower your application will be, and with some of the performance enhancements above, even their simplicity can make a huge difference


aXe – Automated Accessibility Testing

I say, old chap – what a BLOODY good idea!

Deque System’s aXe (The Accessibility Engine) open source library is a lightweight (~100 KB), fast, portable JavaScript library that executes automated accessibility testing inside your testing framework or browser of choice.

Accessibility seems to be the last realm of ad-hoc testing (ignoring the fact that most realms of automated testing are frequently aspirational!), so aXe sounds like a fantastic plan:

Deque’s aXe: The Accessibility Engine

Debugging CSS during drag and drop [Chrome]

Note: You can probably do similar in other browser Dev Tools – I just haven’t checked yet, and despite it’s memory hogging, Chrome is still my dev browser of choice.

+1 to my colleague Dadu for showing me this neat interface hack.

Debugging CSS during drag and drop is a horrible pain – how in hell do you inspect something when the moment you let go of the mouse to get to the dev tools the state changes?

By mildly abusing an unrelated feature, we can freeze the application state, leaving our dragged element floating in space and burrow around the DOM to inspect the CSS classes and work out why everything doesn’t look quite as perfect as we would like (aka ‘horrible’).

Open Dev Tools, jump to the sources tab, and check out the Event Listener Breakpoints.

OH LOOK! There’s a Drag / drop event!
NO. Bad kitty. Stop there. If we use this, we’ll get a breakpoint on the very moment a drag/drop event is called. We don’t really want that.

I want to pause the UI state at a moment of my choosing, perhaps while dragging over a particular element. So… Instead of drag/drop, check the Keyboard event box.

Screen Shot 2016-09-15 at 11.23.58

Now, drag whatever you like, and at the appropriate moment hit any key.


Voila – one paused state. You can’t right click to inspect elements, but you can use the element selector tool -hit the button top left of the Dev Tools pane,  or [Cmd/Ctrl] + [Shift] + [C] and point at the element you want to inspect.

Screen Shot 2016-09-15 at 11.48.17

Or, if you are a masochist, drill down through the DOM in the Elements panel. It’s up to you I suppose.

Don’t forget to uncheck the Event Listener Breakpoint when you are done…

It’s quiet… Too quiet!

I’d like to say that I’ve just been too darn busy to post since December, and while that’s not entirely untrue, the reality is my host disappeared in a puff of smoke, and I’ve lost a few posts. But we are back, and normal service is resumed. Don’t mind the gap…

Unfortunately this does mean that we’ve lost syntax highlighting temporarily, which is a touch annoying. A little busy just now (as per) but I’ll get round to sorting that soon.

[EDIT] Syntax highlighting has been restored! Some of the older posts that were never updated to the previous highlighter are still out of whack, and a few are mangled for formatting, but I’m trying to work through those too.[/EDIT]

Multi-step CSS transitions

Every so often I come across something that genuinely surprises me, that seems like the kind of thing I really ought to be familiar with. This is one such thing.

Adding stops or keyframes to CSS transitions dramatically increases the power and flexibility of your animation. There may not be a million use cases for it, but when your designers start requesting complex visual behaviours, knowing we can do so much more of this in pure CSS is a fantastic addition to the toolbox.


W.H.O. says processed red meat bad. Conscientious devs told you ages ago…

Burgers are bad for you mmkay?

Specifically, the over-production and enforced consumption of burger menus on mobile and responsive sites.
Some sites even use them on desktop!

This is news to you?
Google: UI UX Burger Menus Are Bad

Who am I to talk of UX/UI? Have you seen my site? It’s HIDEOUS!

Yeah, I’ll deal with that some other time. This is just a scratchpad really, no one reads it anyway.

Back to the topic at hand – it has been posited that providing access to a top tier of priority links is a major improvement on the burger menu, even if you have to resort to the cheap cuts for deeper navigation.

Here’s a nice implementation of that:

Fixed backgrounds fixed

Deliberately confusing title of the day goes to…


Original article: fourkitchens.com


Fixed position backgrounds cause performance issues with the content being scrolled causing constant repaints.

This can be improved by using the CSS property will-change

The secret is to put your background in it’s own element (a pseudo-element will do fine) and give that element will-change:transform;|
Note the examples are SASS syntax

You can see that our background image uses two GPU-intensive features of CSS: background-size: cover and background-attachment: fixed. Once we fix this painting issue neither will be a problem, since they will only be calculated once to render the initial page. Scrolling will no longer cause repainting once the image sits in its own layer.