Skip to main content

Posts

Showing posts from 2011

Questioning before Answering

The other day I came across a short video in which a parent is faced with answering a unexpected question posed by her young child. I found this video amusing because, being the parent of a kindergartener, I expect to be faced with many awkward moments like this in the future. I also found it an interesting metaphor for software requirements gathering.

In the video the  parent could have answered the question a whole lot more simply has she just asked taken a moment to try to understand what the real question was, and not taken the question at face value. (I'm being purposely vague at this point in case anyone wants to watch the video.)

Most of us have been on projects where much effort has been spent in an attempt to solve a customer's stated problem, only to discover that that either:

The program didn't actually solve any of the customer's real problems.The team didn't solve the problem that the customer wanted solved.There was a much simpler solution. I'm not…

SCM Tool as Collaboration Tool

A few weeks ago I had the opportunity to give a virtual talk at a product launch for an SCM Tool vendor.   The theme of the talk was basic branching strategies, and preparing for the talk led me to reflect on what  Brad and I wrote in the SCM Patterns Book. This post is based on those thoughts.

When Brad Appleton and I wrote Software Configuration Management Patterns I wanted to focus on how to use Software Configuration Management and Version Control  to improve productivity and collaboration.  In many organizations SCM processes, procedures, and policies are focused on stakeholders other than those who rely on the system most: developers.

A good SCM process can help you to work better as a team, and help your team be more agile. An ineffective one can slow down development, and be an obstacle to progress. Likewise the tools you use, while secondary to the decisions about the way you work, can affect how effective your SCM process is.

Tools are important. A good SCM tool helps you …

Definitions

The other day a colleague use the phrase open interval to refer to time periods that included their endpoints. This didn't sound like the definition that I'd learned in analysis class, which I will admit was not my favorite subject in grad school, so I searched for a definition and found:
An open interval is an interval that does not include its end points. This led to a brief, but interesting, discussion about why my mathematically-minded colleague flipped the meanings. It came down to the feeling that the definition didn't make sense in terms of common english usage (when you open a door, or a group, for example, you're being inclusive).

Definitions add precision, but when you use words that have meanings in multiple contexts, you can find yourself in confusing conversations. Consider a term like normal, which can be defined as:
a lack of significant deviation from the average This sounds pretty benign, but people often carry around more that just definitions when th…

Refactoring

Frank Buschmann wrote a 2-part article in the July/August and September/October issues of IEEE Software that covered an important aspect of software development: refactoring.

Yes,  you'll hear the word "refactoring" spoken often in any development team, but most developers rarely discuss what refactoring is, and whether they are refactoring or doing something else, like "reengineering" or even re-writing.

I won't repeat what Frank said, as he said it quite well,  but as I read the article I realized that there are some points that get lost in many teams and are worth emphasizing:

Refactoring does not mean "any kind of changing." It means changing the structure of existing code to preserve functionality. In principle you are making the code "better."To refactor you need a way to validate that you have preserved functionality. Automated tests are probably the best way to do this. I suggest that you can't refactor without having a test …

Agile or Not: How to Get Things Done

Agile software development always felt intuitive to me. Developing software incrementally, in close collaboration with the customer is the obvious way to deal with the uncertainty inherent in both software requirements and implementation. The technical practices of automating necessary but time consuming tests, and deploying, early and often are the obvious ways to give an team the ability to evaluate the  functionality you have and to to decide if the software works as expected. And it's also important to decide if what you built still makes sense given the current environment. Agile isn't the only way that people build software, and it may not be a perfect approach, but it's one of the best ways of dealing with a system that has unknowns.
Agile software development acknowledges uncertainty. The ability of agile methods to make it very obvious very quickly when a project, or even a process, is failing makes people uncomfortable. The visibility of the failure leads to a de…

More on Being Done

Continuing the conversation from last week, Andy Singleton followed up on my post on being done with this post. Which is good as this is one of those questions that sounds simple in theory, but in practice contains some subtlety.

