Friday, February 13, 2015

The Highway Beautification Committee

The story goes that an old farmer was sitting on his porch one morning. He was looking down the state highway that ran in front of his house, and saw a truck off in the distance. As he watched, one of the people in the truck got out, and picked up a shovel from the back of the truck.  They dug a hole by the highway, and got back in the truck.

A little bit of time passed, and the other person got out of the truck, and picked up the shovel.  They filled in the freshly-dug hole, and returned to the truck.  They pulled forward about 50 yards and did it all over again: dug a hole, waited, filled in the hole, and pulled forward.

The farmer watched these two all morning as they approached his house, until finally they were close enough for him to yell out, "Hey!  What are you two doing out there?"

The first person yelled back, "We're on the Highway Beautification Committee!"

Puzzled, the farmer said, "Beautification?  I don't think I understand."

"Oh, well, the guy who plants the trees is out sick today."

Wednesday, March 12, 2014

PragDave is wrong. And his advice is harmful.

Dave Thomas has posted that "Agile is dead, long live agility."  There's some credibility assumed there, as Dave is a signer of the original manifesto itself, at the famous Snowbirds meeting that spawned it.
He asserts that Agile itself is corrupted, and we should reject the word and all its related practices, education, literature, trade groups, and conferences.

But he's wrong.

These terms (Eco, Natural, and Agile) aren't an excuse to turn off your brain.  You still have to know what Agile (or Eco or Natural) means in order to evaluate that claim.  Expecting everyone who uses a term to use it in exactly the same way is ridiculous.  Changing it from Agile to "agility" won't make any difference or distinction.  The same shady consultants and book writers that create "Doing Agile Right" books and courses will just write "Programming with Agility the Right Way."  The same companies that say "we are agile" while writing four-page user stories won't wake up and say, "oh, our practices don't exhibit agility", they'll continue to say it just the same.  And you'll still have to evaluate their claims, just the same.

But he's not just wrong, he's harmful.

Dave suggests that agile conferences, trainings, and apparently all literature on the subject is counter to the original spirit of the manifesto.  Maybe is is, I wasn't there so I wouldn't know.  But I know that they wrote about teams coming together regularly to tune and adjust their behavior.  If your conference doesn't feel like that, it's a bad conference.  If your training doesn't feel like someone sharing their experiences so that you can use what works, it's a bad training.  If you're ignoring that principle by requiring that your teams "do Scrum by the book", then changing from nouns to adjectives in titles and slides isn't going to fix that.

Rejecting the experiences of others isn't going to make you better at doing agile, being agile, or performing with agility.  His advice to "just do these four things, and build up your experience" while an accurate general guide (that I like), it ignores the fact that he has, himself, taken at least fifteen years to get to this point.  Should we all just derive the fundamental principles of calculus ourselves as well?  Or would it be better to talk together, as a team or as an industry, about what works and what doesn't?

He talks about "protecting" the word agile -- there is no practical way to do that, unless you want to trademark the term and sue those who use it in a way that you don't approve of.  But I get the sense that Dave isn't a big fan of the Scrum Alliance either.

So what do we do?  We keep being leaders, we keep sharing what works, we keep pointing out when the emperor or alliance has no clothes.  What we don't do is mess around with meaningless semantics, and in the process reject an entire community and network who, on the whole, has changed the industry for the better and continues to push the envelope.

Sunday, August 25, 2013

How to get stakeholders addicted to attending demos

Do one of these characters sound like your business stakeholders?

Waterfall Warrior:  "I don't have time to look at mid-sprint demos, it's not like anything changes if I do."
Optimistic PO:  "I don't need to take time to look at the software mid-sprint, I already wrote down what I want."

The Waterfall Warrior is carrying the perception of non-agile projects -- all changes go through the Change Board, whose middle name is "Denial."  Attending early demos is just a waste of time, as the news (bad or good) is the same whether she hears it every week, or just once at the end of the sprint.

The Optimistic PO believes in your team's perfection -- maybe too much!  They don't yet see the problem that their original docs are full of ambiguity.  

