16 ms·
A variant of this that has driven me to quit more than one job is having a non-technical manager look at a UI prototype and consider that 90% of the solution. "
by caymanjim 6y ago
A variant of this that has driven me to quit more than one job is having a non-technical manager look at a UI prototype and consider that 90% of the solution. "The UI guys had this page ready two months ago! Why doesn't this work yet?" It's even worse when you present a working prototype. They simply don't understand that the backend functionality is what's doing the bulk of the work, and just because you can see something, that doesn't mean it's secure, performant, scalable, or even functional beyond demoing with dummy data.
- cosmodisk 6y agoIt's all correct: 90% takes 5 days and the rest 10% will take 3 months.
- dwd 6y agoExcept the UI guys chewed through 2 months in elapsed time getting the design approved and across the line and you now have to compress the 3 months you told them you would need into one to meet the delivery date management had in mind.
- zachrose 6y agoI sometimes look at small mass-produced plastic items and marvel at how hard it would be to make one from scratch. If you showed me, say, a fluted plastic bottle of wite-out with a screw-on cap, I would have to assume you had a very expensive operation up and running that was already churning these out. In software we can put a few shapes on a screen in just the right context and people will believe there's an operation as sophisticated as the wite-out bottle factory behind it.
- DougWebb 6y agoYou could spend a few hours making a 3D print of that bottle to produce a very believable mock-up. And then use it with someone gullible to make a deal on an order to manufacture a million of them. You get your commission on the sale, toss the 3D print to your manufacturing engineer, and let them know the customer needs delivery next week.
- chrisacky 6y agoI literally just had a discussion with a client last week about a feature taking 2months to develop.in my time this week I built the UI, with no backend, and she asked why I quoted two months when it looks like it's already completed.
- AnimalMuppet 6y agoYes, it "looks like it's already completed" because you did the "looks" part. I get that you want to show them that part to get approval of the design approach, but it opens the door to misunderstandings like this. Maybe as part of the demo, you should demo that it *conspicuously fails to actually do anything", to help reset unrealistic expectations.
- symlinkk 6y agoTo me it just sounds like your frontend has a better architecture than your backend.
- tamrix 6y agoDon't blame your stakeholders or customers. These are all just communication issues and common ones at that. Unfortunately communication for software projects isn't often discussed or considered valuable in this community but you can learn it like anything else in tech. The hardest language to learn is the one that communicates with people not computers.
- hutzlibu 6y agoToday I gave advice to wifes friend friend. Who wants to build something "like ebay or amazon". (but cannot programm and wants to contract) Well, after a while they understood, there is a small difference, between a website - and a virtual market place. Seriously, it is easy to forget, that for most people, all these technical things - is just dark magic in a black box. Which sometimes work and sometimes won't. And I find this sometimes hard to deal with, because society gets more and more technologized. At least a very basic understanding would be helpful.
- zebnyc 6y agoClassic buy vs build! Are you sure that they were not looking for a simple eCommerce site made using Shopify/BigCommerce? Maybe they are just looking for a side hustle.
- geoffbp 6y agoYep. buy vs build was a big change for our company, VP made the decision to stop building but the culture is ingrained and difficult to change.
- satyrnein 6y agoI find it useful to tell people around how many engineers that company has. They won't understand why, but they may understand that they don't understand. I also point out when a requested feature actually exists as a whole company.
- satyrnein 6y agoAlthough for some teams these days, the backend might be finished while the frontend team is still setting up their build pipeline!
- MBCook 6y agoWe had a hard and fast rule at my last job. ALL demos were either 100% real, or were mock-ups from Balsamiq. If it looked like someone doodled it on paper we didn’t have to worry it would be taken as working. We came to this rule after far too many incidents where some sort of mock up (Photoshop, HTML, whatever) was shown and taken as done. Then we got the questions (possibly unhappily) about where it was and when it would be done because obviously ”it must be” since we “showed it”. The rule served us incredibly well for years. It put a hard stop to all miscommunication. Everyone understood exactly where we were in the project. Either we knew what it was going to look like, or (if it was ready) it was done and awaiting their approval. Shortly before I left we got a new graphic designer. He wasn’t embedded with the programmers. He didn’t know THE RULE. Sure enough, we were asked why a design we’d never seen before wasn’t ready yet. Because he made a mock up in Photoshop. He told them it was a mock up. Doesn’t matter. We basically follow THE RULE at my current job. It still works wonders.
- Izkata 6y agoOur non-technical stakeholders are almost guaranteed to have some minor design thing they jump on, so our equivalent was to show them only things that were functionally done, no matter how un-polished. That way they were the ones blocking any release.
- bmiller2 6y agoAlways include a duck https://softwareengineering.stackexchange.com/questions/122009/developing-a-feature-which-sole-purpose-to-be-taken-out#122148 https://softwareengineering.stackexchange.com/questions/1220...
- benhurmarcel 6y agoNever heard that name, nice to know. We sometimes have to do that in technical reports. The proofreaders always feel like they have to give at least one comment, so you give them a clear mistake to point out to avoid useless debate over minor points.
- 6y ago
- dub 6y agoThere was an old look & feel for Java UIs that made them look as if they were drawn on the back of a napkin, specifically as a reminder that the code was a work in progress: http://napkinlaf.sourceforge.net/ http://napkinlaf.sourceforge.net/
- kutorio 6y agoA smart idea for the individual employee but terribly unfortunate for the company. Building cheap prototypes is a really good way to minimize wasted effort and gathering valuable feedback.
- LandR 6y agoI was on a call and the client said they wanted something added to a UI. So I very quickly used MS Paint to mock it up... Just so I could clarify that is what they wanted.I shared my screen and someone said "great, you've done it!". Even though I was clearly showing a screen that showed me editing a screenshot of the UI, in MS paint... MS Paint. sigh, they don't tell you in University that the biggest skill you will need in this job is patience and learning how to channel your inner zen. Developers don't need 3 monitors to get through the working day, they need regular sessions with a psychiatrist.
- beamatronic 6y agoIf you have a non-technical manager, quit your job immediately.
- coronadisaster 6y ago> just because you can see something, that doesn't mean it's secure I have yet to see secure software... does that even exist?
- zentiggr 6y agoSure - it's the one that's firewalls all the way down.
- colordrops 6y ago> They simply don't understand that the backend functionality is what's doing the bulk of the work. You say this in present tense which makes it seem like a generalization. This is also a mistake that non-technical managers (and others) often make. The frontend frequently rivals and sometimes exceeds the backend in complexity. It is very application specific.
- caymanjim 6y agoFair enough, although in the case of a complex browser-based application, the same problem exists. The "backend" is complex code that happens to run in the browser.
- aahhahahaaa 6y agoYes! I stopped building working prototypes because of this misconception.
- ianamartin 6y agoBest policy I've figured out as a developer dealing with product teams is demo everything in a command line until the backend actually works. No chance for suckass product guys to push if they can't understand what's going on.
- afterburner 6y agoI mean... are they dumb, or just playing dumb to bully you?
- hinkley 6y agoThe person who promoted them doesn’t care which, as long as they are consistent. I think we spend too much time focused on the trigger man. Whatever person in your org is making your life difficult, there’s a person above them who knows and hasn’t done a goddamn thing about it. Who is the real problem?
- 72deluxe 6y agoUgh but where does it end? I dig out my "The Dilbert Principle" book and will start reading it again to promote sanity.
- afterburner 6y agoI'll gladly blame the entire chain from the immediate supervisor/lead all the way to the top.
- holri 6y agoYes the incompetence in IT is astonishing. For a lot of folks IT is pictures that respond to clicks.
- rapnie 6y agoEven worse if non-technical marketing folks get their hands on prototype tools and use it to embellish the product with non-existing features in sales pitches without devs even knowing about it until after the sale. I've been there, and it is terrible. Also a vicious cycle as frustrated sales reps (by 'slow' dev progress in their perception) started inventing more and more of this stuff. A marketing + sales completely out of touch, chasing for bonuses. Brrr.
- deleted 6y ago[deleted]
- jariel 6y agoTo be fair, we Devs have a tendency to often overcomplicate, over-design, get caught in the weeds. It's not fair for managers to assume, but it's definitely fair for them to ask. And it's our responsibility to show and explain. There's the famous story of the first iteration of Gmail being done really, really quickly. The demo was the product. And then just iterations from there. Definitely a good model if possible.
- agumonkey 6y agoHow does this go ? do you explain frontally or do you just quit without explanation ?
- ownagefool 6y agoThis kinda swings both ways though. We've all worked with the perfect is the enemy of good guy who deeply considers all aspects, takes 10 times as long to deliver and then eventually, after much blood sweat and tears, delivers equally as bad software as the rest of us. Personally, I've gotten over myself and try to just ship it. That said, this is a bit different from the gnarly bug type scenario of the OP; though I'd probably ask how they wrote tests in 2 lines of code? :)
- arethuza 6y ago"They simply don't understand that the backend functionality is what's doing the bulk of the work" The truth is that in a lot of cases nobody has ever bothered to explain it to them. What I tend to find in a lot of situations is that managers often prefer younger and/or less experienced developers because they can be bullied - but the reality is that this also means that people are then unlikely to tell their managers what they need to know. Ultimately it is the managers creating the problem, but in most cases (mind you not all) the managers don't understand that they are creating a problem.
- zentiggr 6y agoI don't think there's much overlap between "managers who select developers who can be controlled" and "managers who are receptive to new ideas".
- tialaramex 6y agoA friend of mine who works in UX always uses literal paper prototypes. Not screens that look like doodles, but actual paper and cardboard and maybe some Blue Tac or paint. Ordinary users apparently behave very differently, because it's obvious that a piece of paper can be changed and they know how to do it so it only takes a little nudging to find out what the customer actually thinks the system should look like. She still has all the CS background to estimate that a change maybe that seems simple to the user just isn't viable, but using the paper prototypes encourages users to leave that to her and not second guess themselves into accepting a bad design because they're mistakenly assuming it would be hard to make a change when actually this is the perfect time to make such a change.
- Aeolun 6y agoI have the opposite experience working on the front end team. I get delivered API’s that are done. Then when I start calling them I get errors. Turns out done for them means they made a basic REST interface, but the API just returns mock data. Now my boss is happy that I’ve demoed API integration, but every next meeting he asks me why nothing has changed. It’s because I’m still waiting for something that is done. For some reason the fact that it’s not done is always the fault of the front end team. I’d love to get an actually finished API for once...
- bregma 6y agoTo a user, the user interface is the software.
- goostavos 6y agoI made this mistake the first time I ventured out onto my own and did some contract work. The thinking was that it'd be a nice way to give them something concrete to play with as we vetted the ideas / flows. But, as you describe, from a perceptions stand point, it was the worst thing I could have possibly done. It went from a very happy client, to a very unhappy and confused client when progress "stopped." I actually started recording development work as a way to make them understand all the invisible stuff which goes on behind the scenes.
- trav4225 6y agoAhh, yes. This is so common in my experience as well!
- mring33621 6y agoYes, very much like the time I replaced a getfakedata() method with a getrealdata() method and then management complained that it was much slower now.
- beckingz 6y agoMaybe print out the data to show them the difference?
- Kye 6y agoLesson learned: make demo functions slower on purpose so the real one matches or exceeds it. It's not even deceptive: you're setting realistic expectations instead of giving a false impression.
- pkilgore 6y agoAfter this (and a few emergent race bugs), I started burying the equivalent of setTimeout(() => getFakeData(), 1500) in my similar code. Best part is, I'm almost certain to beat 1500, so I've gotten compliments that it "feels snappier".
- mcbits 6y agoThis reminds me of the infamous Speed-Up Loop. https://thedailywtf.com/articles/The-Speedup-Loop https://thedailywtf.com/articles/The-Speedup-Loop
- LilBytes 6y agoI'm surprised I haven't seen this before, this is great.
- ioulian 6y agoAnd this reminds me about another story, I can't find the link but it was something like this: A game developer was making a game for PlayStation and they were over their memory limit. They were approaching a deadline but couldn't remove anything else from the game to fit it in memory (or disk, I can't remember). So a senior dev came by, changes the code in 1 minute and everything could fit into memory now. The thing was that at the start of each project, he had declared a variable of 2mb that does nothing, so when every optimisation has been done and it still doesn't fit, he could just remove that variable and free up some more space. It was also his way of insurance.
- ftio 6y agoEarly in my career, I learned a simple 'demo day' rule: never demo things that aren't end-to-end done. When you do, it can easily confuse folks who aren't deeply involved in your project ("haven't I seen this already?") and can hurt team morale because they never get a "shipped it" moment that feels good. More to the point: enforcing this rule incentivizes teams to build things in small, shippable components. Nobody wants to be left out of demo day multiple weeks in a row.
- klenwell 6y agoOn my team, we call this the "Jobs Rule" (i.e. Steve Jobs). As opposed to the Elon rule: promise the moon (or Mars).
- thayne 6y agoOr intentionally show them the rough edges. "Oh, oops it can't handle that input yet, let me try with something that does work."
- renewiltord 6y agoI currently do the opposite and I think it's the right way. Do the part that can provide quick validation first. Usually that's the front-end. You can find out if you're making the right thing pretty fast that way. What are they going to do? Fire me? I can go anywhere. They can't find me anywhere.
- webreac 6y agoFor me, the purpose of the "demo" is to get agreement on specifications and to remove ambiguities. This can also be used to reassure that the requirements of the client have been well understood.
- rado 6y agoOne of the most important lessons. It must be presentable, however extra effort and time it would take.
- nicbou 6y agoThat's excellent advice. I can see how demoralizing it could be to work on something you've already demoed.
- BareNakedCoder 6y agoHas happened to me too more than once. I usually reply that the UI prototype is like a Hollywood movie set: what looks like a real building is fake, just a single wall. The real building still needs to be built. That explanation sometimes works, often doesn't :(
- commandlinefan 6y ago> They simply don't understand that the backend functionality is what's doing the bulk of the work Even people who ought to know better don't understand this.
- deleted 6y ago[deleted]
- D-Coder 6y agoI seem to remember Joel Spolsky recommending that UI demos be done on paper... with pencil. That way even a manager can see what it will look like without thinking that it's all done. (Can't find a reference quickly.)
- WaltPurvis 6y agohttps://www.joelonsoftware.com/2003/05/16/20030516/ https://www.joelonsoftware.com/2003/05/16/20030516/
- baddox 6y agoNot even just the backend! Frontend interactivity itself can be very complicated, and it generally is not fully specified by design (do your design specs come with state machines?) A few things that are often missing from a Figma/similar are things like error states, loading states, handling longer text content than the mockup, and responsive design.
- Softcadbury 6y agoAnd you can add paging, empty states, accessibility, security, browser compatibility...
- RcouF1uZ4gsC 6y agoJoel Spolsky has a great write up on this phenomenon [0]. The opening paragraph is great: > “I don’t know what’s wrong with my development team,” the CEO thinks to himself. “Things were going so well when we started this project. For the first couple of weeks, the team cranked like crazy and got a great prototype working. But since then, things seem to have slowed to a crawl. They’re just not working hard any more.” He chooses a Callaway Titanium Driver and sends the caddy to fetch an ice-cold lemonade. “Maybe if I fire a couple of laggards that’ll light a fire under them!” 0.https://www.joelonsoftware.com/2002/02/13/the-iceberg-secret-revealed/ https://www.joelonsoftware.com/2002/02/13/the-iceberg-secret...
- bsder 6y ago> look at a UI prototype and consider that 90% of the solution Management tip: Make the UI reflect the actual state of the project. The UI should be UGGGLY and should get prettier as the backend work gets finished. If if the artists prettify it; make the animations and interactions janky and sluggish. Never make the UI better than the actual implementation. Bonus tip: Always have something slightly off in the UI that management can point out to fix. Useful managers will simply quickly point it out and move on to more important problems; useless managers will focus on it.
- dllthomas 6y agohttps://mamchenkov.net/wordpress/2012/07/23/a-duck https://mamchenkov.net/wordpress/2012/07/23/a-duck
- WorldMaker 6y ago"Sketch" themes or "xkcd" themes (named after the pencil look of the comic) can be quite handy for this. For instance, Bootsketch: http://yago.github.io/Bootsketch/ http://yago.github.io/Bootsketch/ I wish some of the bigger CSS frameworks would adopt sketch theming support as a "progressive" option, rather than the entire page all or nothing being Bootstrap or Bootsketch have the ability to add a "sketch" class to any element on any page. (Or maybe better yet, forcing sketch styles by default and needing something like a "final" or "final final" class everywhere, like the documents folder of someone that has never understood source control.)
- bob1029 6y agoThis is the best option. Creating low-fidelity UIs that prove the business functionality are faster to develop/iterate and provide an immediate signal to even the least technical individuals that the feature is still incomplete.