While I was advocating a good definition of "Done" to enable you to measure progress along a path, Andy's point seems to be that many teams don't establish enough of a path. He says:
In my opinion, most agile teams aren't doing "Test Driven Development", and they aren't doing scrum iterations where they plan everything in advance. Instead, they are doing "Release Driven Development." They focus on assembling releases, and they do a lot of planning inside the release cycle. This is probably true in more cases than not, though one could argue whether if you are not doing iterations or TDD whether you are, in fact, doing agile. But even if can concede (which I'm not sure if I am) that you can do agile without p…

Being Done

Agile New England (which used to be called the New England Agile Bazaar, and which was started by Ken Schwaber) , has this wonderful activity before the main event each month: they host Agile 101 sessions, where people who know something about agile lead a short (30 minutes) small (about 10 people) class on agile basics for those who want to learn more about some aspect of agile. From time to time I lead a session on Agile Execution, where the goal is to help people understand how to address the following questions:
How can software and other project elements be designed and delivered incrementally? What set of management and technical practices would enable this?How do you know whether your Agile project will complete on schedule? When I lead the sessions, I tend to focus on tracking, defining stories in terms of vertical slices and the importance of continuous integration and testing to making your estimates trackable. Since the classes are so small and since the attendees have diver…

Continuous Learning, Coaching, and Learning from Others

There was an article in the Boston Globe this week by Scott Kirshner: Staying Competitive in the Workplace that emphasized the importance of keeping your skills up to date.

It's a short article and worth a read. Some of the activities Kirshner suggests are similar to those Atul Gawande makes in the appendix of his book Better: A Surgeon's Notes on Performance.

Related to this theme is a New Yorker article by Gawande, Personal Best,  on the advantages of challenges of engaging someone to coach you in your profession. I continue to be amazed at how much I'm learning from Gawande, a surgeon, about how to be a better software engineer. I suspect that I first realized this when I started learning about Patterns. (The short post, The Pattern Technology of Christopher Alexander by Michael Mehaffy and Nikos Salingaros discusses how an architect influences the software development community.)

Maybe the common theme of all these writings is that it's important to be ready to lear…

SSQ Article on SCM and Tools

I recently was interviewed for an article  on SCM and Tools that Crystal Bedell wrote for Search Software Quality. Updating tools and processes key to overcoming SCM challenges is brief, and makes some good points about the relative value of tools compared to understanding what you are trying to accomplish with your process.


The best SCM tool, from a day-to-day perspective is the one that is the most invisible to developers, and the best tool really can't help you much if you have a process that just makes it hard to collaborate. This article was also validation that trying to be too agnostic when Brad Appleton and I wrote the SCM Patterns book was a good idea. While some tools make some practices easier, a tool can't replace having an understanding of the reasons to use (or more important, not use) techniques.

Read the article, and if you want to learn some basic SCM practices read the book. For those who want a very comprehensive discussion of branching (which seems to be, f…

Thoughts on The Lean Startup

I had the opportunity to get a review copy of The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses by Eric Ries. I learned a few things from the book, but the most surprising thing was that what, on the surface is a book targeted at business people, entrepreneurs in particular, actually had a lot to offer developers and project and product managers who work at all sorts of companies. In addition to reviewing many of the lean principles and practices familiar to anyone who takes agile software development seriously, this book also makes a case for how practices that work for developers (like testing) also make a great deal of sense at the business level. To be sure the tests are different, but the idea of having measurable expectations is something all agile developers who have written a unit or integration test should be familiar with. Eric Ries shows how this same approach makes sense for determining the direction a busi…

Why SCM Patterns is in Patterns Format

I recently had an opportunity to speak to an undergraduate software engineering class. The professor for that class, Danny Dig has a very interesting practice of asking practitioners to speak to the class over Skype when an appropriate topic presents itself. Danny invited me to join then when they were discussing software configuration management and version control.

During the session Danny asked me why we used pattern form for the material in  Software Configuration Management Patterns: Effective Teamwork, Practical Integration was in pattern format. At the time I might have quickly answered that I was interested in patterns and the book was based on patterns we'd written. But aside from being a too flippant, and not terribly profound. that answer isn't actually right.


There are two aspects of patterns that make them well suited for software configuration management practices, especially those at a team level:
 Patterns describe things people have done successfully, and we wa…

Experience and Learning

In the past few months I've heard a couple of stories about (in effect) the disadvantages of experience when it comes to innovation and productivity. A Story on WBUR on July 5, 2011
discussed how venture capitalists tend to favor young entrepreneurs, as having never learned the wrong things in business they don't know what's possible or impossible.  In one quote a VC said:
One thing I love about these people is they don’t know what they don’t know. They don’t fear failure. They don’t mind risk...
A March 6, 2011 story on NPR on the pros and cons of raising the retirement age made reference to to an article in Foreign Policy which asserted that younger workers have advantages in the workforce since they learned more recent technology in school.

While new skills and new perspectives can add a lot to a team, is the best way to get these skills to simply hire people who know only what they learned in school? Is anyone you know who is a successful, productive, software developer…

Happiness and Agility

Agile development practices at their core, have a common theme of making better use of the time spent developing software. This starts at the project level and continues down to the developer day-to-day-activities. Consider an agile iteration. The team starts the iteration with a clear sense of the priorities for the sprint, and pretty good understanding of the project scope.  Having estimated and committed to getting the work done,  the team also has a sense that the goal is attainable. The team members then collaborate to get the work done as a team.

While we can see how this might make for an efficient delivery process, consider how agile practices relate to enjoyment and morale on the team. In the paper If Money Doesn't Make You Happy, Consider Time,  Jennifer Aaker,  Melanie Rudd, and Cassie Mogilner discuss five principles for spending time in a  happiness-maximizing way. Some of these seem like a bit of as stretch, but there is a lot to be said about the relationship betwee…

Specialization, Generalization, and Effectiveness in Software Teams: Clinical Metaphors

I was thinking about the relative value to a team of a developer with specific skills (say UI development) versus adding someone who was more of an end-to-end developer. Two stories about medical practice that provided some insight into the question.

I recently read Better, Atul Gawande's book about improvement in medical professions. In this book he relates a story of a clinic in rural India that is poorly staffed and funded, and where doctors manage to successfully perform procedures that are outside the realm of their training. They are able to practice these skills effectively and saved lives.

A story on This American Life, discussed a doctor  in Kermit, Texas who practices in areas beyond his stated training, with poor results. In the end nurses who worked with the doctor filed complaints against him for mistreating patients. This doctor worked alone, and collected information from questionable sources, and ignored the availability of better qualified resource near by.

In bot…

Tips, Habits, Customs and Agility

I was listening to a Planet Money Podcast about tipping recently. According to the story, the custom of tipping has persisted even though the reasons that the practice was established no longer apply. According to the Planet Money story both waiters and customers think that tipping is useful, evidence to the contrary aside. The discussion led me to think about practices some teams do in the name of following a process.

Habits and routines are useful because they free you to focus on the important tasks.  Rituals and processes take a somewhat irrelevant decisions out of your hands, and conventions make it easier for others to understand code and other artifacts.  And when you are starting a new approach to work, following the rules by rote can help you understand the method. But circumstances change, and when the reason for the ritual has changed, there are a few possibilities:

The practice is still useful, for reasons you didn't anticipate when you started it.The practice adds less…

Better: More Parallels between Medicine and Agile Software

I recently finished reading the book Better: A Surgeon's Notes on Performance by Atul Gawande. Having read The Checklist Manifesto: How to Get Things Right  (which I commented on earlier) I expected to learn not just about medical practice, but also about parallels between medicine and software development. Much of what Gawande says about performance in medical environments has can be said to apply to agile software teams, in particular, the need to focus on core practices, the value of retrospectives, and the value of generalists.

A discussion of how hand washing, a simple technique that is vital to infection control but that also requires culture change to implement with the discipline required to be effective, brought to mind how the challenges teams have being agile often center on the challenges of having teams begin to apply basic practices, without customization.

In the discussions of Polio vaccination and malpractice were excellent non-software examples of how we can benefi…

Displaying Build Numbers in Grails Apps

Being a fan of Continuous Delivery, identifiable builds, and Continuous Integration: I like to deploy web apps with a visible build number, or some other way of identifying the version. For example, having the build number on the login screen for example. In the Maven/Java world, this is straightforward. Or at least I know the idioms. I struggled with this a bit while working on a Grails app,  and wanted to share my solution. There may be other, better, solutions, but the ones I found approaches that didn't quite work they way that I'd hoped.

My requirements were:
To display a build number from my CI tool, where the number was passed in on the command line. In Bamboo, for example you might configure a grails build as
-Dbuild.number=${bamboo.buildNumber} warTo only change build artifacts and not any source files.To not misuse the app version, or change the names of any artifacts.To be simple and idiomatic.I realized that that Grails itself changes the application metadata (appl…

Recent Writings (Dev Ops and Testing)

I recently wrote a couple of articles that might be of interest to those who read this Blogs.

On Sticky Minds.com, (a TechWell community) I wrote about unit testing, and how to overcome the inertia that stops people from testing in The Value of Really Dumb Tests

I also wrote an article for  CM Crossroads that gives an overview of DevOps.

If you read the articles and find them useful (or not) please comment here at the article site.