Category: Agile-Related

Thinking about software, economics, and the things I care about.

There are far more important things going on in the world than my Python programming.

We can only improve total productivity by improving people and processes. Re: A post from Kent Beck and Gergely Orosz. [cw: "Intercourse"]

Perhaps the biggest mistake in XP and Agile ...

Usage changes. Language is usage. Language changes, not necessarily for the better, in my opinion.

Tuesday night's Friday Night Coding Zoom has hooked me. This is the beginning of the result of that hook.

Some thoughts after another pleasant conversation with Colin Hammond of ScopeMaster.

If in fact I'm done, for a while at least, with the dungeon program, what shall I do and write about. Your input welcome.

I was asked what I tell people to do that I don't do myself. The answer may surprise you.

We should have it. What should we do when we haven't?.

Estimation and a tiny bit of code. ScopeMaster took up my challenge.

I don't like estimates in this world. Perhaps you do. If so, and you're so inclined, pick up this challenge. I'll tell you everything I know to help you.

This morning, I plan to write about COSMIC Function Points, Agile Practices, Civility, and Kindness. I can't wait to find out what I have to say.

The experiment i did yesterday deserves a bit of commentary. Something to think about.

Here, some thoughts raised by yesterday's Agile Alliance Zoom thing.

You'd think that software developers would realize that they are prone to error. Yet we are often more opinionated than we probably should be. Here's my opinion on that.

In which: Our intrepid author attempts to find some use for the FP library he has been toiling on for over four hours.

Today, for your delectation, I offer: the Library Trap! (Update: I looked at XSet2.)

Let's see if we can find a decent way to provide filter, map, reduce functions in Codea Lua.

Kent Beck is writing about 'tidying'. It's a whole patch of delicious strawberries, and I highly recommend them.

Yesterday's search for strawberries in the XST patch discovered problems. I want to at least double check what we did. TL;DR: It all works. Odd morning.

We're taught to 'make it work; make it right; make it fast'. We're taught that if it's hard to test, it's not right. Let's explore. TL;DR: No strawberry here?

Can we make our programming life immediately easier with this one simple trick? The answer may surprise you.

One 'reason' why folx don't want to learn technical practices seems to be that they expect no benefit. Sometimes that's more about futility than actual benefit.

Some developers show little or no interest in learning practices that could make their lives better. I'd like to understand that.

I don't know whether this is good or bad, but it's an interesting trick.

Wandering off. Spinning down. Fading out. My projects here have a habit of that. What does that say about me, about you, and about our work? And krill? Really?

In my thinking about Strawberries, I'm wondering what issues folks have with Scrum, good or bad. Please tell me. I'll mention some ways here.

There are signs and portents. What are they telling us? Is this death--or is it perhaps a rebirth?

I'm taking a couple of on-line comments as writing prompts today. Let's see what we get.

Today I learned a new term. Maybe better/worse than 'Dark Scrum'. (TL;DR: If it isn't joyful, we're doing it wrong.)

Agile Software Development is about people working together. For that to happen, it helps to be kind, respectful, and helpful. Let's talk about that.

I'm pressing forward with the Lispy thing, but I have some concerns. I find it difficult to think about but I think I have an angle. (Spoiler: It's a wrap!)

TDD is too big a lump to be a good strawberry. Today I'm playing with TDD to try to find a bite-sized goodie. I expect not to accomplish that.

Technical Practices, Craft, Excellence, Improvement, Ease, Joy. What ARE you talking about??

A Twitter exchange yesterday and today has given me today's topic. I love it when not having a plan comes together. (Hm. Societal impact is similar ...)

Let's consider the implications of small-step development on our three shadow views of the program. (Includes Sarlacc.)

Yes, short feedback cycles are good. But is the trick of the trade 'small', rather than 'short'? The answer will not surprise you.

Working software is at the core of success with agile methods. Let's remind ourselves about that.

GeePaw Hill is workin on an idea. I urged him to publish his thoughts because I knew it would help him to make things concrete. Also I wanted to comment here.

I wasn't really planning to write about Sudoku again, but here we are.

I know what you're thinking: 'Is this four rules or only one?' Well, to tell you the truth, in all this excitement, I kind of lost track myself. You've got to ask yourself one question: 'Can I use this?' Well, can you?

We're here to replace raspberry jam with strawberry jam. We need those delicious nodules of flavor and value.

It's not the method. It's not the framework. It's your unique assemblage of innumerable small things that work together toward success. And some larger things: the people.