Both of these are a contract negotiation model.  How do we get them to participate, and as the Manifesto says, favor customer collaboration over contract negotiation?


Have your mid-sprint demos in a very warm room, and as they enter, secretly put a nicotine patch on them, and remove it when they leave.  Eventually, they will become trained that early demos deliver a mild euphoria.  If a few days pass with no demo, your stakeholders become anxious, and jittery.  They come to the Scrum Master and ask, "Hey, can you give me a demo?  I could really use a demo right about now."

There's one problem with this solution: it's felony assault.  A better idea is to find something more addictive, and easier to deliver. 


Saying "yes" to changes, with small or zero change in the cost, is like crack cocaine to stakeholders.  But how do we magically make changes cheap or free?  Timing.  Typically work that is recently created is the cheapest to change.  It has nothing built upon it, no disruption cost, and if we give preliminary demos before costly activities like final QA, less rework cost.  Try to put yourself in a situation where you're often saying, "Yes, we can change that.  No, it's not a schedule impact, I just build it this morning."

It's the role of the Scrum Master to help the team move to this "right time", but also to highlight with some fanfare what just happened.  Enthusiastic personalities might say, "Wait, say that again?  We just found a change and are going to do it, with no project impact?  That's great!"  You could say "groovy" here, but that's probably stretching the metaphor.  Regardless of your personality, it's the role of the Scrum Master to be sure that the stakeholder realizes that this is different than it has been before, and it's not just luck.  It's a result of their attendance.  Done properly, a few days later the stakeholder will come to the Scrum Master and say:

"Hey man, you got any demos?"

Friday, December 21, 2012

Scalatron: The best language tutorial / learning environment ever made

Let me expand on how great the Scalatron initial experience has been.

Scalatron has this fantastic introduction in several steps.  Each step produces a bot that does something, and by pressing a couple of buttons in the in-browser UI, you can see it work as well as tweak it yourself.  Here's a screenshot:

On the left is the tutorial, in the middle is the code, and on the right is the sandbox that allows you to actually see your little 'bot running around, limited to what it's allowed to "see".  All this is regular in-browser stuff, no plugins.  And the highest praise I can give it is that it "just works".  Edit the code in the middle, press 'run in sandbox' and it does.  Compile errors?  The build step pops up an error box at the bottom with line numbers.  Smooth.

And then the interaction with the tutorial:  Every block in the tutorial has a "load into editor button" drops the code directly into the editor pane.   Which means no copy/paste errors, and it works in blocks, so if you're working on the missile-launching section and you messed up the movement section with a half-baked idea, the tutorial lets you reset just one part.  This is really polished, catching use cases like, "you asked to load it into the editor, but you haven't saved the work there.  Save first?"

The tutorials were the foundation of the thoughts and opinions on the language that you can read in my previous post.  They take you through the major language features by introducing real problems you need to solve: how do I parse a string?  How do I re-use a function?  What are vars and vals?  None of it feels contrived just to make a point.

And this IDE has room for growth.  There's a little [<<] button on the tutorial that lets you take of those training wheels, and continue on with your bot development.  Save your work, give it a label, and load it into the Scalatron battle instance that loaded up when you started Scalatron.  Instant gratification.

The one complaint I have is that it's not very clear from this IDE how to restart the tournament without restarting the Scalatron process, which is running your IDE is running the tournament.  It doesn't always interrupt the IDE, but when it does...

I do have one complaint, and that's that there's no way to do TDD with it.  That's a show stopper for me, if I write too much code without a test I start to get physically ill.  So now it's time to get a Scala environment up and running.  This has often been the stopping point for me in other languages/environments as I really have very little patience for cobbling together build scripts or downloading disparate parts.  More on that in the next post.

Thursday, December 20, 2012

If Socrates was a Scrummaster

This blog moved to my company's site:

Thanks for reading!

Wednesday, December 19, 2012

Getting Scala with Scalatron

