And you are here why?

Say you’re building something completely new and different, which can leave users feeling anxious and/or confused. How do you introduce it to the user, and get the user actually, well, using it? It’s a good question, and particularly relevant in our current world, where we are constantly being bombarded with information, with the volume and content thereof being ever-increasing. Mind you, the fact that we spend our days hunched over a computer and/or a phone doesn’t help at all — if anything it only emphasizes the sheer amount of cognitive load that we all live with on a day to day basis. In this environment, the last thing you want is to add anything to this cognitive load. As product developers, succeeding in this world involves either outcompeting the others, or making life easier for your users. Assuming that you  aren’t  in the business of being evil (please please don’t be evil!), your approach towards UX should focus on ensuring that the users  know  t...

There is a persistent myth — particularly prevalent amongst control freaks— that if you get the  requirements  detailed enough, you can assembly-line your way through  development . Dig deep enough, and you’ll find that to them,   Agile is the same as Iterative Development   . Oh, they absolutely get the bit about “ user feedback ”, “ short sprints ”, “ incremental releases ”, and so on. However, in their minds, all of these steps apply   only   to the development process, i.e., you do all of these things   after   you’ve nailed down all the requirements, as shown below From their perspective, you just iterate through the development cycle in a succession of sprints, in what is basically a linear progression. In each sprint, for example you cycle through  Design → Development → Release → Review  for 10% of the requirements, and at the end of 10 sprints,  voila! you’re done! Oh, if you want to get a little pedantic, t...

“I don’t need requirements — I know what I’m doing” —  #CowboyDeveloper A paraphrased version of an actual PR-related discussion I had recently follows. And yes, I’ve had this conversation more than once in my career — there are a  lot  of #TechBros out there  . Hey Bob (let’s just call him Bob), I wanted to talk about this PR you just submitted. Specifically, this bit in the config file —  e nable_network_console: # Yes | No  — care to explain it?¹ Oh, I see, most of the users don’t want the network console, but some might? So you’ve got that in there, just in case anybody wants to enable it? Cool, cool. One more question though — why do we even have a network console in the first place? I mean, I was looking at the requirements behind this PR, and I don’t actually see anything about network consoles, let alone enabling/disabling them, y’know? Oh, right, you thought it might be a useful feature, so you put it in there. Make sense. And they’re not in the requ...

Irreducible Complexity Swapping out your monolith for micro-services — or just using micro-services in the first place — is, in theory an obvious thing to do. After all, the larger your monolith (“one big thing”!) gets, the harder it is to for you to keep track of everything in it. The architecture eventually get to a place where you just can’t visualize it all in your head. Oh, loose-coupling helps, as does componentization, layered architectures, queues/service-buses, and whatnot, but, in the end, you’re limited by the irreducible complexity of the system. So, you do the obvious. You extend loose-coupling to the breaking point, by, literally, breaking apart the individual components into distinct micro-services. Now, each of these micro-services can be visualized in entirety by  its development team, and you can task somebody else with visualizing how all the individual components fit together. So simple, right? You’ve basically  decoupled  the individual compo...

/via http://www.commitstrip.com/en/2013/08/28/faut-que-jte-dise-un-truc/ Life on the Leading (and yes,  definitely  Bleeding) Edge means that you’re always working around that *one* feature that doesn’t quite work the way you’d like it to. Read this, and tell me if it sounds familiar — 1.  You start working on a new system. It’s important, so you can’t really just experiment with Bleeding Edge stuff, but you’ll use this relatively new framework (or library. or codebase. or whatever) that you really like. It’s been around for a while — not so long that it’s Old, and therefore UnCool — but long enough that it’s got most of the kinks worked out. Besides, it’s perfect for what you want to do. 2.  The thing is, it is  almost  perfect for what you need. There’s this one feature that you wish it supported, but you can work around. So you —  happily!  — work around that feature 3.  Over the next few months, it turns out that that one feature that you...

“ Look at all the code I wrote! ”  —  #CowboyDeveloper If you hang around  #CowboyDevelopers  for any length of time, you’re sure to hear the above refrain. It  is  a bit of a catch-all phrase, but the situations you’re most likely to hear it involve 1.  Bragging Rights : Code quantity as a proxy for capability. Or, to put it differently, “ Mine is bigger than yours ”. 2.  Settling Arguments:  After all, it’s a well known fact that the amount of code you write is directly proportional to how correct your implementation is  . 3.  Continuing With The Current Approach : Basically the  Sunk Cost   fallacy , the amount of code that was written by the  #CowboyDeveloper  is consider dispositive evidence that the current approach is correct. The commonality to all of this are the implicit assumptions that a)  Writing code is hard. b)  Therefore, the more code you’ve written, the more hard work you’ve do...

/via https://www.monkeyuser.com/2016/testing-hammering-nails/ This totally nails it when it comes to Manual Testing, doesn’t it? Oh, I agree, there is a place for manual testing — smoke tests to build confidence, complex tests that simply can’t be automated, and so forth. However, what I  do  see all too often is Manual Testing being used as the default approach to existence. This, typically in organizations where QA consists of “ those folks over there ”, and developers consider testing a four-letter word. My advice — if you’re working at one of those places, and if you have agency, leave. It’s just not worth the candle…

So you’re going to revolutionize ice-cream delivery, through the powers of your iOS/Android app. ( Work with me here. Pretend that you’ve actually invented a better mouse-trap ) Your back-end runs on an AWS/EC2 instance, which is fine while you’re developing, but as you start thinking about real live customers,  reliability  comes to mind, and you split the back-end up so that it’s running on  TWO  AWS/EC2 instances. Great, right? If one goes down, the other takes over the load, and everything is hunky dory (as long as you the combined load is less than the capacity of any one of the servers, but let’s ignore that for now). Except, what if  AWS itself goes down ? As  June 29, 2012  taught a lot of us, the un-imagineable  does  happen every now and then. The solution, of course, is to deploy your instances across multiple availability zones, or maybe even multiple regions, or heck, while you’re at it, across multiple cloud providers....

So, you’re building a widget, for example, a temperature sensor. Do you display the temperature in ℉ or ℃? The answer, of course, is “it depends” • You might be able to get away with a switch that toggles the display between ℉ and ℃. • OTOH, If this is going into an airport, with travelers from around the world, you might want to display both And so on. The point being, the amount of configurability that you throw into this depends entirely on what you plan on doing with it, the  requirements  for your widget. After all, the switch, while effective for home use, is actually counter-productive for airport use, no? And that brings us to the User Experience. When you’re building out  any  UI, be it the simple widget above, or something far more complex like a online trading system, you  have to approach configurability from a UX perspective! The vast majority of UI out there falls into one of the following two traps 1.  Feature Overload : The us...