Steve Hansell

🔥 One of the hardest parts of software development? Managing the unknowns. Earlier this week at Des Moines Web Geeks, we highlighted a powerful approach to tackle uncertainty in projects: Spike Stories. 🔍 Just like Frodo and the Fellowship faced choices between the treacherous Misty Mountains or the perilous Mines of Moria, in development, we face choices with technical unknowns that can derail progress if we’re not careful. Spike stories are your best ally to uncover and burn down those risks early on. Rather than waiting until it’s too late to face those “Balrogs” in your codebase, take the time upfront to explore, experiment, and determine the best path forward. By tackling the unknowns head-on, you can avoid nasty surprises down the road. #SoftwareDevelopment #TechTalk #RiskManagement #LordOfTheRings

12

Be sure to mark your calendars for this one! #kcdnug #dotnet #questanalytics

3

Estimating Effort is typically flawed. I've been recently intrigued by talk on LinkedIn about how Story Points in Agile development are terrible and should be avoided at all costs. I don't generally get into that sort of debate, because usually it ends up being an argument about one person's lived experience versus another. Instead I thought I'd contribute to the conversation with my own experience of using Story Points as an antidote to estimating by effort which is often (always?) flawed. First off, on the subject of estimating by effort, this is what I think... In order to estimate by effort on any reasonably sized backlog, you need to know three things: 1. What work you need to do. 2. Who is going to do it. 3. When it is going to get done. You need to know the first thing so you can identify tasks and assign an estimate of effort and/or time to each item. You need to know the second thing because and experienced developer might take one day to do something that an early career developer might take 3 days to do. And you need to know the third thing, because in my experience, most development teams accelerate as they go through the work. Without knowing those three things, any estimate you come up with is just a guess, and you will have to rely heavily on contingency, which makes your estimate a work of fiction. I've been working in software for a loooong time, and estimating effort hasn't often been successful. How often do we know those three things at the start of a significant body of work? Contrast that to the way I've preferred to work for quite a while, using relative complexity estimating, story points and a measured velocity. Without knowing every task you need to do, it is usually possible to find the least complicated thing you need to do (and give it 1 point), the most complicated thing (and give it, say, 8 points) and then assess everything in between for complexity relative to the other things you've already expressed a view on. You end up with a total points balance, and then if you know when you want to deliver it all by, you know how fast you need to go in terms of a points delivery per iteration. What it has historically allowed me to do is use language like "In order to hit the aspirational date of x, we need to maintain an average delivery of y / iteration". And you knew very quickly if you're going fast enough. It unlocks conversations early about adding capacity or modifying scope. I know loads of people will come up with reasons why this is flawed or hasn't worked for them, but I'm putting it out there as my experience. In 31 years of software development I can say with confidence that those bodies of work delivered by estimating effort have been less successful than those using points and relative complexity. I'm always open to learning, though, so I'd love to hear in the comments about alternative ways I could consider that improve on that approach.

7

8 Comments

The dev team have adopted this thing where they won't do anything I ask for until they told me to "p!ss off" at least three times. Their rationale is if its really needed, I'll keep asking. Can't work out if this is good or bad. #development #agile #projectmanagement #startups

9

5 Comments

Kyle does a great job to highlight the pains of translating a shared design system into shared styles between React web and React Native. I do like the use of types to enforce existing style primitives compared to hard coding numbers, but I understand that native mobile developers are not used to the compositional nature of the first design system, compared to shared styles via StyleSheet, NativeWind, or similar. Fusing mobile and web beyond the data layer becomes more and more tricky. react-native-web often isn't the answer. As "headless" components grow to help fuse HTML vs React Native components, we still have a need for sensible styling.

8

It's Friday, and my unit tests are making is so I can enjoy the weekend. #alwaysbeshipping #tdd #continuousdeployment #continuousintegration #softwareengineering

5

Preparing for value-based care? Avoid these 9 data mistakes to ensure you can take on new risks with confidence. #healthcare

1

What I've found is that stakeholders and project leadership look at Agile as "let's just start working on 'something' and we can figure out the details later", which is obviously a recipe for disaster. The Agile projects I've seen succeed actually look a lot like Waterfall projects initially (with almost all of the requirements defined up front), where accepted new requirements are really just small changes to existing functionality. https://lnkd.in/egHcKycy

6

