At Usersnap, we have over 20 (summed up) years of experience in well organized web development. We figured that track record allows us to call out the good, bad and the ugly in the industry. Now, we don’t like to focus on the negative, but just this once we’ll sum up the bad, as the logical follow-up on our post on best practices in web development.
Mails with 20 bullet points, listing bugs, feature request and what not, are as much a commodity as a problem. Often they lead to accusations and “why didn’t you fix $XY, as I pointed out five weeks ago?”-s. In case your head of development is not able to drill these monologues down to workable tickets, chances are you forget things. Instead of muttering all kinds of things your mother didn’t teach you, try and educate your clients or managers how to use a bug tracker or project management tool.* That way you both save time sending countless lengthy emails, and they’ll have a better view of what you’re currently working on.
CC’ing all means: you have no idea who can solve this task. Which is bad in itself. If you start doing this, potentially no one will answer or feel responsible. Plus: reading all those mails will kill a lot of precious time for those who are not into it. Find out who is responsible and address that person only.
Letting somebody test issues who has no idea what the original error was, is yet another way of wasting your team mates time. Example: a customer complains about buttons not working in Internet Explorer. The first dev that gets his hands on it fixes the issue, and another one QA tests it without even knowing how to reproduce the issue.
Splitting up your team to fixed parts of your development is a bad idea and incredibly un-agile (don’t worry, we don’t make a habit of using that term). Separating ‘frontend’ and ‘backend’ leads to “Grabenkämpfe” (or: War on the -ends), which is – not surprisingly – not great for team spirit. Frontend devs will complain that “the backend changes takes ages”, whereas backend devs will complain about “the fifth change of the API in this year”.
Releasing untested code, just because it’s HiPPO** (highest paid person’s opinion) is a bad idea. Even worse: doing this thing on a Friday evening. Unless of course, you’re not much of a weekend person anyway…
Yes, this is harsh, but starting to polish CSS animations while nobody has seen your page is not helping in getting things done. If you have any background tasks or reports, it simply doesn’t matter if they run in 10 or 5 seconds, when your servers are not loaded. Start optimizing once everything works. We do believe in optimization (a lot), just check out point 9 in our previous post!
American computer scientist and Professor Emeritus at Stanford University Donald Ervin Knuth is the author of the seminal multi-volume work ´The Art of Computer Programming´. In his ‘Structured Programming with go to Statements‘ paper he states:
Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.
In short: starting to optimize before it’s clear what you’re optimizing, brings all kinds of unnecessary complexity and errors.
We could go on for a while, I mean, I wouldn’t call changing production without backups or developing without specifications bright ideas either. But luckily you won’t encounter these missteps that often.
For a third post in this series we’ll look into the dark and ugly side of the programming world.
* You might want to set different (editing) rights for different parties.
**Data killed the HiPPO star
[otw_is sidebar=otw-sidebar-4]
In today's market, product managers and CPOs can access a wide range of Enterprise Feedback…
In today's product management space, finding the right tools to navigate the complexities of the…
In the early days of personal computing, my generation used to spend a lot of…
For Product Managers and Developers, selecting the right, usability testing platform and tool isn't just…
Attention, Product Managers! Imagine a whole user journey where grasping your users' needs isn't a…
Why do the most successful product managers always seem to pay attention to the power…
