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.
Early 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.
Also, never use the word "done" in any context in a meeting like that. Do not even say: "I'm not done". They won't hear the "not". Say, "Development is still in progress" or something similar. I got chewed out for something being released (where it was found to be broken) to a customer because I said something like: "I'm about 80% done with testing, but I haven't run into any issues yet." They released it even though it wasn't ready, and both the customer and I found that there were issues in that last 20% I hadn't reached.
> Early in my career, I learned a simple 'demo day' rule: never demo things that aren't end-to-end done.
I take a different but similar approach when I run into situations where I want to get something small in front of a business user before it’s completely ready: I make sure it’s visibly broken in a way that doesn’t detract from my goal for the meeting.
For example: I have a registration form that I want to talk through. The state drop down will only have 3 entries, one validation error will always display, and on final submit you get a “failed” alert instead of a dummy page.
It lets me walk through the page and get whatever feedback I need, but it feels completely broken so non-technical users expect it to take more time to conplete.
While I agree, the feedback I get from a session like that is useless:
"While you mentioned this during the demo, I noted:
1. Your state-drop down has only 3 entries.
2. There is a validation error
3. You get an error at the end.
Yup, that'll happen, and if you omit it entirely you can get comments going "I'm not seeing this field!".
Would it be better to show no progress at all until it's completely done? I know agile methodologies tell you to demo regularly, but I'm more and more under the impression that they are to provide progress feedback / reports to management.
I remember someone suggesting using deliberately crude and hand-drawn looking UI elements in the demo. That communicates to non-technical users that it's just a prototype.
Honestly, that feels like a huge waste of your own time to game a broken system. And I'm guessing it is, but that it's a defensive move because the darker timeline is miserable.
What's broken are humans. For some psychological reason, a thing that looks unfinished gets much higher quality feedback than something that looks polished. There's no way around that flaw in people, so making prototypes look unfinished is something we have to do anyway!
Perhaps because “unfinished” offers stakeholders the opportunity to make major contributions, whereas “finished” means it’s already too late to make changes now so anything they do say will just be ignored.
Yeah it’s all perception, but cultivating the right perception is vital to effective, productive communication.
It's an example of the Doorway Effect: brains are wired to work in modes related to context cues. Change the context, and you'll change the memories and trains-of-thought easily accessed.
Polished things have a context of "use", not "evaluate", because we use so many polished things every day, but very rarely have any need to evaluate them (mostly only when we're buying them, or when a repair person asks us to describe what's wrong with them.) Whereas unpolished things are mostly "for" evaluating; it's rare that people use unpolished things (outside of, say, disaster-relief infrastructure.)
> For some psychological reason, a thing that looks unfinished gets much higher quality feedback than something that looks polished.
Does this really imply “humans are broken”? We all have limited resources and I think this could just be a first order prioritization mechanism. Of course one has to be aware of the bias but that’s a different problem.
it's not a way of gaming the system, but a way of prompting better feedback. For instance, in a Design Thinking process prototypes are more useful when they look rough/unfinished. A more polished piece of work might result in people being afraid to break things.
I use both approaches in my work:
1) demo small, tested bits during show and tells and any meetings where the point is to demonstrate progress.
2) demo large, unfinished and barely stable pieces of work when ideating, trying to figure out the next steps
2) is hard and works only if:
- we know what the unstable parts are (because we have tests, so we know the gaps)
- we know the audience and how much context they have
I've done this on quite a few occasions as well. It isn't necessarily time wasted, as you evoke a positive view from the client (progress towards the solution) and often get valuable feedback.
The alternative is that they think you are done, adding more pressure, and requiring more wasted time later explaining the mis-aligned expectations.
If hes talking about JavaScript an alert dialog is a single line of code so I dont think its that bad. Also as long as frontend and backend have agreed on what certain objects structures will be hardcoding shouldnt be an issue.
I don't do that. When I demo something I need feedback on, I demo the best version I've got. If it still requires work, I say so. This seems to work quite well for me.
Did you really get chewed out? That seems pretty much like a deal breaker for me. Managers are collaborators, not parents, and have no place talking to co-workers in such a diminutive manner.
Yes. He came to my desk a week or so after he okayed the release of the software and took me to a conference room. I don't know how long he chewed me out for because I was red with rage but too terrified of losing my job to say anything. I've experienced similar rage with only one other manager [1]. He was 3 levels above me in the management chain, I really liked the two above me (the test manager, as I was in test at the time, and the software manager) and the guy above him [0]. I wanted to stay with them and I had a good friend there as well. But I did apply for a new job a couple months later, and left by the end of the year.
It was my first professional development job and I learned a lot of things. One of the keys was this:
Your boss and employer are not your friends. When you promise something to your friends, you owe it without any expectation of reward or return. But your employer owes you something for everything you give them. If they fail to meet their end of the bargain, that's on them and you are absolutely 100% free to leave. That can be money, time off, good working conditions, respect, trust, or any number of things. For me money was not primary (though it is nice): I wanted a good work environment, interesting work, and respect. Fail any of those and I will be looking for an exit, even if it's just a transfer within the same company. But respect is first in that. A boss who shows little respect to his employees is not someone I want to be around. I had that boss who chewed me out, I had another that kept me doing busy work for a year and kept saying worthless platitudes like "you're important to our work, we can't do this without you" when everything pointed to that being false. He was just empire building and trying to grow his direct report count, but it hurt those of us under him because he didn't have the work (but he did have the money) to keep us there. (I was still relatively junior at that job and stayed longer than I should've.)
[0] The hierarchy was something like: VP of Engineering (several divisions below him) -> Chief of Engineer (Aviation) -> Chief of Software (Aviation) -> Chief of Testing (Aviation) -> Me; other production lines had similar chains below the VP.
[1] When she was my manager I quit, or more accurately transferred to another group. Years later, I quit my last job for several reasons, one was her. She was not in our division while I was in that position, but they'd just hired her on. When I heard the name I had to verify, when I confirmed it was the same person I was ready to exit.
Reading your comment reminds me of how sheltered and lucky I've been in my career. If my manager released something after I said I was 80% done with it I'd go have a talk with him about how "we" can avoid making that mistake again and what process needs to change to prevent similar errors.
If he tried to chew me out, I'd just say "That's not how I remember things. I said I was 80% done, and, frankly, it was a mistake for you to pull the trigger on the release without confirming with me first."
Yeah, I'd have the same conversation with my manager and she'd apologize. I don't think you have been lucky, such a reaction is just a normal adult civilized reaction.
Well, that gets to my other lesson: Save money aggressively so I'm not beholden to any employer. It's harder when you're taking care of a family on one income (and not making FAANG money), but I saved aggressively when I was young and single. I never actually had to use that option, but I was in a position where I could have lived (as a single healthy guy with no debt) for 4-5 years without needing a paycheck. I wouldn't have lived well mind you, it would've been tight to stretch it that far, but it was possible. My main mistake was putting too much in my 401k. I'm set when I retire, but I still don't have enough assets to get me to retirement.
This works even when you're on a visa, but can take longer to be truly comfortable. I had a classmate in college who'd secured a work visa. His plan was to work for perhaps a decade in the US, save aggressively, and then return to his home country. Salaries in the US were 10x higher at the time than in his home country. Saving even 20%/year meant saving 2 years' of income every year he worked. And he was frugal enough to save a lot more than that. Invested well, taking what he learned back home, he would be set for life at this point (I didn't stay in touch so I only know the plan started well, not how it turned out).
Look up the 72(t) rule relating to a 401k. You can retire early and start withdrawals at any age without penalty, as long as you continue the withdrawals for sufficient time (the longer of five years or until age 59.5.) This fixes the "too much in the 401k" situation.
Yes, but you don't have to spend it all. You could take just what you need to live on and invest the rest elsewhere. You'd give up some of the tax-deferral advantages of the 401k, of course.
(Perhaps you could roll over part of the 401k into an IRA first, and then take the rest as 72(t)?)
A 401k is specifically a retirement account - you pay an extra 10% for withdrawing from it before age 59.5, which should add context to the rest of their paragraph.
Look up the 72(t) rule relating to a 401k. You can retire early and start withdrawals at any age without penalty, as long as you continue the withdrawals for sufficient time (the longer of five years or until age 59.5.) This fixes the "too much in the 401k" situation.
Less than full liquidity. If you get a decent matching contribution from your employer, it's probably worthwhile. Otherwise, it may be kind of a toss-up.
At a minimum, you should save enough to your 401K to get the company matching.
Let's say the company match 50% on the first 6% you save.
So if you put 6% of your salary to 401k, the company will add another 3% in addition to what you did. That's a free 3% raise.
Tell me another way that you can get guaranteed 50% return of your money.
In addition, there is the tax advantage where you do not get taxed on your money until you retire. So you money grow without taxes until you actually need them.
Are there bad 401k? yes, but I think very few. Check the rules of your company. But most of them are very good deals and you should take advantage of them if you can.
> He was 3 levels above me in the management chain, I really liked the two above me (the test manager, as I was in test at the time, and the software manager) and the guy above him [0]
I happen to get along really well with the person three levels above me, but I can't imagine dealing with getting direct negative feedback from him. Honestly, more of my conversations with him over the years have probably been about things unrelated to work than work-related; we don't just hop over my direct manager and his boss unless there's a really good reason for it.
Parents are not supposed to talk to kids the way chewing managers talk to people. Also, business oriented managers are not collaborators in my experience and take such idea as offence.
And yep, I was actively avoiding that environment too.
One thing I learned very early in workplaces where there are "project management professionals" is to NEVER to casually mention even the implication "dates" and "completion" anywhere near each other.
Someone is bound to jot that down and interpret it as a hard commitment regardless of any other details or conditions.
In a company that understands and embraces agile software practices, this works well. You demo small things that are done, and prototypes are understood as just mockups designed to drive future work. Alas not everyone in power gets it. In more egregious cases, I've been in adversarial environments where teams were pitted against each other to appear "more done." Obviously a recipe for failure. I'm fortunate enough to be able to be more selective in where I work now, and have the experience to drive the choice.
I've come to realised this, "true" agile is more like being funny and smart(not that I am either). If you have to tell people you are smart or funny, you probably are not. Ever noticed how smart people(the really clever ones) are just absurdly smart without walking around telling everyone "hey I'm smart", usually the nicer they are the more intelligent they are(yea you get exceptions), same with funny :)
I feel it goes double for "agile-processes" if you have to walk around and tell everyone (management or interviewees how agile your process is, it's probably not)
It feels like "agile" is such an overloaded word these days. In most settings it just means a specific workflow centered around Scrum or to a lesser extent Kanban. The only true difference from old school waterfall and month long specs is shorter iteration cycles. A "sprint" or "iteration" is still treated as a rigid block of work.
On the other hand if you have a look at the original Agile Manifesto[0] it is a different beast all together. It specifically seems to go against using set processes altogether and basically boils down to nurture organic communication, to adapt and focus on getting shit done.
I suppose the "agile" in the former sense is a compromise to edge closer to the latter, while still maintaining a familiar corporate structure.
That's...a great point, actually. The most humane (and incidentally, agile) workplaces I've met didn't mention agile much: "yeah, we do this and that, we just want to have a sane environment."
The places that went "we do all the agile incantations in the book, because that's the only way," well, those actually had a scrum-o-fall culture.
Yeah, but there's a big difference between working on a TV show that's meant to be a comedy where people are trying to be funny, and working on a TV show that's meant to be a drama that isn't a parody. Both might have the same "actual goal" of trying to get good ratings, but if you're trying to put jokes in the show that's meant to be dead serious because you mistakenly thought everyone in the writer's room was trying to be funny...
If you want to be working with a team trying to be funny, at some point you have to use the word "funny" and "comedy" to make sure you all are actually trying to do the same thing. And make sure the producers and show runners agree that it's a comedy you're making.
There's no greener grass on the other side.
I've been in the big consulting business, and sometimes you can't get a client to schedule a meeting for months, so you're flying blind, with absolutely no feedback.
And then we go into the typical cycle of "Lessons Learned" etc, because what you've developed is irrelevant to the client.
That's a funny comparison to demo days early in my career. The company I worked at had too much upper management that would hijack dev teams to make "cool" features constantly. We only had to make something good enough to appear like it worked in a demo though, because then that upper manager would get his bonus or look good to the CEO or CTO and we could move back to doing real work.
I'm still conflicted about this. On the one hand I agree. On the other, I wish we could educate people enough for them to understand Proof of Concepts and Minimum Viable Products.
It depends on the audience. A customer demo is different than an internal demo, and I assume you are referring to an internal demo.
You must demo the product in a form that leaves the right impression of the current state. If you are painting a picture of a polished product, expect polished expectations. Instead, show the bugs and say "we are still working through this section" Show missing pages, show your work in progress. Show wrong colors. Show potential, wave your hands and tell them to imagine this part working. Don't fake it. If that feels wrong, then a demo isn't right.
If you show it in a form that looks complete and polished, even if you say it is not, how can you expect any other conclusion from the viewer other than "it's practically ready!"?
Great point with the visual appearance: show what you currently have, just include ugly.css. People are wired to understand Comic Sans and hot pink on green intuitively.
I can only agree with that. It is kinda just being honest. I don't know from where come this idea to showcase our work better than it actually is. Is it our own ego, showcasing unfinished/buggy work making us question our competency? Is it the fear of getting negative feedback because it is buggy and unfinished? Is it deeper issue, society making us believe, that what counts is superficial (apparence) way more than it should?
There is a reason that teams with mostly non-technical leadership deliver broken software as your choices are feature driven architecture with absurd glue or being asked "why isn't it done yet"?
This doesn't require that things fit into a single sprint. It just incentivizes teams to ship their work in smaller chunks.
If it helps motivate a team to divide some four-sprint piece of functionality into two shippable chunks that each take two sprints, I'd call that a win. Customers get something a bit faster even if it's not single sprint-sized.
Reiterating what gp said , not all dev is like that, lesser you are doing IT and more comp science or any unfamiliar territory really it is harder to break down ahead of time .
Many times I can’t tell you what tasks need to done let alone how much time is needed and break it into smaller chunks during planning phase.
If planning has to work you should be familiar with what you are building , with poor information on the bug/ code / stack planning agile is just useless overhead . it works great for yet another CRUD app where you know the requirements to the dot and know exactly how to build or fix not always , most management fail to differentiate
All the reasons in the TFA are also why it is hard to estimate , what and how much time will take .
When you’re doing exploratory work, the discipline of stopping, examining what you have learned already, deciding whether the goal still makes sense, and correcting course and reprioritizing seems even more important to me. You don’t know what you will be doing more than a few days ahead? Then your sprint length should be a few days and at the end you recombine and replan.
I mean obviously this only makes sense as a way of organizing a team who are trying to build something exploratory - that’s what scrum is meant for. If you are trying to pursue a solo research project within a team the rest of whom are doing scrum then... that’s not a problem agile can solve.
It is not just only research that is exploratory, even the kind of bug fixes the article talks about can be hard to predict. replication of an issue or understand a new module can be uncertain, race conditions or data specific issues are uncertain too.
Identifying and solving something similar to [1] with a team is not simply possible when you plan with agile. I am likely going to go the next item once I mitigate the effect without bothering to dig deeper just because someone is clocking me on a timeline I committed.
It kills all the joy and fun, work becomes boring, this is by design, it is hard to run an organization unpredictably. If only management trusted you to deliver without looking over shoulder constantly ( when the situation warrants it)..
It is not only a engineer's gripe, it applies to management too, the board/ market forces them to be very short sighted, unless you are musk/jobs/buffet it is hard not to buckle to market pressure and invest in longer term opportunities.
The point is not that planning is bad, it can do a world of good in many including unpredictable situations, it is more that blinding pushing a framework especially agile because it worked somewhere and everyone says so, or the manager can't be bothered or won't risk doing something different as the situation warrants.
Ah - you’ve been subjected to management-by-scrum. I am sorry.
Scrum is a collaboration hack for creative problem solving teams, not a managerial accountability tool. The version of scrum where stand ups are for checking on the team’s progress and velocity is reported on up the org is using the tools of scrum to solve a very different problem than the one that it was designed for.
I’m sorry you don’t believe it’s possible but I can tell you from experience that it is possible to use the processes of scrum and the principles of agile to help a team collaborate on open ended creative problem solving tasks.
Maybe it's finally time to give up on Scrum. Whatever good intentions the original inventors had, whatever idealized situations it may work with perfect unicorn teams, the general experience in the wild of this benighted framework is a tool in the hands of mediocre, inexperienced managers to micromanage, infantilize and monitor developers. It's essentially warmed up command-and-control Taylorism with some feelgood buzzwords and neologisms thrown in. I would even prefer the old horrible Waterfall approach, at least we didn't have all the endless, pointless groomings, standups and retros to attend along with the "we so agile" gaslighting.
Not to put it bluntly but you can not do even small bits of work in 2-3 weeks?
Sometimes your demo is nothing more than 'here it is in the log doing xyz' or 'I added this thing to this config file'. Not all demos are big flashy ordeals. The team I am on right now most of my demos look exactly like that. I can usually do them right after the standup. Our team allows it because we are mostly remote and talking to each other helps.
I personally use scrum as a weapon to make sure management does not overload our teams. Those made up story points are a good way to say 'you have tasked us with 4 months of work in 2 days'. You have to know your manager too. You have to talk to them. Know what they are looking for. Some take a very hands off approach. Some want the nitty gritty details. For both of those a 'oh that is going to take 3 months' may sometimes work. But it does not give them actionable items to help you. The task broken down into some sort of chunked out work does. Sometimes you do not know. It is OK to admit that. That is when you make a discovery story. Make sure they are onboard with that story is to help you find out what is needed. Even then you will still learn along the way.
I worked with one guy who wanted to task things down to 15 minute increments, 6 months from now. He kept failing. Because he was being too narrow. He refused to do story points. Because they were 'stupid' yet management kept piling more stuff on him to fail at. He was in every weekend and in until 9PM every night. Because he had no tools to push back. Give your management numbers and actionable items or they will assume everything is hunky dory.
It's an anti-pattern to simply not demo any progress until done. If you're doing agile right (loaded statement), the solution is to make sure everyone understands what's being done. If the audience is expecting all demos to show complete products, find a different audience to demo done-but-incomplete work. The idea is to get feedback before you've sunk six months into something that may not meet expectations.
Yeah, I could've been more precise about what I meant by "demo day." In my comment, I was thinking about the broader, often companywide demo days that many companies hold.
I wasn't talking about intra-team demos to, say, product owners.
I totally agree. Having weekly demos where we showcase unfinished features has been, in my experience, one of the main avenues where we have learned of issues / conflicts / problems with those features at exactly the right time where we could still fix them.
Not having demos of incomplete features would just hide the issues until they are released to the final customers, creating a problem you didn't have before, and making it much more complex to solve.
Progress gets quantized. Some quanta are small, easily shown, etc... other quanta are a bit bigger, less easily shown.
There is a similar problem in manufacturing.
Atomic releases.
While making something, there are many subtle tweaks to the BOM. Changes, substitutions, removals, adds.
Upstream people can make a real mess out of all that, and one way to prevent it is to only deliver releases that are resolved and intended for manufacture.
"where is revision 4?"
Doesn't exist, won't get manufactured, etc... "Use Revision 5 plz."
For the case of insuring expectations get aligned, a mock up can be used. Deliberately used to generate a spec.
People can hide the fact that they have a big ball of mud fir a very long time, and they only want to talk about improvement after hunts have gotten miserable.
4-11 years depending on exactly what you'd define as "brownfield"
> People can hide the fact that they have a big ball of mud fir a very long time, and they only want to talk about improvement after hunts have gotten miserable.
True but beside the point. The same point stands: you can always find a way to make a worthwhile improvement in two weeks - something that's useful on its own, even if it's also the first step of a much bigger improvement plan.
Unlikely. I used to go looking for tasks that couldn't be broken down; I'd get excited when someone would claim that their task couldn't be broken down. But they always could, and it was never even hard.
My task is to implement a model that takes advantage of unified field theory to simulate arbitrary bodies in spacetime, first the mathematical models behind it need to be created then implemented in software.
> My task is to implement a model that takes advantage of unified field theory to simulate arbitrary bodies in spacetime
Sure, sounds straightforward enough. Start with simple cases (e.g. universe is a unit circle), you can definitely implement useful pieces within two weeks.
> first the mathematical models behind it need to be created then implemented in software.
The problem with this is that to produce quality, you actually need iterative feedback from stakeholders and users/user representatives. If you don't show anyone anything until it's "done", you are doing work in a direction that would have been better informed by more feedback.
(Cause another lesson is that people have a lot of trouble giving worthwhile feedback on a verbal/written description of something, they gotta see a thing in front of them).
But I think that's still possible. For example when testing a new idea that just takes some months, it's pointless to show an alpha version where half of the buttons create error messages - even if it solves a much more valuable problem and these errors could be ignored. Instead one should make a presentation of a mockup or a screen recording how a single feature will work. That's much more digestible for everybody and gives far better results if the one watching has anyways only 3 minutes time.
> Early in my career, I learned a simple 'demo day' rule: never demo things that aren't end-to-end done.
I've learned this adage years ago (I think it was from Spolsky), but nowadays I'm in a project (re)building an UI from scratch as a sole developer aaaand I made the same mistake.
I was doing some UI prototypes about activating a process, big green Activate button, opens up a confirmation dialog, spinners with some artificial / simulated delay because I didn't do the back-end, and it caused confusion with our tester because she was wondering if activation actually works.
I've got three options; remove the button for now (I should do that), partially implement the activation (changing a status in the back-end), or fully implement the activation (which has a lot more prerequisites).
> Early in my career, I learned a simple 'demo day' rule: never demo things that aren't end-to-end done.
I've learned the opposite. If I communicate clearly that what is being shown is little more than a mock-up, executives of all levels and technical skill, all the way down to managers just above myself, all understand that a very thin and scripted demo is not anything close to a finished product.
Describing the demo as a "house of cards" that will collapse with a single misstep gets the point across nicely, while also giving the demo audience an eyeful of what can be accomplished if everything is handled appropriately.
Demos are carefully scripted and rehearsed, values are hard-coded, and absolutely nothing exists that does not prop up the demo for the purposes of the script and the talking points.
It is hard to describe to someone who hasn't written an application demo like this just how little actually exists behind the UI.
Anyway, my point is that if you choose the correct words, anyone can understand that it's like a painting of an application, and not an actual application, just like a painting of your mother is not actually your mother.
For 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.
I 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.
I 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.
We 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.
Ah yeah, I had a marketing/sales friend who did that the other way around: he made nice mock-ups, he even built powerpoint presentations that seemed to show the UIs actually working; he made credible ads and sales documentation with it, and he sold countless non-existing snake oil products this way ("available soon!").
As he simply was the marketing/sales guy, in case he found himself cornered he could always pretend that the failure was on the dev/technical side... "see with the support".
He could also successfully sell himself this way: once a billionaire proposed him to be the sales director of some company. He set the meeting at 7AM at the Ritz bar, and got the job (not for long : he had negotiated to keep the perks when leaving anyway).
For mockup images, you can use an unmistakably prominent watermark.
Superimpose the word "MOCK-UP" in a gigantic font that takes up nearly entirely the image.
Make it translucent and red or make it black outline. And maybe tilt it diagonally to catch attention and to make it easier to visually separate it from the rest of the image.
To streamline the process, you can just keep an image like this around to import as a topmost layer into other images.
I’d like to pick your brain on how you got this started. My current company seems to run into this problem occasionally, and we use Sketch for a lot of our UI designs.
I was there at the time but to be honest I don’t remember exactly. I know that we used to use Photoshop for mock ups. I think one of the other developers found Balsamiq when they were looking for something that would be less work and we found the side benefit that the doodle looking mode prevented confusion.
Whether we realize that immediately or only after we stopped having misunderstandings I’m not sure.
But once it was realized I don’t think it took very long at all for it to become a rule. It made life so much easier for us developers.
Our 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.
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.
If you can do it that sounds like a very good strategy. We needed to be able to show mock ups of what things WOULD look like before we even start at the project so that everyone was on the same page. So we couldn’t develop functional prototypes or full working implementations to show.
And 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.
There’s an episode of “Star Trek: the Next Generation” where Scotty, the engineer from the original Shatner Star Trek tells the next-century engineer LaForge that this is how it’s done. You never tell the captain all that you have so you keep something to squeeze at the fatal moment.
This is sound advice from both technical and nontechnical perspectives. I like to use this middleware in node to inject semi-realistic delays in my mock data: https://github.com/boo1ean/express-delay
A lot of people are building big systems these days and in many cases we have a guess at what is a reasonable amount if time for all of the steps in the process to take if we want an answer in 600 ms.
While your trick makes you look good, setting the times to match the budget might be more honest. And when the app slows down you can blame the people who take 250ms to do their part when we agreed to 100ms.
Really? Our 95th percentile only goes above 1s when we are having problems, and nobody with any power in the company thinks that's good enough. Think about how much hardware capacity you need for a site getting even 100s of requests per second. If you can halve the p95 you can decommission or re-allocate close to half of your servers.
As several other people on HN have pointed out more eloquently, it's the variability that kills you faster than the average throughput.
The 100ms was not about end-user response times, it's referring to internal response times between servers. To make a page in 1 second you can't have 3 different services taking 700ms to respond, even if you can make all three calls in parallel. And if you have to call a bunch sequentially, you need the 75th or even the 95th percentile for those services to be pretty good otherwise your 95th percentile for the entire interaction will be very spiky.
Lesson 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.
> 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.
This 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.
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.)
Joel 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!”
Today 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.
I 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.
I've started doing this too. The director of the company I work at is non-technical and will semi-regularly come to us expecting that we can build a competitor to Product XYZ in 6 months.
Pointing out that Product XYZ has 3000 employees and has been carving out a niche since 1995, while there are six of us with no knowledge of that market, is usually the only thing that gets him to accept that just because he understands what something does, it doesn't mean he understands what it takes to build it.
Ah, the eternal temptation: "but that's Easy! I can tackle this single-handed! produces a minimal, text-only prototype which scales enough for a couple thousand users"
There doesn't have to be a difference, you can throw up a static list of items with price descriptions and a number you can text to purchase things.
This is how we used to sell drugs in college. It was a simple URL you could go to with pricing and you just sent texts to a burner phone to arrange a transaction.
Yeah, this would be a website. Maybe ok for one primitive shop. And for webshops there are tons of frameworks, also possible with reasonable amoumt of work.
But a virtual marketplace .. where different actors make transactions, is a different story. Consider you have a bug and people loose money because of you. It really needs to be solid.
Has 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 :(
A 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.
I 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.)
"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.
Not 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.
There 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/
I 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...
I 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.
You 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.
To 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.
> 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.
Fair 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.
I 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.
Yes, 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.
Even 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.
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? :)
The 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?
I 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.
Except 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.
A 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.
Don'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.
