@jasongorman@mastodon.cloud
@jasongorman@mastodon.cloud avatar

jasongorman

@jasongorman@mastodon.cloud

Software developer, trainer and mentor at Codemanship. Now run your tests.

This profile is from a federated server and may be incomplete. Browse more on the original instance.

jasongorman, to random
@jasongorman@mastodon.cloud avatar

6 Ideas That Transformed The Way I Make Software

Day #2- Iterative & Incremental Delivery

This is another of those ideas that seem obvious with hindsight, but in the first couple of years of my career, the majority view really was that we gather the requirements, plan the design, write the code, test the software and then release it - usually on a fixed date we committed to months in advance.

(thread)

jasongorman,
@jasongorman@mastodon.cloud avatar

Sounds great, doesn't it? All lovely and simple and predictable (and businesses loooove predictable). There's just one small problem: it's bollocks.

Even on what seemed like relatively straightforward systems, when the software was put in front of customers and end users, we'd get an avalanche of feedback about what was wrong with it. So there'd be a frantic phase of change requests and bug fixes to try and get the software into the ballpark of usable.

jasongorman,
@jasongorman@mastodon.cloud avatar

And it wasn't unheard of to be so far out of the ballpark that it ended up being abandoned. Just too much work. Quite often design decisions taken months earlier got baked in by all the code we added since.

That final frantic "stabilisation" phase was typically characterised by very frequent user feedback. Okay, we fixed that bug. Waddaya think? Okay, we moved that column. Waddaya think?

jasongorman,
@jasongorman@mastodon.cloud avatar

It doesn't take a genius to figure out that just maybe we should ask "Waddaya think?" earlier, and more often.

Instead of gathering all the requirements, doing all the design, writing all the code, and then testing all of it, it makes much more sense - for a student of risk - to gather some of the requirements, do some of the design, write some of the code, and then test that to get user feedback, so we can incorporate what we've LEARNED (in capital letters!) in the next cycle.

jasongorman,
@jasongorman@mastodon.cloud avatar

And it turns out that much - often most - of the value in software isn't in what we planned, but what we LEARNED from what we planned. So we need to LEARN as early and as often as we can. That's where the gold we're panning for usually lies.

The last 30 years I've been doing software development has been characterized by those user feedback loops getting shorter and shorter. In the mid-90s, my teams would tackle a bunch of usage scenarios, getting feedback every couple of weeks.

jasongorman, to random
@jasongorman@mastodon.cloud avatar

6 Ideas That Transformed The Way I Make Software

Day #1 - Usage-driven Design

Instead of asking ourselves "What does this system need to do?", a more useful question is "What do our users need to do /using/ the system?"

The user could be a person, or another system, or another class, or another function (or a test, of course).

When we approach design from the user's POV, we're much more likely to end up with the right set of features.

jasongorman, to random
@jasongorman@mastodon.cloud avatar

"Here at Acme Megatech Corp, we empower teams to do their best work. Also, here is the form you need to fill out to get pencils."

jasongorman, to random
@jasongorman@mastodon.cloud avatar

One common justification for why development teams need managers is that someone needs to see "the bigger picture", remove organisational obstacles, and broker agreements with other teams.

But in my experience, when I've wanted visibility of the bigger picture, or to remove organisational obstacles, or to reach agreements with other teams, it's been the management getting in the way.

jasongorman,
@jasongorman@mastodon.cloud avatar

It can be a self-fulfilling prophecy. Teams need managers because they need someone with the access and authority necessary to do these things for them.

And teams don't get that access and authority because that's not in the interests of the people they gave it to .

jasongorman,
@jasongorman@mastodon.cloud avatar

@zl2tod Autonomous teams don't need that, though. They're empowered to say "no", they nurture from within (e.g. mentoring) and engaging with stakeholders outside the team is very much part of The Work 🙂

jasongorman,
@jasongorman@mastodon.cloud avatar

@zl2tod Software developers aren't children

jasongorman, to random
@jasongorman@mastodon.cloud avatar

They say a picture speaks a thousand words

jasongorman,
@jasongorman@mastodon.cloud avatar

What I find most interesting isn't the image itself, but that someone selling expert guidance on "prompt engineering" felt it was fine to use it in that context.

jasongorman,
@jasongorman@mastodon.cloud avatar

It adds weight to my suspicion that the real key to being "productive" with generative transformers is not caring that the output's wrong.

jasongorman, to random
@jasongorman@mastodon.cloud avatar

Young folk say to me "You old folk don't need as much sleep as us". We really do. We're just not capable of getting it.

So.you have that to look forward to.

jasongorman, to random
@jasongorman@mastodon.cloud avatar

A lot of developers are from the "If it's new, I gotta have it!" school. I'm very much from the "If I'm still hearing about it 10 years from now, I'll give it a look" school.

jasongorman, to random
@jasongorman@mastodon.cloud avatar

TDD doesn't do the design for you.

Hexagonal architecture doesn't solve all your architectural problems.

Pair programming doesn't replace all other kinds of knowledge sharing.

Iterative development doesn't remove the need to think ahead.

None of these are valid criticisms of TDD, hexagonal architecture, pair programming or iterative development. Any more than "Yeah, but you still have to decide where to go" is a valid criticism of steering wheels.

ecomba, to random
@ecomba@ruby.social avatar

On related news, if you know of a place in London for my partner, motorbike and myself in London (from the 30th of June till the 7th of July) I’d highly appreciate it! 🙏🏼

jasongorman,
@jasongorman@mastodon.cloud avatar

@thirstybear @ecomba I mean way out, though. Like Norfolk.

jasongorman, to random
@jasongorman@mastodon.cloud avatar

Those devs who say "LLMs have 10x my productivity"... I've finally figured out how they do it.

https://chatgpt.com/share/85bf5ca9-dc40-4188-95b8-8545c9e269ab

jasongorman, to random
@jasongorman@mastodon.cloud avatar

If you genuinely believe people get worse at software development the older they get, you're a self-fulfilling prophecy.

jasongorman, to random
@jasongorman@mastodon.cloud avatar

It sometimes feels like the last 25 years of progress in software development has just been thinking up cool names for the things we were doing in the previous 25 years.

jasongorman, to random
@jasongorman@mastodon.cloud avatar

A sci-fi horror like The Three-Body Problem, but called "The Two-Party System", in which the solution to the Fermi Paradox is that technological civilisations vote themselves into annihilation.

jasongorman, to random
@jasongorman@mastodon.cloud avatar

Hey, remember when you used that in-house corporate IT system and it was just great and really easy to use and made your job so much easier?

jasongorman,
@jasongorman@mastodon.cloud avatar

@gdinwiddie And a rare one

jasongorman,
@jasongorman@mastodon.cloud avatar

@gdinwiddie The Three Amigos?

jasongorman,
@jasongorman@mastodon.cloud avatar

@gdinwiddie Ivar Jacobson, Grady Booch and Jim Rumbaugh.

  • All
  • Subscribed
  • Moderated
  • Favorites
  • •
  • megavids
  • thenastyranch
  • rosin
  • GTA5RPClips
  • osvaldo12
  • love
  • Youngstown
  • slotface
  • khanakhh
  • everett
  • kavyap
  • mdbf
  • DreamBathrooms
  • ngwrru68w68
  • provamag3
  • magazineikmin
  • InstantRegret
  • normalnudes
  • tacticalgear
  • cubers
  • ethstaker
  • modclub
  • cisconetworking
  • Durango
  • anitta
  • Leos
  • tester
  • JUstTest
  • All magazines
    •