I've always liked Scala, but like many of my early dating experiences, it has been from afar... wistfully looking at Scala projects on github, thinking that one day I'd take the plunge and ask one of those nice projects out.

Then I found a geek that was easy for me to connect with: Scalatron.  Here ends the dating analogy.

Scalatron is a framework for writing competitive AI bots that compete in an online arena.  But Scalatron is also super easy (hey, the dating analogy is over, remember?).  Download the zipfile, extract it, type java -jar Scalatron.jar and jump into the very nice tutorials, and get quick visual feedback on the code you're writing.  Plus, it's fun and you can kill stuff.

Scala's Goals

Scala's goals remind me a lot of Java's goals when it first came out.  Java was a Real OO language, where everything is possible (mostly), but the easiest way to do things was the OO way.  At least as compared to C++ or interpreted languages at the time.  I think it's maybe being eclipsed by C#, but that's a different article.

Scala's goals are to be a Real Functional language where everything is possible, but the easiest way to do things is the Functional way.  So it has all the tools to make it really obvious when you're being non-functional.  val vs var, for example really prompts you to say, "Hey man, why you gotta go and make this mutable?  You trying to make problems for yourself?"

And it wants to have a type system that doesn't get in the way, or leave you in the dark.  This addresses my big complaint with dynamic languages.  Dynamic languages are nice right up until you're working with unfamiliar codebases, which unfortunately is immediately.  The Ruby framework routinely made me upset by having no types defined at all, not even named.  What does this method take?  A hash.  Ok, not helpful.  So I open up the code and ask, "what does it do with that hash?  Oh, it passes it to another method.  great."  And pretty soon you figure out that it's hashes all the way down.

"But Kevin!" the dynamic programmers say, "That's the flexibility!  You can pass it anything, that's the point!"  Anything?  Yeah, what if I pass it some drek?  Will it like it?  I suspect it won't be good for either of us.

Type Inference to Tuples

The middle ground.  Strong types and a compiler that cares (vs leaving us to write unit tests to do what a typing system could do for us) but no more of Collection collection = collection collectioncollectioncollectioncollectioncollection.  It's interesting to work with a type inference system, because it's such a perfect window into why we had no inference before.  I find myself looking around the code saying, "Wait, what type is this again?"  The compiler knows, but I don't.  It's like one of those logic puzzles that is 10 steps deep in transitive logic.  And if I were writing code in vi or something, it would be a pain.  But I don't do that anymore.  I'm not using an IDE right now, but I'm sure that will be my main way of working, and I have full confidence that the Scala IDEs will let me hover over something and see its type.

But Functional programming's no side effects rules means that you're frequently going to have multiple return values, which in many languages generates a lot of types.  But this is Functional programming, so Tuples are built right in with both type inference and static constructors to keep the code from being redundant.  Syntactic sugar?  That's a funny way to spell 'readability'.
val myTuple = ('something','somethingElse')
Except I do have a complaint:  _1 and _2 aren't particularly good names for the contents of a Tuple.  Time will tell if this is a problem, but I suspect it might be.  The typing system will tell me I get three strings, but what are they?  There's some more syntax so that you can assign things directly to meaningful names, which is nice:
val (firstName, lastName) = someTupleReturningFunc()
But how did I know what that function did in the first place?  Especially if it's cleverly passing tuples from its component parts?  Ideally I'd like for the API to be discoverable, and type information isn't always enough.

