Keynote: Lies Developers Tell Themselves - Billy Hollis - NDC Minnesota
Vložit
- čas přidán 21. 11. 2022
- All humans sometimes deceive themselves, and developers are no exception. From "I can get this done in a week" to "My job is to write code", developers often convince themselves of things that are only partially true - or even outright ridiculous.
These seductive-but-false notions are factors in everything from poor software quality to unnecessary stress on developers and other team members. In this session, developer/designer/architect Billy Hollis will bring out his top ten uncomfortable truths about software development, with some humor to make them easier to hear. - Věda a technologie
It’s uncanny (and unfortunate in some ways) how accurately this describes my own thought processes and career as a developer. So many good takeaways from this.
"There is no wrong answer. This is a test of character. Because whatever answer you give has to be in connection with reality and honest" - 9:30
I know it's not the main point of the talk, but I've been straight up saying the fighter jet thing about all modern cars for years. Touch screens don't need to be everywhere, least of all in human controlled vehicles! Drives me nuts!
I would even say, touch screen is the worse possible interface one can have, unless it is used directly to influence the screen or the thing that is on it. To operate anything, especially blindly in short amount of time or under stress we need physical feedback, also we have to be able to find out the operation handles by touch and be able to feel difference between them. Touch screen is fine where we have time to look at it and recognize pattern fully and then act. Try to call current smartphones blindly or without using the voice control... it is impossible.
And at least for Kias, they even hard-labeled the touch buttons. What is even the purpose then? I'm crying, but happy that my eNiro still has physical buttons for exactly this reason.
I like Billy’s talks. I like this one too!
It is worth sharing to all developers, tech managers, business managers, etc. and even those new devs in the industry.
Thanks for the great presentation, Billy!
"I can get this done in a week" - When my boss ever needed a quote from me for an offer, I doubled it. Then he TRIPLED my already doubled quote... and quite often that meant very very busy six weeks for me.
I used to designing + coding + talking with the end-users. Not exactly an easy job, but very rewarding in the end.
I knew an HP software engineer, supervisor for a DoD contract, confide to me that he worried that he lost the ability to code. I really hadn't imagined that, and still find it difficult to.
"What is the weirdest bug you've ever encountered?" I am impressed that someone could even answer a question like that. I mean, maybe if you had lots of examples jump to mind, you could just pick one and it wouldn't have to be the weirdest. But just being able to remember something like that in 10 seconds or less without having prepared a story is impressive.
I can only remember bugs that I wasn't able to solve. Solved bugs are gone.
Not a fan of that question. He likes the question because he has this war time story about his false-dialog he want's to tell. But i now needed 5 minutes to remember that time i debugged the Quarkus OIDC extension code to find out why "randomly" users got a 403 error, which was the result of Quarkus filling an unordered list of OIDC providers based on some race condition during startup. And because the application was running in 6 instances, it made it seem randomly depending on to which instance the request was routed and what happened during the start of each instance. That issue showed up constantly for months before i joined the project as lead architect (some microservice projects do have architects doing actual architecture stuff) for 50 developers and fixed it in a couple hours, so kinda an achievement and not part of my daily job and it happened only half a year ago and still i had a hard time remembering it without somebody staring at me in an interview situation.
Yeah, I also wasn't a fan of the story:
"A dialog box stating 'false' popped up randomly", it wasn't random, it was a very specific popup that showed up in a specific scenario. It was a scenario in which a popup was expected, just one with a different text.
I was immediately thinking of how I would solve the situation he described:
start the application, continue working on something else: To see if it was something that actually was random (as was in the bug-report sent to me. Especially given how others couldn't solve it)
Conclude 'no' as it wasn't the described situation would only occur when a popup was expected (just not clear which one)
follow it up by going to customer-support, where the original report likely came from, and ask if they had info on scenarios in which this occurred, and pin down the correct popup from there.
To later hear the 'random' was 'greatly exaggerated' I would conclude, yup put this guy on the 'partial sales, partial dev' consultant-team.
Plant
a better question which is more general and easier to answer would be the standard "tell me about a significant technical challenge you faced and how you dealt with it"
What's sad is this isn't really an "individual developer" problem - this is often a company-wide culture problem. Corporate leadership loves to be the tone-setter in diabolically bad estimations, including advertising to customers and the public before any engineer has vetted any timeline or work scope.
Seeing the length of this video I was like "I am NEVER going to watch it through to the end" and I said that to myself every 10 minutes into the video, until I finished watching it to the end.
🤣 same for me
One evening I had this great idea, while drinking beer in a small pub. I just had to go the front desk at ask the bartender for a pencil and some paper. I got them, I wrote down the fuction headers (C code) for this idea I got. The next couple of weeks I spent writing the bulk of my idea as proper C code. And I still think it was my best idea ever.
You wanna knw what my great idea was? Just ask.
I'd like to know. What was your idea?
Good talk; I really enjoyed this
Having such a great presentation helps to make software developers grow instead of having them go the expert beginner path. Thank you! 🙏
this was a great talk
Removing project managers from SDLC really helps with the first one.
Righting Software by Juval Lowy, is one of the best books which I've ever read. When you finish it you will start thinking not for functional decomposition, BUT decomposition based on volatility which is something totally different!
I'll be seeing Juval at a conference next week. I've known him well for about twenty years, and agree with your assessment.
Greetings from Bulgaria for Juval! He has fans here and his thoughts about volatility based decomposition are remarkable! I hope I'll be able to attend his classes :)
I also enjoyed reading the book "righting software". I like the idea of Domain-Driven Design. When I read the book, I thought there are some similarities between decomposition based on volatility and Domain-Driven Design. I don't know if you would like it but I recommend the book "Learning Domain-Driven Design".
If I explain why I feel those are similar in detail, you can categorize your system among core, generic, and support. The core subdomains are used to have higher complexity and are expected to be the most volatile. You also need to go through processes to figure out how to decompose systems based on volatility by questioning and analyzing them. I felt finding Ubiquitous language with domain experts and boundaries are pretty similar at the core.
I really appreciate that Juval Lowy shared his knowledge with the book. It is really helpful for me and I can learn from it and give me a chance to think of systems in different ways!
Thank you for the nice presentation too! Billy!
Thanks for the reference,will check that book
That bug would have been easy to spot.
Good talk, I will be reading righting software. The 'don't try to be cool' and the 'be innovative' points are in tension with each other
They are indeed in tension. The "don't try to be cool" point is about forcing something perceived as cool into a design when it doesn't fit. So trying to be cool should never be a driving force. Innovation and good design should be the focus. If that turns out to be something cool, so much the better.
@@BillyHollisUX oh, thanks for replying and clarifying! Makes total sense
Rule number 4: the feature they don't know they will need... it comes after rule number 3: the feature they are insisting is essential will be the first one they ask us to modify or remove
36:00
That's a tough one,
As most people can't speak at the speed of thought. this is practically guaranteed to happen.
'mind wanders off, thinking about things' will happen
whether that thing is related to the thing being said, or whether there's also listening going on, that's harder to tell.
The amount of times I've been accused of 'not listening' because 'I looked like I was also thinking' (I was), I lost count by the age of 10 basically.
My response when anyone actually bothers stating that accusation, is thinking for a moment whether I should lie and agree to save their ego, or give the honest answer of 'here's a bulletpoint list of everything you've said thusfar, here are the ways they are related, here are the action-items I took away thusfar, here's where I expect the real point is still coming/where I would ask 'which of these things were you working towards/do you need me to do?' if you were to end the conversation here'.
As the overlap between 'people who feel comfortable stating such an accusation (in public)' and 'people who would accept a public display of 'your accusation is factually incorrect and you aren't as much _smarter than everyone else_ as you like to pretend that you are' ' is very small.
I see the loop of:
- I can trivially keep up with everything you're saying and still am basically waiting for you to continue talking (so I start thinking about other stuff as well)
- I think I see, I only have half of your attention. Let me slow down to accommodate.
(with increasing frustration on both sides)
on practically a daily basis.
@NDC It would be useful to put the year of the event into the video title and also on the video thumbnail
It's also confusing that the start screen says "Inspiring Developers since 2008" 1st, then the actual year of the talk comes 2nd, with the exact same font size, no emphasis whatsoever.
No meeting lasts 90 minutes "because there's a lot to explain". It's because bosses have a captive audience and are addicted to the attention.
coincidence is that this is in Minnesota and I did the dynamic validations for an insurance app in Minnesota But that was the first time I ever did that
About "lie: business rules go in code". As a programmer (disclaimer made :)), I highly disagree with the author. For several reasons:
1. from my experience, non-programmers really struggle with defining rules (eg, programming the rules), even the simpler ones and even with DSLs that would simplify.
2. Tthe author talks of "complexity" of code; it is likely to be also considerably complex in non general purpose programming environments/DSLs. For example: pick some random web project and try to understand the CSS rules associated with it. Now imagine that you have to change something or add a feature using some existing pattern. Good luck :) (and CSS is not as complex as business rules)
3. If a DSL is used to simplify the life of the (non-programmer) user, there will be rules that simply aren't definable in the DSL domain. If the those complex rules are possible, there is a high change that is not a DSL but a general purpose language
3. Users will fail defining the rules, since everybody make mistakes. Debugging every business rule engine that I'm aware of or can imagine is pure simple pain
4. To many dynamic changes may lead to undefined behaviour. No one really knows the rule at the time something happened. I'm willing concede on this one
Yeah, I also have the same thought. In fact, there are 2 anti-patterns called Hardcoding and Softcoding. So NOT ALL business rules should go in code, but also NOT ALL business rules should be softcoded. I find a bit concerning (possibly due to limit time of the speech) that the author has not defined what should be considered static or dynamic rules (and therefore, should go in code or not) and how to do so (which can be hard and requires end-users pov). And even from my experience, part of the dynamic rules would still need to be in code.
I think the best direction is for developers to learn how to organize the rules in isolated places. You don't want codes of dynamic rules to mingle in the same method with static rules. You want codes of dynamic rules to be in the place that is easy to read and easy to change, and if circumstances evolve, you can bring part of the rules into user inputs (softcoding them). Simon Painter's video in some way illustrates it quite well: czcams.com/video/0ial6pfgV9g/video.html
You didn’t understand the talk. Business rules start at “our company logo is X” and our primary color is Y. When the company changes the logo and color, they need to talk to an engineer. This talk has nothing to do with DSLs or Visual Programming - he is talking about taking business requirements point blank and putting them into code, instead of sometimes giving agency to the domain owners. Be it replacing a logo without a programmer, updating help texts, configuring the validation logic of acceptable data input. The best solution I found is to teach people github. I have laywers working along side engineers to update legal copy via pull requests - but that text is extracted to markdown files and not hardcoded into the apps. Slight inconvenience for engineers; not everything needs to be an admin app or database. Not that hard.
100% in agreement. If the business rules are "dynamic" and configurable by users, without any testing, you're going to go out of business very quickly. And then my company will eat your lunch because it has an engineer in the loop who's familiar with logic and common pitfalls and who has version control and testing infrastructure.
Not to mention it's a more expensive way to do things. To anticipate every dynamic business rule and build a system that can interpret the user input and react based on that takes WAY more time than looping in the engineer when a change is needed.
I think the main issue here is that what author meant by that and what e.g. I would mean by that are different things :). So in the author's case it was perfectly valid to put the validation rules for their system into some external config in a database (or something similar) because they had tons of them than changed rapidly, but it doesn't mean that you should do that for stuff that doesn't change often.
So I think what is actually true is that programmers tend to resist allowing to put too much logic into config because of the issues you described, however sometimes it's the right solution. I think a good example of the same thing would be embeddable scripting languages in games, such as Lua. It allows game designers to focus on what they can do best and iterate quickly (because it's a scripted language with a lot of bindings to the engine), whereas the engine developers can focus on the actual engine and not hard-code any game logic (or hard-code very little), and everyone wins, because engines are typically written in C++ which takes ages to compile and recompile.
I admit I don't understand comments like this. My team has been designing and writing systems in which rules are external to code for decades. Some of the most valuable systems we've written are in that category.
I don't understand why you would think capable users cannot understand and set a rule that says "For Customer X, the value of this field must be between A and B." In our rules-driven systems, it's common to write a "rules designer" that helps the domain-knowledgeable users put in the rules, and automates the testing of the rules.
I was at a conference a couple months ago where the lead for a team at a major company (whose name you would recognize) told me about his rules-driven systems. So I'm not the only one. He discussed how such a system saves money and helps the business be more responsive over time, and they were able to keep their software responsive to constantly changing rules with a very modest staff of developers.
So I'd suggest reconsideration of your position. It absolutely can be done, and it can be immensely valuable to a business.
You might start with this: If, in your experience non-programmers struggle with defining rules, perhaps the rules framework needs to be better designed, and/or a better rules designer is needed to give them the assistance they need to manage the rules. But don't just give up on the concept because you've not seen it done successfully.
Vasco Duarte's research disagrees with estimations.
49:00
Another tough one.
Is the 'there is basically only one good way to do things, and it is ours'-statement something that should either be ignored or considered reason for skepticism? Absolutely.
Is it also located on [the location reserved for the sales-pitch], anything put there should either be ignored or considered reason for skepticism? Also yes.
"AI will not take my job, it will just make me more productive!"
Ok, I'm going to correct you this time. The reason the failure of the F-35's were reported was because all the news organizations responsible for vetting their sources simply parroted a sensational clickbait story that did not actually support its own headline statement. The DoD has admitted design flaws, but not a failure because F-35's do what they were intended for, which wasn't to replace F-16's. It's a completely different type of fighter, one that attacks from over the horizon rather than close range combat. F-16's can't do that, F-35's do.
From 30 years in this business I see where the failures of agile comes from: ots simply that software projects is hard and incompetent management makes it fail, whatever process is used. And agile is a bit fragile in that it only works if the rest of the organisations really allows them to follow the process: if they really dont get impatient and issue new work orders during sprints or constantly destroys the team by moving people around.
Oh, I know. I started as a COBOL programmer, and the mainframe was 200 kilometers away from my terminal. When I needed to compile a fairly short program, I started the compilation, bought a bottle of Coke from a vending machine, went with it to the smoking room with a book, smoked a cigarette or two while reading my book and finally went back to see if my code had been compiled. It usually wasn't.
So you're still quite young? The generation before you had to deliver a stack of punchcards in the afternoon, and would then receive the compilation errors the next morning.
There are some good points in this talk, but the hectoring tone makes it pretty hard work to listen to the talk.
i like this Guy
Not that sold on 'the first question':
- If you think, 'your way of doing things is the only correct way', you're objectively wrong. (presented example, the concept of scrum)
- If you think, 'you know better than management', you're objectively wrong. As it is their job to know more than you, you must assume they do. (providing more info is fine. Asking about the additional info, based on which they overrule development and increase TechDebt, to keep up with unrealistic promises, is not)
- (the actual question) If you think, 'trusting [Product Owners] to call in developers to assist in the customer contact *when needed* .' is something that works, you're objectively wrong: the *only* way to get anything to work, is if every developer is replaced with (/trained to be) a consultant.
40:40
I find defensiveness about your work, almost perfectly correlated with being bad at your work ..........
Yup you would
There are 2 reasons why one would be defensive:
- they f-ed up
- they have a history of answering to blame-shifting bad management.
(to the point where, being put in a defensive position, triggers a reaction from a defensive position)
Given the famous statement "People don't quit jobs, they quit managers":
I'm very skeptical at anyone who's talking to someone they *know* is actively in the process of quitting a bad manager and won't even entertain the notion 'having a bad manager' might be a factor.
If I were given the option to redo a project from 5 years ago, what would I do differently?
I would reconsider picking up this, adjacent but strictly speaking out of scope, mid-high impact bug, management insists on not fixing (because we made higher priority promises).
If I were in an interview asked to answer the above?
I would try to think of something different, try to find any excuse to stick to the 'job-interviews or first-date'-rule of 'under no circumstance do you state anything negative about the (hopefully) predecessor of the person you're speaking to' rule.
I am good at my job, job-interviews are not part of my job.
(The thing that got me hired at a previous job, was how much I lit up, dropped all signs of stress, the moment they mentioned they would have a test as part of the hiring process. (The senior developer, told HR that the test would not be necessary, based on that reaction alone))
I don't hear 'have you learned anything in the last 5 years?' I hear 'Something went wrong 5 years ago (simply statistically likely) are you willing to lie and take the blame of poor management? (We're not recruiting for developers, we're recruiting for meat-shields)'
I disagree that the estimates are estimates and they are needed for business.
An estimate of days, weeks or story points is truly a bad idea. It's never worked. Business only gets a falsehoor.
Understanding that something will cost 10k or 100k is doable, but not as an estimate of time. The reverse is also possible, less than 1 month or 5 months, but this is not what estimates are usually for.
When you say you get better at estimates, it's not true, because of what is really happening.
The real happening is, fudging implementation to meet your estimate. What you get better at is understanding the tolerance of fudging. Example, the 15% is actually a lot more, it's confabulation to bring it to 15%
Parkinson's Law, measures cease to be a measure and all that.
I think estimation is actually the lie we tell ourselves.
As I mentioned in the talk, I and my team have been doing decent estimates for over twenty years.
Typical estimates are in weeks or months, or in total cost. The majority of those estimates come reasonably close to the actual numbers - within ten percent is our goal and usual outcome, though some creep a bit above that. While it's true that there are outlying cases where the estimate is off by more, especially with leading edge technologies in which the team lacks experience, those are the exceptions, not the rule.
No fudging of implementation is involved in the vast majority of cases. That would defeat the point of the estimate. There may be some adjustment in scope as the project proceeds, but a good estimate includes enough slack to allow that.
In some cases, the estimate drives reconsideration of the scope, as the business realizes some capabilities are not worth the development cost. That's one of the reasons, in fact, that the business needs estimates. It's so much better for everyone involved to adjust that scope *before the project* instead of in the middle after realizing it's necessary.
I agree that estimation is hard. It's a skill, and takes a fair amount of experience in both the specific technologies involved and in the general art of software development. Good estimating also requires the willingness to disappoint business oriented people who would like to get software on the cheap.
So I must challenge the idea that acceptable quality estimates can't be done. I must vigorously challenge the idea that they are not needed for business. In many cases, without an estimate from a reliable source, businesses simply won't make the investment from fear that it's not a good investment from a cost/benefit perspective.
That means we as a profession have a vested interest in doing reliable estimates. They increase the total amount of work for us. Individuals may be in circumstances where they are allowed to proceed without estimates, but in my experience, that's not the norm. Typical managerial people have a strong aversion to approving the spending of money when they don't know how much it's going to be.
@@boumajohn In the common case of replacing an existing application or module, the requirements are taken to be (1) the functionality of the old app, plus (2) a delta of new functionality. Thus, studying the old app and analyzing the delta is needed for a decent estimate. This doesn't take a huge amount of time. We usually flesh out the understanding with a UX design phase.
For completely new apps or modules, it is necessary to spend some significant time on requirements before an estimate. We shoot for 85%-90% understanding. We map out workflows and again do UX design to flesh out the requirements. Can take anywhere from a week to a couple of months, depending on the size of the project.
In our world, that requirements understanding would have to be done anyway, because the necessary architecture also depends on those requirements. The estimate and the architecture both depend on an understanding of the problem(s) to be solved.
To reiterate, this isn't easy. But it can be done. The value of the developer or the team increases dramatically to the business decision maker when a good estimate can be rendered.
i rather see it like this: if the marketing really needs this feature then an accurate rime estimate isnt needed. Just one that gives the order of magnitude: does this take a week, a year or 10 years? more exact estimates isnt reliable and trying to accomodate more exact estimates actually hurts more than it helps. Cause they will believe in your numbers even if you say they are uncertain.
If you have work items taking 2 weeks or even 6 weeks something is wrong anyway 😅
Dear presenters, for god sake stop telling people to move seats !!!
If you don't present to large groups, you may be unaware that having more people close to the front helps energize the audience and makes the presentation better for almost everyone. It also lets the presenter get better feedback during the presentation as to whether the audience is responding well to it.
Oh, and almost no one *tells* people to move. Like most presenters, I suggest that they move. No one has to do it if they don't want to.
nothing i have written (as a programmer) is in your speech, you are shouting at yourself
😂🤣
Once you get beyond bash scripts, you will Robert 😌
man this guy is old
I’ll get on top of the schedule with just a couple of 80 hour weeks. It’ll be plain sailing after that.
Stop looking at me 😅
I read that as "180 hour weeks" and thought, "good luck!"
Hah! 4:00
I made my previous post before he started.