It's Wednesday. At last night's Friday Zoom Ensemble, we talked about Jam. I am inspired to put down some thoughts. Bottom line: On-line strawberry, not raspberry. (Updated, more links.

Just a bit more playing with the Lispy Calculator to while away a few minutes in the afternoon.

Thoughts and observations. Stuff and nonsense.

I'm going to push forward with this LISP / Scheme dialect. I'll begin by explaining why, and why not.

It's still the weekend, so I'm going to follow Peter Norvig's Python LISP Implementation a while and see where it takes me.

It's my weekend and I'll try if I want to. You could try too if it happened to you. Spoiler: This takes a very weird turn. Final line: Your move, Bill!

I guess there's nothing for it but to figure out how to rewrite, i.e. refactor, a set operation based on the existence of helper structures. But how? I have ideas but are any of them any good?

Bill Wake is trying to get me to think in terms of trees. I don't want to, but he does have some good ideas. Thanks, Bill!

Today I plan to experiment with creating some form of expressions that might be optimized. I expect to stumble a lot. Come along, point, and laugh.

No, not smiles and frowns. Algebra. At this moment I don't think much code will be done today. Feel cute, might delete later.

It's 6 AM and I have an idea. This could be very good or very bad.

I don't love the interface for adding functions into an XSet. And I want to add them 'one level in'. Will hilarity ensue? Probably not, but something will happen.

Some HNY thoughts, and more on the function as an element idea. Joy, philosophy, code. What's not to like?

I was thinking before I got up about median and mode. Then I had a truly marvelous idea.

I want Lua tables to be more useful as XSets. There's a hard way. But the current design also offers an easy way. (The answer will surprise you. It surprised me.)

I'm on a path to make ordinary tables behave like XSets. But first, I have to figure out how this thing actually works! Much musing, then some code.

I have in mind small things for today, starting with an interesting and confusing mistake left over from yesterday.

No, I'm not hearing voices. But the code does tell us things, just like any working material. We need to learn to listen. Today, we listen and the result is good.

A look at the code. Maybe a bit more on stats. P.S. I learn something and ditch almost all the code I wrote this morning.

It's Christmas, I'm waiting for the household to wake up, and I enjoy what I'm doing. Perfect holiday so far!

I didn't do the best possible thing in this morning's XST article. Here's what I think about that.

Today I plan to get grouping and summing working. Who knows, it might happen. If not, there's always tomorrow or my birthday.

Let's think about what the current drafts of summing and grouping tell us about our system. Then code (anyway).

Today, rather than make any deep progress, I plan to work on something I consider interesting, sums, averages, and grouping. I promise to publish this even if it explodes. (It doesn't, quite.)

Transformations, optimizations, and the relationship between OO and XST. Got some thinking to do. You get to watch, if you're tough enough. At least a tiny bit of code.

Step by step, inch by inch, slowly we turn long searches into more direct accesses.

I don't want to get stuck in a never-ending series of new setops: there won't be much learning there. Where's the beef?

I'm sure a lot of you have been saying 'Yes, but what about tuples?', or 'Why XST anyway?'. Today, we address those fascinating concerns.

Let's work on those new operations a bit.

Short morning today. I have a tentative plan for indexes. I'll scribble some sets. Might code.

Last night's Zoom Ensemble netted me a few ideas. I'll start exploring those today. Hilarity or perhaps something good will ensue. I can't wait to find out.

Further reading leads me to think about design, and design motivation. Castles in the air. Or underground. Good stuff happens.

In conversation with Bill Wake and with the Internet, I have an idea for something to try. And I'm just about ready to assess where we are and where we should go.

I'm not sure whether this will be useful, but Bill Wake gets the credit if it is.

Bill Wake was trying to hammer an idea into my head. I must think about that. And I have a small idea of my own.

Time to work on the actual restrict operator for CSV, since the pattern-maker experiment was a success.

There's no way around it, I've got to work on the fast restrict today. Might not finish. We'll see.

Getting started with CSV data. And reporting a conversation.

Reflection leads me to focus a bit more on set operations, and less on internal methods. Does this call for a new layer? Also: real technical debt! Updated with idea from Carl Manaster!

I'm going to try to create pipelines using coroutines. I think they may make for a more expressive interface. I turn out to be partially right.

How do you design a thing like this, Brain? Same as everything else? Or not?

I was puzzling over an issue with 'union' and gained an insight that either I've never had, or that I had lost. Whee!

I found the easy way to build an iterator in Lua, so we'll do that and see whether it improves the code as much as I think it will.

I think I'm going to start on restrict today. There are some issues around atoms.

Last night I understood how to do something with XST that I've not in the past been able to do. So let's talk about why XST is interesting and what one might do with it.

I have a random idea about the data structure for sets, so thought I'd give it a try.

Save me, I'm thinking about Extended Set Theory again.

Just because I think I should do SOMETHING, I think I'll improve how CodeaUnit displays results on the screen.

I'm going to try to build a 'fluid interface' feature for Codea's graphical style capability. Why? I don't know.

Let's improve CodeaUnit a bit. But first, what's the deal with iOS shortcuts? An odd report on an odd morning.

Driven by some Slack chatter, I've been thinking about feedback. How does that fit into life, and into this little program?

Some refactoring, and some thoughts on a Twitter thread. And an odd surprise: the code says No.

Rules, rules. TDD rules, Beck Rules, OK. And a cat.

I'm just not up for going back into the Dung mines. Gonna put plain function detection into the stats instead. Also, random subtweeting. Also bear bites man.

At last, I get to apply Dave's scrolling thing. It's simple, and obvious, and I never thought of it. And a couple of stories of a great programmer.

This morning, I plan to add detailed method reporting to the full report. I am expecting no real trouble but have recognized a mismatch.

Let's get some output up in this baby. I plan to steal two good ideas while I do this.

I wonder what we could do about comments. They're tricky.

"If this is his idea of fun, he must be a laugh riot at parties." -- A Reader

Backward? Or forward? Which was it?

We continue working on our little 'Making App', because it's kind of fun. Today, I foresee a 'major refactoring'.

Let's do methods, and try to drive out some objects.

In the interest of variety, let's do some work for the makers here. Let's see how we can collect some interesting statistics from Codea programs.

What's the deal with Jira? Is it a bad thing, or the worst thing?

We were thinking about words for code. Let's consider these. New! Improved! Now with more words!

Today, I'm going to try a fun exercise to demonstrate Codea's translate, scale, and rotate.

Two ways of doing a thing appeared on the Codea forum today. I'd like to see whether we can transform the one into the other in small steps.

Another in my continued attempts to come to terms with what Scrum is rather than what it could (and should?) be.

Satire? Idiocy? Monkeys? Why not all three?

Again today, I take my writing prompt from GeePaw. I have a good purpose in mind. (Added: Dammit. I didn't expect to end up here.)

Is it useless marketing BS? Certainly there are issues. [CW: language, systemic racism/sexism]

Events in a few worlds lead me to write a few words about how we treat each other.

When someone shows you who they are, believe them the first time. -- Maya Angelou

I've had a reply from the Chief Product Owner of the Scrum Alliance.

I think that today I'm going to write about joy. I have no idea where this goes. Walk with me ...

Jeff Patton writes about the importance of outcomes. Yes, and ...

I've think I've figured out the disconnect between my view of the Scrum Developer priorities, and those of the Refactoring Team who created the new CSD track.

Responses from Scrum officials to my recent Scrum articles here and on more private slacks have not been favorable. I think I'll sum up and move on for now.

I've chosen a large windmill at which one might tilt. Could we, of good heart and great skill and courage, fix Scrum? If so, should we?

The End Scrum Now site, a bit of a rant, raises important issues. Let's explore some of them.

Herewith, some remarks pro-Scrum, and a reminder that Scrum is not as good for developers as it might be. Even some advice to developers.

On June 19th, I sent this email to the CPO of the Scrum Alliance. I have had no reply. In a second article today I will offer some related ideas.

A week ago, I posted a Scrum-related survey. Today, the results of that survey, and my comments.

Scrum asks for an Increment every Sprint. Of all the Scrum rules, this one is most important for developer success and survival.

A few(?) more thoughts on the battle between Scrum and Software Development. A review of some past thoughts, and some of today's.

The Scrum Alliance mission? Let's talk about that. Fail better.

As often happens, this article didn't go where I expected. I hope you like where it went.

What are you doing, Ron, how do you do it, and most of all, WHY?

I was going to move back into the dungeon today, but realized I wanted to talk about what I learned doing the ominoes exercise. Here goes ...

It is of course necessary to display yesterday's polyominoes, for our viewing pleasure.

The Zoom Ensemble folks have been playing with polyominoes. I can't resist embarrassing myself by trying them.

Alistair found some ancient estimate for a KWIC program and challenged folks to implement it. I'm picking up the challenge.

Every time these organizations stamp out a new ScrumMaster, there are programmers somewhere whose lives will be made worse.

Some thoughts on the world as I see it today, in 2021, from my privileged vantage point as an old white guy in the USA.

Today, some code review. No big plans. We'll see what we see. I expect to mention Beck's Four Rules.

We'll look at using invader count as a flag to start a new rack. I don't promise to change it.

I don't feel very bright this morning. Let's see if I can prove it.

I have an idea and I can't wait to try it out. Niagara Falls.

Today's plan: Code review, and targets of opportunity. Short morning, just one new class.

Displaying two player score. Beyond that, we'll see.

Attract mode needs to be turned back on. Maybe we should show both players' scores. What about those buttons?

Let's do more on the two-player game mode. We're probably getting to the hard part.

It's time to start on the two-player option. I have ideas but not precisely a plan.

A lesson from history, a surprise refactoring, and, apparently, a sermon.

Not really, but the saucer is looking to score.

Users observe the need for more racks of invaders. That's going to get ... interesting. Also Game Over if they reach bottom.

I've convinced myself that a global would be a better way to handle constants than the singleton. Kill your darlings.

Users have detected a problem. Users, do you hear me? Users!

Improving zombie behavior. Sound adjustments. Maybe more. Maybe less.

Let's take a look at a simple attract mode. Zombies!

More with Singletons. And distractions. And no singletons.

Improving our Singleton and using the idea elsewhere.

There's no reason to think that I'm smarter today than I was yesterday, but I am a bit more experienced.

Touch to Start has me thinking that attract mode might be within reach. Things go Very Wrong.

Saucer Scoring, then whatever makes sense to me at the time.

Another day of improv. Let's see what looks worth doing. (Wow, a factory object!)

What shall we do today? I honestly don't know.

Remarks on a Twitter comment from Jez Higgins.

Another defect. I'm starting to feel ... afraid. That's not a good sign.

This isn't Houston, but we definitely have a problem. And it's not a new one. And I'm tired of it.

Things we might do. And I'm thinking about conditionals. The next trick may surprise you.

I have an idea. Let's find out if it's a good idea.

Maybe some tuning. Do we need more start-up settings? Should the test results disappear? What about a FireControl object?

The world is burning, and I'm really just trying to ignore reality, but in addition, I've made a mistake. Another mistake, that is.

If nothing else, you have to admire me for getting over 100 articles out of ancient video games. Let's do another today.

A couple of interesting articles crossed my virtual desk yesterday. Links and some reflection within.

Better scaling, then more with the saucer, I guess. Plus whatever opportunities we spot.

More with the saucer, that's my plan.

I know the voices in my head aren't real, but they're sure ticked off at me for the past few days of messing up.

Well this goes entirely not as planned. Double Arrgh.

In which our intrepid author makes a grievous error: disagreeing with Kent Beck. Or does he?

No, not space pirates all of a sudden. I released a fatal defect yesterday. What's up with that?

A couple of small changes to CodeaUnit and my CUBase template. Then let's see what we can improve about Space Invaders. (Saturday: Arrgh, a defect!)

More to do with bombs, especially targeted ones. We need some refactoring as well. The results may surprise me.

I think today we'll work on the bomb timing, and targeting the rolling bomb. Often, what I think will happen is what actually happens.

Let's continue the bomb dropping logic. Our current design can't do what's required.

Speed indicator; Bomb dropping order; Free player, maybe.

Some recovery from repo problems, some work with the clock, whatever else seems right.

The web site with sounds came back, so I'm scarfing them down and starting to install them. Should be mostly straightforward, he said. Except when my repo locked up.

If you're like me, you're wondering what space invaders eat. The answer will surprise you.

Let's damage shields from below, and try to continue small steps toward 'better', whatever we mean by that.

Let's make missiles explode, and continue improving this design.

I want to figure out why this program makes me feel bad. Then do something about it.

Some improvements. But first, a word about less technical matters, the book `x + y`, by Dr Eugenia Cheng.

A bit of planning, a bit of action.

Let's get a start on scoring. This should be easy enough. But--when is too much way too much?

I woke up this morning certain that some of my bitmap calculations were STILL off. Something has to be done.

A bit more exploding. I'm going to continue to let things get messy.

Let's do some damage

It's my ball and if I want to play with it you're not the boss of me.

One of these two things is not like the other ...

If the world isn't flat, how come these invaders keep falling off the edge?

Today we'll try to fix the collision logic to accommodate our origin changes, and to make the invaders explode.

I've moved the good iPad into the TV room and while waiting for our Sunday festivities to start, I'll set up the project's bitmap assets.

Having decided to move to CORNER mode from CENTER, we've got some work to do. I'm hoping this one isn't interesting.

Is it worse luck when Friday the 13th comes a day early? Or a near miss? Time to dig further into bombs failing to miss shields. (Added Friday: It was worse luck.)

I had no plan. Now I have a plan. Check code clarity, then work on shields. Things go ... oddly

Maybe make the invader bombs do some damage? Or what?

My plan for the day is to retrain myself by reading this code that I've not touched for two whole days, and then to see about moving things forward. My guess: invader missiles.

I think today I'll work on making the invaders march back and forth. Right now they just march forth and forth and forth ...

A friendly demo of shield damage techniques leads to an examination of an interesting coding approach. I need to figure out what I think about it.

It's 6 bloody AM and I'm programming. What's up with that?

Let's see about extending our square invaders game-like thing to be a bit more like a game.

Twelve articles and no product. What's up with that?

Adam Savage (@donttrythis) posted a marvelous video of his attempt to build a giant brass nut and bolt. It reminds me of software.

In the real game, the invaders' missiles eat away at the shields. How can we duplicate this effect?

An experiment and some planning. Then even some doing.

Learnings from the ancient scrolls. What shall we do about them?

This one is mostly for the record, if it goes as planned. I'm just going to import some more bitmaps. I recommend against reading this.

Let's see what happens if we try to refactor our little spike into something reasonable.

A bit of an idea about marching, and thoughts about spikes.

I need an idea. Representation is important.

I'm wondering how to move these invaders. Let's do an experiment.

Dave1707 from the Codea forum shows a much better approach to converting the bitmaps.

Importing Invaders. How hard could this be?

I'm having so much fun with Asteroids that I thought I'd look at the old Space Invaders game. I'm sure I'll learn something.

Let's clean up that level handling a bit.

Unfortunately, we need to take things to whole new levels. This'll be fun. (Later: not as interesting as some, but it has its moments.)

Let's get some more modernization up in this baby. I'm sure it's the only reason we aren't selling millions.

Let's see about reducing a Singleton or two, and maybe some more modern graphics.

Our marketing people have a challenging request: modernize the look of this game.

It could happen: I've figured out a good way to handle these callbacks.

We'll continue our code review, with particular attention to our tweens, especially that tricky one.

I feel like reviewing some code. What I learn? Kill your darlings.

We're nearly done here!

Some tweaks to hyperspace seem in order, but I feel that this thing is nearly done.

Enhance Hyperspace?

Perfect saucer shots and a start on hyperspace.

Let's put in some options.

Let's clean up the Aimer and look around. I think we need options.

I really want to crack missile targeting. I've made some observations.

Two things go right. One thing goes horribly wrong

Free ships. Beyond that, maybe some reorganization? No, more like confusion.

Let's finish up the small saucer, and how about testing it this time?

Ships Remaining Indicators. After that, who knows?

After some discussion of things we might do, we decide to do GAME OVER. The results will surprise you.

Run tests automatically, dribs, drabs, and oddities. Pretty calm.

Today I plan to give the saucer the ability to aim its shots. I anticipate zero trouble.

A bit of planning and a bit of doing.

Not really an answer, but just a bit of fun.

Some sound, and saucer needs to stop helping so much.

Let's do collisions. And try to TDD them.

We move saucer and ship in the direction of our new scheme, and get rid of the cloning of the collection. Also took a nice walk.

We made a number of useful changes last time. Let's harvest some value.

I'm sure my double dispatch approach will work fine. But the pattern seems simpler than that ...

Some thinking and working on collisions. Is Ron converting to London School???

I've determined that it's time to collapse some 'technical debt', in small, incremental steps.

We need to improve collision detection. I think we have to do it in one go.

I think this afternoon I'll just push a little further on the saucer. Maybe make it dangerous.

I've decoded how to draw the saucers. Let's see about making them fly. That will require some research.

Some rationale, an experiment, some learning, some protection.

We start asteroids on the edge, which gives us an edge on refactoring.

A new approach to steering. And an apology.

I found some better recordings of the Asteroids sounds. And it's time to trigger new waves.

Stereo, because I can.

Based on the 'learning' from #25, let's just make bigger buttons.

Today I decided to experiment with improved controls. The experiments, um, succeeded oddly.

New ship, new sounds, learn new tricks, amaze your friends, confuse your enemies. Apply now! UPDATED!

I think today we'll do waves of asteroids. And some tests.

I've made yet another mistake. Will the embarrassment never end?

I reckon it's time to kill the ship when it's hit by an asteroid. I have a clever way to do it and a direct way. Which is best?

I'm feeling like coding a bit this evening. So stand back.

Thinking about tests and refactoring. The boss wants a feature.

I think it's time to move more toward objects. Part of our mission is to decide what we like. And: 'No large refactorings!'

I thought I knew what we had to do today but I was a bit mistaken. We need more, and better thinking ... and code.

Just arriving 'at work' this morning, I'm thinking we'll make the Ship move. We need a safe place to land first. EDIT: Arrgh, a defect!

A report on last night, and a 'major' refactoring. P.S. There is no such thing as a major refactoring.

A quick report on a short project last night, then let's try to get something nearly playable.

I looked up tween and my tween example and it seems like just the thing. Let's find out.

First, I'm really feeling the need to improve this code. But maybe it's too soon to do good work? Plus explosions.

Displaying different shaped asteroids is nice, but we have an issue of size we might work on for a bit. And let's split them!

Having converted the 6502 asteroid shapes to Codea style, let's plug them in. This design is starting to bug me, and we'll think about that too.

Dave1707 offers a much better idea for the conversion of Asteroids graphics into Codea. Let's explore it.

I found the definitions of the asteroid shapes in DVG language. Let's draw them in Codea.

I spent last night decoding some graphics chip code on computerarchaeolgy.com, and I managed to draw an Asteroid in the classic style. Today, a look at what I found out. Updated: New Resource.

I've decided how buttons should work. It only remains to make it so.

To move forward with this project, the ship needs to be able to move forward. And turn. And fire ...

OK, Asteroids doesn't have a horizon, but today we'll start on the ship. Shouldn't be too hard: it's a triangle.

I needed to test some floats the other day. Let's improve CodeaUnit to help with that.

Today we'll clean up the code a bit. It really needs it.

Today I decided to draw two square asteroids at random angles. All's well that ends well, but I did get confused.

For something to do, and because it might be helpful to new Codea users, I'm going to implement an homage to the old Asteroids game.

Wow. Shapr 3D is neat! I wish I could use it. It's so cool I might warp my process just to fit it into my plans.

This may be the most powerful most frustrating 3D application ever created.

To create reasonable creatures or vehicles, I'd need a decent 3D object creation tool. Ideally, since this is an iPad project, an iPad app.

I am supposedly on a course to make the Orc stay within bounds of our little world. Today might be the day ...

It's probably time to work on behavior, so I want to take a bit of time to look forward at what we might do, might not do, and probably won't do.

It's Sunday. My long-suffering wife is prepping for the upcoming election. On my own, I decided to spike motion for my game creature.

I've decided a bit about the 'game' I'm writing in Codea. This should keep me off the streets for a while.

I've been reading examples and searching the web about terrain generation and I'm ready to start sharing. Brace yourself, this gets pretty random.

I feel I've got my feet firmly on the grass, dirt, and bedrock, and I can see what I'm doing. Time to become confused again.

I think I nearly have a solid place to stand: a tiny application that I understand pretty well. Today we'll clean it up and see what's next.

There's trouble, my friends, right here in river city. Is this little project serving my needs? Am I about to break through to the other side ... or to break through the ice and freeze?

We're at a fairly clean point right now. There are a couple of small topics in the code to consider, but we need to figure out a plan for what's next.

Owing to driver error, I lost all my code versions for the Orc program. We'll speak of recovery and then move on.

In response to some question on the codea.io forum, Dave1707 showed me a neat trick with text. It taught me something, and raised some questions.

Despite its great value in the hands of experienced TDDers, the uptake is slow and the practice is often hard to sustain. What's up with that?

The bird experiment worked pretty well. Now it's time to clean it up and consolidate what we've discovered.

I've made a couple of objects move, in two different ways. I figure that topic is spiked. What should I look at next? This session is gonna be rambling, I'll wager.

Today I'll build a different kind of creature, who moves differently from the Orc. The idea is to build up an understanding of where the design needs improvement in terms of flexibility or clarity.

Today I'll review the code, and think about whether to build in some object thinking. I want to ... but should I?

Last time I managed to make a fairly simple Codea Craft program draw an Orc standing on (or near) the floor. Today I plan to make him move a bit, and then to see what I've learned.

Yesterday I managed to move an Orc, by hacking a sample program. Today, let's try to do a clean version to consolidate our learning and ask ourselves some questions. Maybe even begin to answer some ...

I begin trying to make sense of Codea's ambitious and powerful Craft components.

>Alex Bunardzic has been part of a rambling Twitter thread about TDD and people who object to it. One of his concerns is that TDD proponents agree that TDD isn't always appropriate but don't say when. Let's explore that.

I tweeted this on the 18th, in response to something left frustratingly vague by one of my dear colleagues, which caused me to think more deeply about what they said.

Some folks who don't know TDD, and some folks who should know better, have been describing TDD in ways that don't match what I experience. Herewith, some thoughts.

In a Twitter conversation a week or so ago, I was asked to do a TDD video, to show how I do it. A video isn't within scope just now, but here's an article with real TDDed code in it.

Despite my concerns about experienced coaches advocating against practices that are often quite useful, there are a few things where I'd at least advise great caution.

This article expresses, in written form, the talk that Chet Hendrickson and I gave at the deliver:Agile conference.

A private note from GeePaw Hill, and a tweet from Brian Marick inspire me to mumble a bit about mindfulness and collaboration.

When I was blurting about the Increment as the most important thing, just the other day, GeePaw Hill mused about collaboration as the most important thing. Today, I'll muse on that and his notion of makers-making-made.

If you are not producing working, running, tested usable software in every single Sprint or iteration, you are not [yet] 'doing' Agile, you are not [yet] 'doing' Scrum.

A question on AgileMentoring.com triggered this little article. Perhaps repetition is the mother of something ...

Kate chats with people at the KALE Society meetup. They discuss some small issues and then one big one. Test Doubles come up. Darts are thrown.

A Twitter conversation and some reading has triggered some new, and probably some old, thoughts on estimation and the #noEstimates tag and meme.

A bit of a screed about naming, triggered by a super idea from Dan Terhorst-North.

We're here to discuss whether Agile ideas fit in with fixed-scope efforts. We'll look at Agile values, principles, frameworks, and practices. The answer is that Agile works just fine.

I like to say that I may have invented story points, and if I did, I'm sorry now. Let's explore my current thinking on story points. At least one of us is interested in what I think.

There was a thread on Twitter talking about Agile being anti-management. No, it's much more radical than that.

Sprints, Iterations, Cadences, Continuous Flow. Planning sessions, daily scrums, retrospectives, increment reviews. Are these all, in the end, overhead to be eliminated along the way to some Agile Nirvana?

Scrum is founded in the belief that self-organizing teams can figure out what they need. When true, this is sometimes not sufficient. And sometimes, particularly in software development, it seems not to be true.

Let's talk about what responsibility we have for those who never take a course from us, read our books or web sites, or even see our tweets. I think we have rather a lot.

I wrote this in response to some tweets from an esteemed colleague, who I think is a bit less sensitive to dangerous ideas than I'd prefer our 'thought leaders' to be.

Another little tweet-storm about estimation. I think it's useful and not as easy to use as some people think it is.

I was asked on Twitter what I meant when I said 'Simple, not easy. There's a difference.' I have no idea what I meant then, but here's what I think just now.

Are Imposition and Dark Agile both bad? Yes. Are they the same thing? No.

Some early unfocused thoughts around original XP practices and what I might say today.

I'm not going to define a new framework, and don't think I should redefine XP, as it's not my baby. But I was thinking ...

I tweeted a storm about responsibility when 'Agile' doesn't go well. Here we'll unroll it and say a few more words.

Yesterday, I tweet-improvised the following thread. I had intended to write it up later as an article on my site, and here it is. It received a number of replies and comments, and I'll address some of those here as well.

There's a lot of whinging going on about imposing 'Agile' methods and practices. These whiners just don't know how to do imposition correctly. Me either, but here's what I'd try.

People have been telling me for years that Scrum is not an Agile Software Development Framework. I should have paid more attention. It's still good stuff, though.

A discussion of my personal values in the light of way too many 'well-reasoned' but mistaken notions on diversity.

A chapter from 'Software Development, How I'd do it'.

The above was the title of my talk with Chet Hendrickson at deliver:Agile. I'll update this with a link to the talk when it is published. Meanwhile, here are some thoughts.

I watch The Expanse to force myself to exercise. Today this quote hit me pretty hard.

Where do we place the responsibility–surely not blame–when things don't go well on a Scrum team? Who's responsible for taking action? (A bit of something I wrote on Twitter, lightly edited.)

Just a few words about why I publish all these words, going over and over the same topics again and again, repeatedly and repetitively.

On the Agile Mentoring Slack group, Jack Caine and I were discussing what it means to be Agile. I wound up writing something like this, and wanted to share it more broadly.

I'm not finished ripping Scrum a new one, but I don't want to come off all negative. So let's talk a bit about what I'd like to see done.

We've spoken often before about the backlog. Let's get down and dirty today. Delenda est backlogus or something like that.

If your factory pollutes the river, you're supposed to clean it up. If you plant kudzu to combat erosion, you are responsible for its destruction of everything in its path. If you swallow a spider to catch the fly, and die when you swallow the horse, of course -- it's on you.

The Sprint causes serious problems in many Scrum installations. What are some ways to mitigate those problems?

Let's consider the Scrum Sprint. What's the strongest case we can make against it? It harms people, how's that for a case?

In the spirit of inquiry, fairness, and a generally bad attitude because it's raining, let's consider how strong a case we can make against Scrum. It might be fun.

These articles about hills to die on are in response to a continuing trope on Twitter and elsewhere, to the effect that X is bad, or Y is better than X, and therefore don't do X do Y. These are amusing, provocative, and rather frequently ... mistaken.

When are Sprints a good idea, when not so good? What are their values, and their costs?

Bashing of Scrum (and other methods) is a common form of Internet Entertainment, and not without reason. Some of the concerns are more accurate than others. Choose carefully which hill you want to die on. In this series we'll explore some hills.

There's a lot of noise going on on the Twitter just now, about starting with Scrum, with kanban, or with nothing. Here are some thoughts.

Responding to a mistaken TDD flowchart.

Mike (GeePaw) Hill storified about sense of urgency and an acronym RAMPS. I like what he said and will muse upon it.

I'm wondering, today, whether the Increment could be the driver for all 'Agile' software development.

Today, let's talk about cadence. Iterations, Sprints, to have them or not, that is the question.

I was asked a question about one of today's modern approaches to Agile software development. Here are some general thoughts.

An innocent email question leads me off into wildness and chaos. What's new with you?

What if I were to create a new software development framework? I'd never do that, but if I did, what might I do? Let's find out. Let's talk today about Whole Team.

Terms seem important to me today. (Revised 2017-07-05: Techniques)

Some Notes on the theme "If I were going to create a new framework, what would it be?".

A number of tweets and posts this week point out, correctly, that if we don't think about what we're doing, Scrum and Agile won't work. Apparently people need this reminder.

A couple of things passed by my Twitter last week and I'll try to comment briefly on them. For values of 'briefly'.

Based on our Scrum Gathering 2017 talk, we discuss the impact on real software development of growing focus on the 'enterprise'.

Time was, you got a spec, got browbeaten into saying you'd do it in 6 months, then got mostly left alone for 6 months. Now, they get to **** with you every ******* day!

Good frameworks are deep. Quick-entry courses sell well. It turns out they sell TOO well.

Scrum is good, when done as intended. Otherwise it can be oppressive and dangerous to developers. Let's study: Defense Against the Dark Arts of Scrum.

A twitter conversation got me thinking about the extent to which Agile ideas are intended to support small improvement, or to disrupt things.

Some interesting tweets make me wonder: if I were creating a method today, what would it be?

A foray into Google App Engine turns into a Tibetan adventure with Bos grunniens. No real lesson is learned.

Mike Vizdos and I are starting a new Slack team and we invite you to join us.

Over the past few days, an ancient twitter thread accidentally revived, talking about how you don't need quality code when you're just validating assumptions. What do the ants have to say about that?

Tozier and I did a little work on the ants experiment. Lessons are beginning to be learned.

Tozier posed an interesting problem today, and we decided to work on it at the coffee shop.

I found this picture of a roulette wheel. I wonder how hard it would be to make my little game use it.

Let's finish wiring up our second pass at Jim Jeffries' roulette example, and see what we can see.

I felt I owed it to myself to do Jim Jeffries' roulette exercise, this time with more tests. You won't believe what happened next. (Sorry, I have a click-bait virus.)

Jim Jeffries (no relation) proposed a TDD exercise / challenge. I took it on. The results may surprise you. (Sorry.)

Measure teams by metrics. Because that's how you get Crappy Agile!

I was asked a question via email and liked my answer enough to write it up. I hope you like it too.

Some twitter leftovers got me comparing Scrum and [Kk]anban. Are they Agile?

Some tweets inspire me to write a bit about management in Agile.

Going too far is quite difficult to do.

Bob Martin has published the Programmer's Oath. What do I think about that? The answer may surprise you.

Just some small thoughts bordering on rants. Something here for everyone to get mad about.

It's common to tweet things objecting to high automated test coverage as if it's irrelevant, incompetent, or stupid. I suggest otherwise with a thought experiment.

In which we discuss the technical debt metaphor, bright code, and the inevitable decline of civilization.

Mistakes, I've made a few [thousand], but then again too many to take personally. – not Frank Sinatra

A Twitter thread gets me thinking about Mock objects and whether they're more than just a matter of personal taste.

Let's try this again. The previous article was not clear to all readers. I suppose this is often the case with my work but in this case I thought I'd try again.

At the time of the Agile Manifesto, we all did the best we knew. Here's something I wish we had done. (Revised)

The Backlog is an essential artifact in Scrum. It may also be the root of serious dysfunction.

Generalizing from a few results isn't proof. In this article I'm going to prove that by generalizing from a few results. Wait, what?

Let's look at what Agile-focused individuals can do to improve their own lives, and, through interacting, help their colleagues and their organizations.

In a conversation about religion, I found myself saying something that makes me think about 'Agile'. Trigger warning: includes words like 'Christian'.

I've been a bit disappointed lately by the state of Scrum in companies, and rightly so. But there's another way to look at it.

Chet and I were talking about the importance of the Increment and the Sprint Goal. Herewith, some musings.

You have to either laugh or cry. -- Wm. M. Rogers

One great way to remove an impediment is to replace an old idea with one that's better. Let's give that new idea a new name.

You people could help me by doing a better job and making fewer mistaks.

Kate and Dan estimate a new project. Or do they?

I haz one.

The Estimate-Commitment relationship stands in opposition to collaboration. It supports conflict, not teamwork.

After a lot of email and blogging, Steve McConnell and I "Came out by the same door where in we went".

Many individuals are creating new, marvelous, incredibly valuable Agile contributions. These were inspired by the Manifesto. They are not updates to the Manifesto, they're founded upon it.

In which we search for common ground and disputed ground.

Steve makes some great points. I think I'd make somewhat different ones.

If we can't build software well, all our Agile is for nothing.

A recent Twitter conversation bugged me (and bugged Clarke Ching even more). Here's why.

Privilege. No privilege. Screw it, improve your situation. Or don't. It's up to you.

OK, one more on this bowling thing: I decided I should do some tests.

Scoring bowling is Chet's and my go-to application for demonstrating pair programming and TDD. So here it is in Elixir, without either pairing or TDD. Interesting, though.

A report on building up a payroll pipeline. Twice. And still not entirely liking it.

Let's see whether we can sketch a little payroll. In Elixir. As the title suggests. Expect trouble - I do

It seems like time to experiment with something new. Will it be Elixir? Hold on, this is going to be chaotic.

Apparently the word 'estimates' is not clear. Here's what I mean and don't mean.

You keep using that word. I don't think it means what you think it means.

Slicing is easier and better than estimation for projecting done. And slicing adds value, while estimation does not!

That's all you need. You don't need no more.

A Twitter conversation got me thinking about how often teams or organizations fall away from their process, when it happens, and why.

Theory, Practice, Received Wisdom, Certification. These are not the things that make things work. Good people make things work.

Keep seeking better ways.

Deciding what kind of tests, and what tools, would be good for a payroll series, if I continue with it.

I love computers! Trying to set up Fitnesse and landing squarely on rspec.

Every minute we spend just thinking and talking, and not programming, is wasted!

Chet and I just ran an Agile Skills Workshop last week. It was great fun. We were asked for a description, and here it is.

A brief um discussion about the Increment and how it might help you change culture.

I guess today I must write about the Scrum "Definition of Done", which is neither a definition, nor done. Is it a Scrum Artifact? I'd rather not.

Someone asked about comments on this site. I don't want comments on the site, but I am happy to discuss things, so I've set up a Google Groups forum. Here's some info about the forum.

I had occasion to look at a couple of articles from 2010, and things don't seem to have changed much. Should we be concerned?

All around us, Scrum and Agile are used, misused, and abused. How should we feel about that?

For success with Scrum, we need the basics, our expertise, and to improve our culture. To improve the culture, we need the Product Increment.

Development teams need help using the product increment as a center for making lives better. I resolve to work to fix that.

We're not blaming you when we say you're doing it wrong. We're trying to help you do it right.

We need to make Scrum and Agile safe for software developers. How should we proceed? (updated)

It's not up to Scrum or "Agile" or XP to make you successful or happy. It's on you.

We don't want just a "Product Owner". We want a Product Champion!

Impediments are there to be removed, not there to be recorded for posterity. Drive them out, don't log them in.

There's not much wrong with Scrum. Or is there? It depends what the meaning of 'wrong' is.

They shipped the software, therefore what they did was best. It ain't necessarily so.

Jonathan Rasmusson wrote an interesting article. I agree. It's not about unit tests. It's about skill and understanding.

Giles Bowkett invited me to discuss another article he wrote. For some reason I'm willing to do that.

The conversion from XProgramming.com to RonJeffries.com is essentially complete. Let's look at some learnings.

Many people assert that Scrum fails often. They say it's Scrum's fault. I'm still trying to understand.

Jeff Sutherland said today that it's not done if it's not tested. You won't believe what happened next!

It is my practice to reconsider important topics. Certification certainly is such a topic. Here are today's thoughts.

Giles Bowkett has written some impassioned diatribes against Scrum on his blog. He raises some issues, which I shall try to discuss.

I was reminded by a lovely email of what happened during our SAFe training. Eliminate dependencies, don't document them or accommodate them.

Address given at the final meeting of the Agile Alliance, August 20__, by Ron Jeffries

As Tozier and I work on Scraper, I find the pairing to be quite difficult, though not unrewarding.

XProgramming will transition slowly over to ronjeffries.com. Be there or be square.

Today is a big day for people tweeting how they deplore what other people are doing. Others retweet those tweets. I think that's a fruitless behavior and suggest something different.

This is an NSFW rant regarding the whiny, mewling *bastards* who bitch, whine, and complain about Agile methods, Scrum, and similar topics.

Scrum top dogs announce combined site for Scrum definition.

XProgramming.com needs a new implementation. Want to watch?

XProgramming.com needs a new implementation. Want to watch?

Put makeup on your own pig, make it look as good as you can. Don't go around finding ugly imaginary pigs to stand it beside.

Recent Twitter conversations inspire me to pull out some of my concerns with SAFe and talk about them.

I recently took the SAFe SPC training. My bottom line assessment is that it will be a marketing success, organizations trying it will see improvement, and some will see great improvement. And I don't like it.

Don't buy a brand. Seek out good ideas, and apply them to your situation.

Robert Pirsig's protagonist "Phaedrus" said "Quality is what you like". We talk a lot about "value". My aim here is to suggest to you that value is what you like.

Overcoming the Estimation Obsession

Alan Shalloway blogged on "Big Change Up Front", suggesting that it's not always the best thing to do. This made me think ...

"Why don't you believe in testing?" said Lanette Creamer, the Testy Redhead. Ah, but I do. I care about what, when, and at which end of the horse.

An odd anonymous article on "LearnTFS" purports to debunk Agile by moving closer to waterfall. Interesting, but not quite right.

I've had the privilege of observing He Jinbao, a martial arts master. He doesn't hurry. Maybe we shouldn't either.

Are there places where lower quality has less negative impact? Possibly. Except maybe on your soul.

No one I know can operate at their peak performance all the time. How do we know how hard to work on quality? Same way you get to Carnegie Hall.

You can always find someone to argue for cutting quality corners to "go faster". Is it possible to waste time cleaning code? Sure. Is it possible for code to be too clean? No.

Teams often want to write "technical stories" to cover things like testing and improving the design or infrastructure. There is rarely a need to do this. Here's why.

Alan Shalloway and I were tweeting about whether Scrum could be improved because it doesn't include some damn thing or other. Scrum is working as designed. We and the Alliance need to get to work.

Chet and I will be meeting with both the new and the outgoing Managing Director of the Scrum Alliance. I asked for input on Twitter, and have received some. Here, some thoughts.

"Just tell us when you'll be done with all these requirements" is not how to guide an Agile project, be it Kanban, Scrum, or XP. Not remotely.

Some people have difficulty living up to the values and principles of the Agile Manifesto. Should we improve the Manifesto? Raise your game: we meant what we said.

"His brand is bad: my brand is good." Isn't it well past time we got over that kind of thinking? I'll take a good idea from anywhere. So should you.

Should we ease into Agile, or jump in? How fond of being eaten by bears are you?

Let's consider two "dimensions" of a project, the extent to which it adheres to "Agile" values, and the extent to which it is an effective or successful project.

There has recently been another discussion of Kanban on one of the Scrum lists. Kanban has some interesting ideas, and yet it seems to conflict with Scrum in some essential ways. The problem isn't Kanban: it's the notion of "essential ways".

Agile projects very often seem to stall out after gaining perhaps twenty-five percent of the possible benefit. Why is this? What can be done?

Incremental and iterative development processes provide frequent opportunities for teams to "Inspect and Adapt". What should we inspect? How should we adapt? Is this part of the process?

Object aficionados worldwide are concerned that the procedural bowling solution presented last time is just not robust enough. They want to see how we would make it score the frames incrementally. Frankly I haven't the slightest idea.

Here's the Bowling Game again. This time I'll take a simpler approach, along the lines I usually follow when I do a Test-Driven Development demonstration. The result is strikingly simpler than the preceding 'object-oriented' solution. What does this tell us about TDD and how to use it?

TDD on the Bowling Game (article lost and now found again)