I guess at that point you create an object (via Scala's object keyword, which is distinct from class) and give everything proper names.  I read online about using a case class to extend a tuple, which looks nice but apparently has some real complications.  I'm just a novice, of course, perhaps there's a better solution still that doesn't fall all the way back to making pojo beans.

The first touch that I have with real Functional programming is almost always with some kind of mapping function.  And that's even the famous Function Heard Round The World, Google's MapReduce.  I like how it looks in Scala, returning a Tuple for a given input.

No return statements?  What about readability and accidents?

And here again is an "aha" moment for me.  The Scala 'way' is to have no return statements.  This is an element of consistency when looking at quick function definitions.  And Scala, like Javascript, loooves functions.  And if most functions are going to be one-liners, having a return keyword in there is just clutter.  So the quick-closure definition of a function doesn't use the return keyword.  And neither should regular functions.

Language Habits: names for everything

I can see that my Java habits are going to give my initial Scala code a strong accent.  Like the charming Eastern European habit of dropping articles like "a" and "the", I'm going to probably name lots of stuff that I don't need to in the beginning.  Right from Scalatron's example:
val rest = tokens(1).dropRight(1)               
val params = rest.split(',')                    
val strPairs = => s.split('='))    
val kvPairs = => (a(0),a(1)))   
val paramMap = kvPairs.toMap       
That's familiar code right there.  But we don't need all those names, technically.  The way all the cool kids are doing it these days is this:
val paramMap =
    .map(a => (a(0),a(1)))

Get off my lawn!  I mean, uh, what a charming way to string everything together.  But what it represents here is the Functional point of view.  These are all simultaneous operations we are invoking on the original value.  The intermediate names aren't useful.  I have to admit I'm not convinced.  But then I can't explain to my Lithuanian friends why "a" and "the" are important, either.

Function scoped Functions

And hey, if we're going to have functions that we pass around like variables, there's no reason we can't have locally-scoped functions is there?  In fact, this is pretty key.  In OO, methods exist to change the state of the object.  So we had only a couple of levels of visibility of methods.  If you felt like you wanted to hide some methods from some other methods, this was a pretty good hint that you actually need to divide the object into parts.

But now we don't usually have state to deal with, and we're going to be using a LOT more functions.  So there you go, dawg.   

Objects vs Classes vs Case Classes.

This distinction seems a little fine on first blush.  First, terminology.  Just like in Java and other OO languages, objects are things that are instantiated, and classes are definitions and names for things that you may choose to instantiate (or not, I suppose).  And Case Classes are a special thing that ... some people apparently hate.  I think that's where I'm going to have to pick up next time.

Friday, November 30, 2012

Real Discoverability

An important aspect of languages and toolkits is discoverability. The ability to answer questions like:

What other code (including display code, configuration) uses this method/class?
What code or behavior does this configuration option reflect?
Where is this text displayed?
Where is this data from this DTO used?  What business logic does it impact, or is it just display?

This is a property that dynamically typed languages can lose as a result of that dynamic typing. (That's not to say that statically typed languages preserve it in all, or even most, cases -- more on that later). One way to think about it is to compare the difference in result to searching for string matches on "getName(" and comparing that result with the reality of the codebase.  Some problems will include:

False positives: the text search picks up calls to methods on other objects that happen to have the same name
Stupid false negatives: you need to be a little sophisticated to get both "methodName(" and "methodName (" etc.
Method overloading causes more problems: If you're looking for the method that takes a string, not the one that takes a Customer, that's tricky to do by text searching alone. You'll have to go through them by hand.
Metaprogramming totally wrecks your string search. Assigning the method to a variable then passing that off to something else to be executed hoses your text search.

Statically typed languages aren't a whole lot better, actually. As soon as you add an interface, you've abstracted the call to the method. Even though it's a useful abstraction, you can't tell what happens in practice. And static languages' reflection attributes wreck things as surely as function pointers.

What if the virtual machine recorded things for you, and piped that data back to your IDE? Assuming you're running this in either production or a test environment that has good coverage, that could make it clear what paths are frequent and what sections are never called -- in production meaning they're unused, and in test code meaning untested. For example, a Ruby IDE could use this to generate many of the features of statically typed langauges, like automated refactoring, and to the point of this article: call hierarchy discovery, without all the headaches above.

This same approach might be viable at the framework level. Rather than trying to derive from the code and the configuration where data is displayed, use testing or production to record it in practice. The former is like proving code correct -- technically possible, but very very difficult. The latter is much like the real-world testing we do: rather than trying to construct a proof of correctness of the button, just push the button and see what happens. In this case, we record what did happen and use it to inform the rest of the system and our tools.