The Five Whys February 5, 2010
Posted by mdenomy in Agile.2 comments
I have recently been pointed to a great blog called Startup Lessons Learned. There are some great posts on product development, Agile practices, hiring practices and tips, and TDD, some of which have made me rethink how I go about my day and the practices I employ. I highly recommend giving it a look.
There were a couple of posts on a practice called the Five Whys, which comes out of Taiichi Ohno’s book Toyota Production System. The first post is about the Five Whys and what they are meant to accomplish, and the second is on how to actually run a Five Why’s analysis meeting.
I am very eager to start applying this technique. I am fortunate enough to be working on a really great team that has the maturity to avoid turning the five whys into a blame game. I am sure it will take some practice, but I am interested to see what comes out of it. If anyone has used this technique and has advice or stories to share I would like to hear them.
I’ll let you know how it goes.
PyCon on the Charles – Part I January 21, 2010
Posted by mdenomy in Python, Unit Testing, mocking, mocks, testing.add a comment
I have been doing some work with Python the last few months and recently joined a Python Meetup group in Cambridge that had a meeting last night at Microsoft NERD. The purpose of the meeting was a chance for some people who are presenting at PyCon to do a dry run on their presentations. The meeting was called PyCon on the Charles – Part I
This meeting definitely met my one good thing rule, in fact I thought all the presentations were interesting. There were three presentations
- Python for Large Astronomical Data Reduction and Analysis Systems by Francesco Pierfederici
- Python’s Dusty Corners by Jack Diederich
- Tests and Testability by Ned Batchelder
Francesco Pierfederici talked about how he uses Python in “Big Astronomy”, particularly for the LSST project. The code base they are using has a pipeline framework that I am interested in looking at. There is a lot of simulation that needs to be done before building a large telescope and the supporting computing infrastructure. Most of the high level code is developed in Python, with the computation intensive code written in C.
I was most interested in the Ned Batchelder’s Tests and Testability presentation because I am interested in the tool support for testing in Python. He presented techniques to using mocking to make your code more testable, as well as ways to structure your code to support dependency injection. The mocking framework was Michael Foord’s mock.
I would have liked to have seen more emphasis on addressing testability early in the development cycle. As a proponent of TDD, I think you need to begin testing as soon as you start developing. In my experience it leads to a better design through loose coupling and you avoid having to make a major refactoring to put in test hooks after the fact. I think Ned did a nice job presenting the techniques and some of the tools available in Python to make testing easier and with better coverage.
All in all, an interesting evening and if you are a Python developer in the Boston/Cambridge developer you may want to join up. There is a follow up on scheduled on 2/3/10 called PyCon on the Charles – Part II where there will be three more practive presentations for PyCon.
And once again, kudos to Microsoft for making their space available for different groups. This is the 4th event that I have been at in their space and exactly none of them were Microsoft specific. I think having a space where developers can get together is something that has been sorely lacking and they deserve credit for trying to make that happen.
One Good Thing December 10, 2009
Posted by mdenomy in Uncategorized.2 comments
I have been trying to get out to more networking and technology events lately. In the past, I have gone to some of these events with high expectations and have sometimes left disappointed.
I have a new milestone for these types of events that I am calling the “One Good Thing” principle. If I can get one nugget of wisdom or truth: an idea to put into practice, a new blog to read, a new way to use an existing tool, a good contact, then I should consider the event a success.
Some recent examples of the “One Good Thing” principle in action
- Pollyanna Pixton at an Agile Boston event gave some great tips on collaborative leadership that I was able to put into immediate practice
- Sue McKinney at the same Agile Boston event was talking about how she implemented Agile techniques at IBM (which I hear is a pretty big company). There were a lot of good things in this talk, but one that I found particularly useful was how she dealt with teams that were resistant to adopting Agile practices. She did not force it on them, it was OK if they didn’t want to adopt it, but they could not disparage it publicly.
- A recent Ignite event at Microsoft NERD. I had never been to an Ignite event, but I hope to go again soon and maybe even present. I learned something about how to present an idea well (and sometimes not so well) in a short amount of time. Kudos to all who tried, I learned quite a bit there.
And finally, with all the Microsoft bashing in the world, I would like to say thanks to Microsoft NERD who seem to be making a concerted effort to open their space for networking and technology events in the Boston area. If you are in the Boston area, you should keep an eye on their Events page
New Team – First Retrospective October 20, 2009
Posted by mdenomy in Agile, Rally, Retrospectives.1 comment so far
Rally recently held a “success tour” event in Boston. I have been using Rally for about 18 months, but recently began using it on a team that is new to Agile, so I was interested in seeing if I could pick up anything that would help ease the transition. The event started with a roundtable of executives who have successfully used Rally, and a quote that hit home for me was from Jochen Krebs who said “every team needs to find its own unique path within the Scrum framework”. Joechen’s presentation at the Boston event can be found here (you have to hit the “older” button a few times to get to his presentation).
An interesting follow-up to Jochen’s presentation was given by Heather Kanser who pointed out the danger of teams “cherry-picking” the parts of Agile that they wanted. Their talks were complimentary as Jochen’s comment about teams finding their own path was “within the Scrum framework”.
I came from a team that has had good success using Rally and Agile in a particular way, and one of the challenges for me has been to tailor the approach for a new team. We’ve been introducing some new processes and adoption has been a challenge for both sides. We introduced some new processes about how we do releases and validation, and recently pushed out a new release of the software. It seemed like a good time for a retrospective. Of course, if I read my own posts, I would have remembered that the right time for the first retrospective may have been right when I first joined the team.
The comments for “what did we do well” were very encouraging. Collaboration, better testing, delivering what we promised, fixing architectural issues were all mentioned. I was particularly pleased that delivery of promised features and improved testing were included. These were areas that I pushed hard for and it was gratifying for the team to see the value. It is always nice too when you hear team members say “that can wait for the next release”. I think one of the hardest parts of initially adopting Agile is having faith that regular releases will provide an opportunity for more incremental improvements down the road. Delivering what you promised is more important than trying to add more features near the end of the development cycle.
There was some good discussion about what we could do better. This was one of those times where as I heard at the Rally event, the team needed to find its own flavor. I tried to stay back a bit from the technical aspects and work more to facilitate the discussion. It was very interesting to see how what we thought were the most important items to address evolved over the meeting. We have some actions and a follow-up meeting scheduled. Should be interesting.
Convincing Developers on the Value of Pair Programming July 1, 2009
Posted by mdenomy in Agile, Extreme Programming (XP), pair programming.add a comment
Something that often comes up when discussing the topic of pair programming is the notion of convincing management of its value. Am I paying twice as much to have two developers to work on a task instead of just one?
My experience with convincing management of the value of agile and XP methods has been if you deliver software on time and with few defects management will accept whatever practices get them those results.
The problem I often face and find much more challenging is how to convince other software developers of the value of pair programming. Getting comfortable with pair programming can be a challenge. The evolutionary nature of software development in an iterative, TDD environment means we don’t have all the answers up front. That can be an uncomfortable feeling. Nobody wants to look like they don’t have a clear vision of where the design is going or be uncertain about the best way to implement it. My advice is to get over it. The other person you are pairing with is in the same boat. When you switch seats and they are at the keyboard, they are going to be leaning on you to see the big picture and help guide the design.
Some people advocate code reviews and feel they can serve the same purpose as pairing. That is true in a sense, but one of the problems I have with code reviews is grasping the subtleties of the design and what trade-offs went into a particular design decision. With pairing you are intimately involved in the design, coding, and testing. You talked out the trade-offs as you went along. The tight feedback loop in pairing also reduces the likelihood of having to make a major refactoring that may come out of a code review. I am not opposed to code reviews, I just think pairing provides a better mechanism for good design and coding practices.
A lot of successful pair programming has to do with the two engineers developing a good working relationship and respecting one another. Talk through alternatives, try different implementations, write good tests, listen to one another, and learn from one another. My pair programming experiences have been some of the most gratifying development experiences in my career.
Head in the Cloud with Windows Azure January 22, 2009
Posted by mdenomy in .NET, Software, Visual Studio.add a comment
Microsoft hosted a developer conference in Boston today. I think for the most part, you get when you pay for, and the $99 price of this event told me it would probably be more marketing than technology. But it’s always good to get out and hear what’s going on and talk with other developers.
There were several topics of interest to me at the conference, ranging from F#, Silverlight, Visual Studio Team System 2010, and ASP.NET 4.0 , but one of the things I was most interested in learning about is Azure, Microsoft’s foray into cloud computing. I have not been paying a lot of attention to this topic and I thought that this conference would give me a good 50,000 foot view into the technology and Microsoft’s plans for it.
In the keynote, Amanda Silver referenced the Battle of the Currents, where in the early days of electrical distribution Thomas Edison’s system of direct current (DC) was pitted against Nikola Tesla and George Westinghouse’s system of alternating current (AC). One of the disadvantages of direct current was that the power generation had to be close by due to power loss associated with transmission. This meant that a manufacturing plant might need to have its own electrical plant, with all the associated capital costs and maintenance. This is much the same as technology companies today incurring the capital cost and IT support of maintaining their own data centers. The ability to buy electric power from a utility company would allow the consumer to focus on their business and treat the incoming power as a service.
Microsoft’s intention in this market seems to be to offer a similar utility model that would have the benefits of scalability, redundancy, and IT support and allow a company that subscribes to the Microsoft data center services to focus on it’s own business domain. As any of us who have had internal data centers know, power outages, scaling, and IT support (security patches, etc.) can be a real headache for a developer and data center IT support keeps us from doing our real jobs: design and writing code.
Now before you think I drank too much Microsoft Kool-Aid, I am just saying that is the idea behind cloud computing in general. Why absorb the capital outlay and support costs of setting up and maintaining a data center when you can lease those capabilities? Theoretically, this could lead to better support, scalability, and fault tolerance. Microsoft seems to be positioning itself for proving data center services and support in the future. How far off in the future is a question that remains to be answered.
The presentations on Windows Azure presented a fairly realistic picture of where the technology is today, and I give the presenters credit for that. Michael Stiefel’s presentation was good and gave the 50,000 foot view that I was looking for. He also drilled down a little bit into the services provided in Azure, including high level. Ben Day’s presentation was particularly good I thought, pointing out the potential of the technology while balancing that against some of the limitations of the current implementation, particularly related to Azure data storage. I would assume their blogs will have the presentations at some point in the future, so you may want to check in.
The presentations and keynote showed how you can get started with Azure today using Visual Studio 2008. You will need to install the Azure SDK and Azure Tools for Visual Studio that you can find here. Azure applications can execute locally on a Development Fabric, which is a simulated cloud environment on your desktop. You can also deploy a service to run in the Azure cloud, but you need to set up an account for that, and for the purposes of learning about the technology it would seem that the Development Fabric is adequate. The developer “experience” (another big buzzword at the conference) is the same as developing other Windows apps in Visual Studio. You can debug applications normally if they are running in the Development Fabric, however once they are deployed the only debug mechanism is logging statements.
This is definitely a “down the road” technology, and there are several kinks to work out, but if you want to be ahead of the curve it might not be a bad idea to try some of it out. One of the things that came up in the presentations is that Microsoft is on the fence on some aspects of the implementation and will be looking to the developer community for feedback. We’ll have to wait and see how all this plays out, but I am certainly willing to give it a spin.
Just Because You Can, Doesn’t Mean You Should January 21, 2009
Posted by mdenomy in Uncategorized.add a comment
I got a new car recently. For the last 10 years, I have been driving a Jeep Cherokee with roll-down windows, manual door locks, and no modern conveniences other than air-bags. Now I am getting used to all kinds of conveniences like lights that shut off on their own when I turn off the car, ABS, stability control, and even power windows and locks. Basically all the good things that the rest of you have enjoyed for a while.
It took a bit for me to come to grips with the fact that a car with ABS can stop the car better on snow than I can by gently pumping the brakes. And I am pretty sure that I’ll never get a dead battery because I left my lights on. So what does all this have to do with software you ask. Well I’ll tell you.
I love all these new features. But there are a few things that my car does that I think may have been “cool” to the guy that designed it, but maybe not such a great idea in the long run. My favorite example is the stability control system. The stability control feature will do wonderful things like help keep me pointed in the right direction if I start to lose traction in snow. What’s wrong with that….nothing, I love it.
What drives me crazy is that when the stability control automatically activates, an alarm sounds telling me that it has kicked in. Now I have one job in all this and that is to drive the car, but when I hear an alarm my first reaction is to look at the dashboard and find out what is wrong. Whoever designed this “feature” probably thought it was a cool thing to do, and we might as well use the buzzer in the dash for something, but is an unintended consequence of getting a driver to take his eyes off the road while losing traction a good thing? I don’t think so.
We’ve all been in situations when we have wanted to do something because it would be fun to implement or maybe would use a technology that we’ve always wanted to try. That isn’t a good enough reason to do put something into a product. It needs to add value to your product and be the right approach. If you want to try out a new technology, put it in a spike solution where you are free to experiment and where it stands alone and is easier to be reviewed. Prove that it works and show it to your peers. Determine how it can make your product better and convince the product owners.
Being agile means responsing to changing requirements and technology, but product decisions need to be made in the light of day.
By the way, this has not been a problem on the teams I have worked on. It’s just that we’ve been getting a lot of snow lately and that stability control alarm keeps going off.
Getting Started with Rally October 25, 2008
Posted by mdenomy in Agile, Rally.add a comment
I have been using Agile techniques on a regular basis for about 3 years now. The team I work in has gone through some interesting evolutions with our iteration and release planning, and at the moment we are using Rally as our planning tool.
A little history first might be helpful in how we got here. Early in the project it was just 2-3 developers and we were all developing C# code, using Visual Studio Team System. Team System has a pretty good work item and defect tracking system. You can enter defects, tasks, provide time estimates, and have dependencies between tasks. Another really nice feature was that your check-ins could be linked to a task/defect, so to go back and see what changes were made in the code against the work item was pretty easy to do.
When the team was smaller this approach worked pretty well. Our iteration planning meeting involved going through the open defects and work items (tasks, essentially). Most of what had to be done was implicitly understood by the stakeholders, so priorities were typically pretty clear and mostly it came down to a scheduling exercise. Team System did not seem to have any good mechanism for defining user stories and linking them to tasks, but with a smaller group of stakeholders and developers we were able to get by without a lot of user stories. Was it a mistake to not put more effort into user stories? Maybe, but that was the world we lived in.
All this worked pretty well while the team was small, but as the team grew it became more unwieldy. There was no mechanism to graphically display the tasks and do any long term planning. It was just a big task list. You could sort it, but being able to lay it out graphically was not supported. For a time we used a manual process where major tasks were put into a Visio diagram and grouped into iterations. That allowed the team to see how functionality would be rolled out, but keeping it in sync with the work item system was a manual process and difficult and time consuming at best. There was also no automated way to see if we were overloaded.
As the size of the team grew both in terms of developers and other stakeholders, we needed to find another solution. We looked at several tools and decided to try out Rally. Rally’s Community edition is free for up to 10 developers. It also has some of the features that I found were missing in our previous process.
- Graphical- Easy to drag and drop stories into different iterations and see when new functionality will come online
- Supports resource loading, so we can see how our iteration and release plans measure up against available resources
- Hierarchical – Everything starts with a user story or a defect. Tasks are grouped under the user story or defect. It is also possible to have a hierarchy of user stories to group and plan related functionality.
- Supports releases and iterations, so I can plan when formal releases will be available and easily see what feature sets (user stories and defects) will be in them.
- Built in reporting tools for defects, and iteration burn down rate.
Like any tool it has a few warts, and I am sure I will get around to posting about them. But in the two months I have been using it I am pretty pleased.
Project Retrospective October 2, 2008
Posted by mdenomy in Agile, Extreme Programming (XP), Retrospectives.2 comments
I held my first project retrospective this week. It was probably overdue, but there is no time like the present right?
I found Peter Steven’s blog and Boris Gloger’s paper on Heartbeat Retrospectives helpful in setting the format. I decided to cover the following topics in our retrospective
- What did we do well?
- What can we improve on?
- Who has ownership of the things that can be improved?
- What are the priorities?
We used sticky notes and a white board. You need to be succinct to state your point on a sticky note. Plus once they go up on the whiteboard they tend to lose ownership and they become the team’s ideas. There were only a few times when we had to ask who wrote something and that was only to clarify an idea. The group ownership of ideas keeps things flowing and prevents the meeting from being driven by one or two strong personalities.
Starting with “what went well” set the tone that the meeting is going to be positive and constructive. At other companies I have been at these type of meetings often turned into a finger pointing exercise and went downhill rapidly. Our team has a lot to be proud of, and it was great to reflect on the things we did well. And if it ain’t broke…..
The things we thought we did well broke down into 3 catgories: Team, Process, and Technology. I am not sure if that categorization was planned or an impromptu decision. Grouping them into categories didn’t really serve any purpose other than it allowed us to acknowledge each point as we decided where it belonged.
Like any project there are things that we can do better. We purposely did not put any limits on what people thought we could do better. Once we put everything up on the board we broke it down into two groups: Team and Organization. Team means we can do it within the framework of our own team structure. Organization meant we had to bring others (HR, management, etc) into the mix to help address the problem.
Once we had things broken down into 2 categories, it was time to prioritize the lists. There are a couple of different schemes you can use here. Seeing the same issue raised by multiple people may indicate something that is important. Ultimately we decided to do a simple voting scheme where everyone got one vote, and that seemed to work pretty well. Next time we may try giving everyone three votes, but that’s for next time. We have a small team, so there were only a few items in each category that got votes, but even that tells you something, and we were able to prioritize those items. The reality is you can’t fix everything, so you focus on what is most important.
Probably the most important part of a retrospective is that you take action on the high priority things to improve. I am anxious to seize the momentum and teamwork of the meeting. That is the challenge for me and the team in the very near future.
Energized Work – Part II October 2, 2008
Posted by mdenomy in Agile.add a comment
To paraphrase one of my favorite quotes from The Mythical Man Month
How does someone go from blogging about Energized Work to being too busy to blog for 6 months.
One day at a time.
