Skip to main content

Posts

Showing posts from 2012

Slicing Pie (Review)

I had the opportunity to review a copy of Mike Moyer's Slicing Pie: Funding Your Company Without Funds. Having worked at a number of startups at various stages,  I  was interesting in the insights this book gave into evaluating the value of and managing equity shares in an early company, before a company is making money, and before you have investors.

This seems like a book anyone involved in startups should read. Entrepreneurs can benefit from a reminder about the value of trust and fairness in dealing with those who join the company to help realize their vision. Those who join startups (even in later stages) can gain insight into the issues involved in bootstrapping a company. Anyone who works in small teams can gain insight into the psychology of motivation and compensation in team working to realize vision. This is a quick read, and the author uses frank, conversational language to explain the importance of fairness in dividing equity among founders.

The underlying concept is …

Groovy Dependencies, Grape, and Firewalls

Groovy is a powerful and fun language. One of the nice features, particularly useful for internal tools,  is the ability to deliver scripts that are self contained with the only pre-requisite being that you have groovy installed. One of the tools that enables this is the Grape dependency management mechanism. Using Grape, rather than delivering a zip file with all dependencies, or requiring that modules be installed as part of the global system installation, you can add a line like this to your script:

@Grab(group='org.springframework', module='spring', version='2.5.6')
This will grap the dependency into a local repository if it is not present already. It makes the startup time for the first run of a script a bit slower, but it also greatly simplifies the delivery of short, script-based tools.

If you are in production environment behind a firewall, you might find that that this mechanism doesn't work because you can't access the public repositories. Yo…

Automation

I recently wrote a short article on on StickyMinds.com about automation. After it was published I came across another related post by Jim Coplien which makes the point that automation should come after you have figured out your process.

I'm not sure that Jim and I disagree in principle on anything related to when to automate, but I wanted to make one point. I think it's important to start out an process that is likely to be automated with the idea of automation in mind. If you don't, you are likely to make decisions that are both not important to getting your work done and which would make automation harder to implement.  As I've said before in the context of deployment, the sooner you consider your constraints the easier it will be to build a system that addresses your real problems.

The hard thing is identifying which "requirements" are there out of expediency (or perhaps laziness) and which are there out of need. Having an iterative approach to any kind of…

Problem Solving: Deadlines and Context

One of the more difficult challenges people and teams have in the face of deadline pressure is taking time to consider how to approach a problem rather than just diving in with a solution approach that you know will work.

In college, when I was taking a devices and circuits class,  I found myself stuck on a problem on the first problem set of the semester.  I asked an upperclassman for help and we determined that the problem could be solved by setting up a system of something like 12 equations, and grinding through the process of solving it. His solution was correct of course, but I wondered if this approach might be more complex than it needed to be given that it was  for one of a number of problems in the first problem set of the course, and given that the theme of the first few classes was more conceptual than about doing calculations .

When I later saw the solution to the problem it turned out that by making some simplifying assumptions, the 12 equations reduced to 2, and the sol…

Patterns and The Storytelling Animal

I had the good fortune to be involved in the early days of the Software Patterns.  In brief, patterns are about capturing solutions that people have developed organically over time, which have proven to be the best ones for the context at hand. What's interesting about patterns to those who are used to more academic approaches to learning about software,  is that a good pattern isn't novel. If you've been working in a domain for a time you are likely  to recognize solutions you have used before. If you've struggled with the problem in the past, you are likely to appreciate that the "common solution" is now documented.

By writing patterns, and hanging around people who studied and and worked with patterns, I learned to appreciate that the value of context: it's not enough to have a toolbox of solutions; you need to understand which solution makes sense given the specifics of your problem. In that way, Patterns fit into a set that includes agile engineering…

Have the Orders Changed?

One of the great things about being a parent is that you have an excuse to re-read some classic books. My five year old and I have been reading The Little Prince, and the story of the Lamp Lighter reminded me of a common problem teams have with organizational inertia when trying to transition to agile software development.

For those who haven't read the story, or who don't recall the details, the Little Prince relates the story of his journey to various planets. One one planet he encounters a Lamp Lighter who lights and extinguishes a lamp every minute, not having any time to rest. When the Little Prince asks how this absurd situation came to be, the Lamp Lighter discussed this with the Little Prince:
"Orders are orders..." "It's a terrible job I have. It used to be reasonable enough. I put the lamp out mornings, and lit it after dark. I had the rest of the day for my own affairs and the rest of the night for sleeping."  "And since then orders hav…

Paper v Electronic Dashboards: Goals and Values

It's almost a matter of dogma that, for agile teams, low tech project tracking tools and artifacts are superior to electronic ones. The usual reason you might hear for preferring a physical task board to an electronic issue system are are that a physical task board is more visible and encourages communication and collaboration. I appreciate this, and have seen it, but I've also seen teams do well with issue tracking systems. From time to time I see a discussion of this "physical v electronic  tracking" issue and I find myself frustrated by it, but not sure why.

Reading Scott Kirshner's article Incubating ideas from the rank-and-file in the March 4, 2012 Boston Globe led me to think more about this. The article is about the value of listening to people in your organization when seeking ways to work better. This in itself seems aligned with agile values. In particular, this quote caught my eye:
Many of the ideas presented were dazzling. And almost every one sprang …

Kanban

I've worked with Scrum for a while, having gotten my CSM certification in 2005, and I've spent time both before and after that trying to learn what I could about Scrum, agile, and Lean, both in the context of software and out side of it. After absorbing bits of information on Kanban informally, I decided that to was time to read a book on it. I read David Anderson's book Kanban: Successful Evolutionary Change for Your Technology Business.

Anderson's book was a good introduction to Kanban in practice. It had a mix of stories, theory and guidelines that gave a good sense that the content of the book was based on practice. My only reservation about the book was that while it was well written in many spots, there were places where it was a bit less focused that I would have liked. But if you are willing to skim through the less tight parts of the book, it is worth a look. Here are some of the things I learned while reading Kanban.

Before I read about Kanban in detail my in…

Do we care whether it's Software Engineering or Craft?

Much like a tenet of agile software development is that "planning is more important than the plan," there are some questions about software development that are useful to explore, even if you can't suggest a good answer. One of these these is whether what we, as software developers do, is (or can be) engineering.

I was talking with a colleague about a comment someone made about a post about lessons that software engineers can learn from artists. In this comment the poster raised an issue that comes up a lot when someone uses the phrase "software engineer." The question was, in essence:

Is what we do when we build software "engineering" or "craft?"
My colleague, who has a background in Naval Engineering and who is engaged to an Electrical Engineer (who designs and builds hardware) suggested that the difference is that one rule of thumb might be:

It's engineering if you need to use calculation (about physical constraints).
An example was tha…

Agility (and Learning Opportunities) Everywhere

People often ask "can I apply agile methods to something other than software development?" Since the basic appeal of agile methods is to acknowledge uncertainty by planning in increments, evaluating where you are relative to the plan and other forces, and planning the next increment, it seems like there should be no obstacle to following an agile approach for any project. The lurking question many have is "but can my type of project really be structured in an incremental way?"

While in general, I tend to believe that the answer is "yes," it's always good to have examples. So I was intrigued to head a segment on the radio show Living On Earth, where the rapper Baba Brinkmann described his approach to developing The Rap Guide to Evolution as "Performance, Feedback, Revision," which is a very concise way to describe an agile approach. This meta-aspect of this also intrigued me, as Brinkman used the performance, feedback, revision theme in the e…