Agile Otter Blog

This is just a little bash script for those times when you know what you want to change, but aren't sure where it is in the directory. fixwhere() {     files=$(grep -ril "${1}" *)     if [ -n "$files" ]; then         vim +/"${1}" ${files}     else         echo "not found: [${1}]"     fi } I use this whenever I have a bunch of text files. It's especially handy when you're working with a markup language. I specifically wrote it to use ' vim ' and the  +/pattern function.  I don't actually know a good way to have it load any ${EDITOR} you use and search for the pattern in that editor. I suppose if the time comes and I need to generalize, I will write a load_search_and_edit () function. For now, it works for me and makes me happy. Cheers.

I write a lot about velocity because people ask me a lot of questions about it.  Here are links to the write-ups I reference most in my daily work -- which I tend to associate to "the things most people need to know." Velocity: Kent Beck's Recommendation 14 Weird Observations About Velocity "Managing" Velocity How to Use Story Points Stop Using Story Points No Estimates Esther Derby answers " Why Not Use Velocity as an Agile Metric ?" Ten part Q and A on Velocity blog series Harmful Metrics What SHOULD we measure then? I hope it's helpful.   A friend published a blog at Industrial Logic on Value-Based OKRs . I wonder if "objective-based" or "initiative-based" is a better term.  I'm not sure what my opinion is here, and I lack experience with them, but I provide the link in case it is helpful to you.

When programmers complain about the "pressure to produce more," I usually describe this as a positive thing. Programmers, managers, software companies, and consumers all want more and better software. It is the basic axiom of our field. When I say "if I could find a way to produce 10 times as much quality software in a day, I would do it in a heartbeat," all the programmers' heads nod in violent agreement. Most of us came to this field because we really like writing programs, solving problems, and making things work.  Learning algorithms and data structures was a small part of the answer, as was learning programming languages and idioms. But the underlying drive is still to make things that work using logic and flow and structure and all the IQ we can muster. We build because we love to build. There is more than productivity to consider in software, such as building the right thing (product management), and building things well (craftsmanship), but produc...

If we want to see a greater theory of productivity , we have to recognize first that software development is thinking.  Once we get there, we need to understand how we can think better. One aid is to have more information  so that we know what to do . In the 1926 book  The Art of Thought , Graham Wallas explained that having an idea (a creative solution) requires four distinct phases or steps: Preparation (gathering of theory and data) Incubation (letting the idea "cook" by doing something unrelated) Enlightenment (the emerging of an idea, or "connection") Verification (determining the validity of the idea) Wallas noted that stages 1 and 4 may take minutes, hours, days, years, or decades. We are primarily interested in those that work on the sub-week scale when programming, but the fact remains that we need to allow the brain to work by feeding it information, giving it some time to process, and then verifying the ideas as they come. Wallas refers to the ...

There are some special challenges with dealing with productivity of knowledge workers. Most of them have to do with the invisibility of the work and the difficulty in managing invisible work. Programmers and testers don't assemble machinery or bend paperclips or mold parts from molten goo. They don't stack boxes or bricks, or swing hammers. The work they do has no physical manifestation, which makes it both hard to observe and hard to understand. I don't blame managers in the 70s and 80s who counted lines of code. It was one of the few visible manifestations of the work programmers do. It was entirely misguided of course, and several of us have experienced net-negative lines of code in consecutive weeks of work (I've even had awkward and unpleasant meetings with managers for "messing up the metrics," ending in an admonition to stop it). Other attempts to make the work visible count data fields on screens and in databases and on reports. This is a bit...

Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand. -- "The Retrospective Prime Directive" by Norm Kerth Software, as Dr. Ralph Johnson informed us, is distilled experience. Writing software, Ray Scheufler reminds us, is a process of making decisions. To make decisions, we have to understand the system we're working in, and the consequences of our decisions. That means that most of the work of a programmer is learning, and very little of it actually involves typing. Understanding any existing body of software is involves understanding the domain,  the user being served,  the specific problem being solved,  the solution chosen,  the techniques of safe software development,  the organization producing the project, and  the technology (language, operating system, network...

Agile is not against documentation. It is merely lean, in that we don't want to maintain piles of documentation that don't actually help us product value for customers. We maintain the least non-test, non-code documentation we can afford. To be minimalist, we recognize that a conversation is better than a whiteboard, a whiteboard a poster is better than a white paper, a white paper is better than a tome -- provided it's enough for us to be able to produce good, working code and collaborate. Here are all the rules I know about agile documentation: If the document is contractually required, of course we do it. If the need is immediate and significant we create a document (UncleBob's law). In other words, we don't build documents in case someone needs them in the future, and we don't draw a document when a conversation or whiteboard will do.  There might be other rules. To date, I don't know them.