😀 Upcoming Complimentary Angular Coaching Session with SeaLadder: 📅 Angular Front-End Development Intro Session: Wednesday July 3rd at 8 PM AEST If you've already signed up for the Angular session, we look forward to seeing you then! Calendar invites and additional information has been sent out via email. Haven't signed up yet? Head over to our website or complete the Google Form below. My partner Adam Pond is going to be your rockstar coach - and if you know Adam you know his passion for learning is unmatched. The course is 4 weeks long, culminating with a project that you can proudly put on your CV 🚀 Why Join SeaLadder? 😎 SeaLadder is revolutionizing upskilling for software developers through a community-driven approach. As a member, you can: - Learn at your own pace or within a cohort - Become a mentor and share your expertise - Engage in diverse tech topics - Grow with a supportive community Special Beta Launch Benefits: - Free coaching sessions - One month free access - Discounted rates for the first three billed months Visit SeaLadder for more information and to secure your spot. 🌊 SeaLadder: Empowering Developers through Community and Learning 🌊 #angular #professionaldevelopment #frontenddevelopment #softwaredevelopment

4

Split the room into 2 teams: Team Waterfall and Team Agile. Both teams have to guess a random 4-digit number. Team Waterfall has to guess all 4 digits at a time. Team Agile has to guess 1 digit at a time. If their guess is wrong, they are told "Wrong", and they must guess again until they get it right. Which team would you bet on to guess the 4-digit number first? Now let's 10x Team Waterfall. For every guess Team Agile gets, Team Waterfall gets 10 guesses. Which team would you bet on now?

79

65 Comments

The classical yes-person is a terrible thing in the workplace. Equally bad, however, is the no-person. I've observed this pattern in some engineers who have been too long in a single place. This isn't ageism talking, I've most recently seen it in a person in his late 20s. The no-person gets stuck in one area, it gets too comfortable for them, and rather than innovate or adapt, they use their often formidable institutional knowledge to knock down any idea. They are adept at finding reasons not to do anything and can easily convince weak managers to always play it safe. They kill team morale. Folks begin to censor themselves, and shortly thereafter they stop caring altogether. If you have such a person, do not delay in dealing with them.

10

It amazes me how many people have a hard time grasping what a User Story is supposed to encompass. So here it is. I am Sisyphus and this is my boulder. A) The User Story statement includes the Who, What and Why of the functionality being requested. Nothing more. B) Everyone on the team, including developers and testers, have a full understanding of the Acceptance Criteria and have had the opportunity to ask the business questions required for them to gain a full understanding and context. C) Each Acceptance Criteria is a finite statement that can be definitively proven either true or false. It is from this finite statement that Testing Scenarios can be properly constructed. D) There should never be any implementation details in an Acceptance Criteria. Acceptance Criteria are ONLY the definition of the What of the User Story statement. Nothing else. The ‘Definition of Done’ in the business rule context.

8

1 Comment

We've collectively decided to move away from using the strict Definition of Ready (DoR) to avoid any unintended bottlenecks in our collaborative process with the Product Owner (PO). Instead, we are adopting the "Good Enough Product Backlog Item (PBI) Guideline."The "Good Enough PBI Guideline" allows us to maintain flexibility and foster continuous collaboration between the team and the PO. This approach ensures that we can start working on items that are sufficiently defined but may still need some refinement as we progress. It encourages proactive communication, quicker iterations, and a more adaptive workflow.

28

3 Comments

My initial involvement with .NET was in 2008. I started with WinForms, then UWP, and most recently Blazor, with some Web API work as well. I also did/do some Xamarin.Forms and .NET MAUI on the side. I've worked with SQL Server, Oracle, and SQLite. The last year has broken me. Without work and income for at least a year I've been forced to start tapping retirement funds at least a decade before I had planned. (In fact, I had always hoped to take my last breath at the keyboard trying something new.) The constant fruitless efforts in the job search, including massive numbers of ghosting events; postings I've applied for, never had a response, but continue to be posted; the horribly vague pieces of textual trash called job descriptions; and so on, have made me give up. I just can't do it any more. Without the generosity of friends, right now I'd either be dead, in jail, or living under a bridge. This was not the way I saw my future. I dedicated my career to .NET and I ended up broke and homeless, in massive amounts of debt that can't ever be repaid. So I'm backing away from full-time search. That said, I'm still looking to keep involved with the .NET technologies but in a part-time manner, as well as build upon the meager retirement income. I'm looking for a Blazor or MAUI project to work on, perhaps a lower-priority solo developer effort, demo, or POC requiring around 20 hours a week. If there's some other .NET technology, give me a little time and I'll get up to speed. No charge until I start doing your work! It probably could go unsaid, but I'm not interested in being contacted by recruiters. You're the ones that did this to me with your gross incompetence and terrible work practices. Yes, I'm bitter, and I hope every one of you that ever ghosted me suffers like I am.

2

5 Comments