I recently finished up reading another book about agile. This time it was Scrum and XP from the trenches.
It was a pretty good book. Well written, an easy read. I liked it because it described real world experience using scrum over several years at a software company in Sweden. It's good because it shows that in practice there were some deviations from agile doctrine that worked for them.
For example he suggests a three week sprint length. This makes sense because then the team can get some momentum. Plus the overhead of setting up and tearing down a sprint is very non trivial; so extending the actual clean development time is a good thing. He also recognizes that within a project the team and team members are constantly bombarded with issues that are not part of the sprint planning. In general only 40-60% of the team members time will be available for the actual new feature work in a sprint. The rest may be addressing new bugs, distractions with customer requests, network being down, helping out people who are looking at code you know about, general delays and distractions that happen almost every day. Unlike the unrealistic viewpoint of "sprint safety"; in the real world there is distraction and the wise developer accounts and allows for it.
Another thing I really liked is his honest talk about personnel. In one passage he suggests the ideal sprint team size is no more than eight. If you find there are 10 people assigned to the sprint he suggests to eject the two weakest team members. Excellent practical advice. In another passage about difficult to manage team members he says in some cases to consider if you even want this person on your team.
Some valuable common sense advice there. Far and away the real key to a successful software team is having predominantly strong developers on the team. That's more important than religious adherence to the development methodology fad of the quarter. The author recognizes scrum will not transform weak developers into average developers; or average developers into good developers. After the stand up meeting everyone just goes back to their cubicle to write good software; mediocre software; or bad software.
The author talks about the problems there were at the company before he joined. I know he credits scrum with a lot of improvements. Still I wonder how much improvement was the undertone of the book which was that after he arrived he was allowed to get rid of low performing developers; I suspect previous management was unwilling or unable to do this.
I liked what I would call real world scrum like this book and the works of Scott Ambler. Hearing some of the dogmatic scrum theory; it's hard to grasp some of it. So it's good to hear of bridging the gap between the real world software development and the strange world of the agile theory.
Thursday, April 02, 2009
Friday, March 27, 2009
Python back on my desktop
This week I was doing some stuff with some log files. In the logs there were some periodic logs that appeared every 30 seconds which was distracting and annoying.
In UNIX this is of course swoosh, its
Alas running on my Windows desktop Microsoft in its wisdom sees no need of such conveniences like tail and grep.
So what to do? Of course, what I did back at SupportSoft when I had to deal with this. Write a Python script to tail and grep. It was pretty easy since there was already stuff on the Internet for that - of course in Python it was only about three lines anyway. And just like that I was in business, no more annoying periodic log messages.
It was a bit strange though when I went to write the script. I was surprised to notice that I didn't even have Python installed on my desktop. That's weird, have I really gone that long without it? Maybe since I switched jobs close to a year ago it takes a while to properly get settled in and comfortable to the point of firing up Python to make your day more productive and enjoyable. Plus I've switched to a new team recently so maybe the dynamic here is somehow different in some more positive way that steered me back toward my correctness of the past.
Anyway I'm glad to have it. Since then I've had my interpreter up all day long and it's just pleasing to see it there on my taskbar, like an old friend. I even found some more uses for some quick one line things. So welcome back to my desktop Python.
In UNIX this is of course swoosh, its
tail -f logfile | grep -v pattern >> outfileAlas running on my Windows desktop Microsoft in its wisdom sees no need of such conveniences like tail and grep.
So what to do? Of course, what I did back at SupportSoft when I had to deal with this. Write a Python script to tail and grep. It was pretty easy since there was already stuff on the Internet for that - of course in Python it was only about three lines anyway. And just like that I was in business, no more annoying periodic log messages.
It was a bit strange though when I went to write the script. I was surprised to notice that I didn't even have Python installed on my desktop. That's weird, have I really gone that long without it? Maybe since I switched jobs close to a year ago it takes a while to properly get settled in and comfortable to the point of firing up Python to make your day more productive and enjoyable. Plus I've switched to a new team recently so maybe the dynamic here is somehow different in some more positive way that steered me back toward my correctness of the past.
Anyway I'm glad to have it. Since then I've had my interpreter up all day long and it's just pleasing to see it there on my taskbar, like an old friend. I even found some more uses for some quick one line things. So welcome back to my desktop Python.
Monday, March 09, 2009
Non functional requirements
This is kind of a strange one if you think about the name. I mean, why would you want the software to be non functional?
Of course we know what non functional requirements are. That is stuff that an end user or even tester cannot verify directly by using the system. Such as "all code is reviewed", "JSF will be used to generate the GUI web pages", "database access will be through stored procedures", "development will follow the S methodology". Stuff like that. But if you look at the name itself in isolation it's kind of funny.
Of course we know what non functional requirements are. That is stuff that an end user or even tester cannot verify directly by using the system. Such as "all code is reviewed", "JSF will be used to generate the GUI web pages", "database access will be through stored procedures", "development will follow the S methodology". Stuff like that. But if you look at the name itself in isolation it's kind of funny.
Wednesday, February 18, 2009
Software development projects
I recall back in fall 2001 back at Core Networks, shortly after I joined Core. We were kicking off a project for the next version of the CoreOS flagship product. The project lead mentioned that we were going to be doing some tweaks to the software development process for this project.
At that time Andrew, one of the earliest Core Networks employees from the founding in 1998, had this comment. He said "except for emergency bug fixes, no two software development projects in the history of this company have ever been done the same way."
Which was true at the time. What's interesting is 7 years later in 2008 when I left SupportSoft (which had acquired Core in 2004). In 2008 Andrew's statement was just as true as in 2001. Except for emergency bug fixes, we still had never done two software development projects the same way.
At least with Core/SupportSoft there was always some desire to change the way we did software development projects. For whatever reason management, the architects, or the developers or whoever instead of standardizing on something that worked was always reinventing how software was to be developed.
Perhaps it's like software itself, which is perceived as infinitely flexible and changeable. The process of software development is perceived as infinitely adjustable and changeable. Some new fad or methodology. I would argue that the perception that changing software development process is cost free encourages excessive and unnecessary tinkering and adjustments.
I think most everyone would agree that the old style late and large delivery to the test team is not a good way to go. However once you get past that I don't think people recognize that the changing the software development process is disruptive and expensive. I suspect the point of diminishing returns is reached sooner than people would like to admint.
Some recent work on my street has made me think about it I guess. There are 6 apartment buildings on my street. They are all wood, 3 storey, around 30 years old, built around the mid 70s. Although the ownership of the buildings is mixed, within the last 8 months or so 4 of the 6
buildings have had their exterior renovated. Front shingles and siding replaced. Two of the buildings have also got new vinyl windows to replace the legacy metal frame windows.
For the companies doing the work, I'm sure this is a pretty standard project. Shingles and siding on a 30 something 3 storey wood 20 unit apartment building. I suspect that they followed the same methodology for each building project, and did not make material changes from building to building on the order of work done, number of people per building, starting on front vs. back, amount of cleanup done per day and at the end, what work is done by the most experienced journeymen vs. the less experienced apprentices, etc. It was just the same standard way that everyone understands, is predictable, and works well and everyone knows what to do and how and when.
Thinking about it I kind of envied them a little bit. Maybe there's something to that we could use in software.
At that time Andrew, one of the earliest Core Networks employees from the founding in 1998, had this comment. He said "except for emergency bug fixes, no two software development projects in the history of this company have ever been done the same way."
Which was true at the time. What's interesting is 7 years later in 2008 when I left SupportSoft (which had acquired Core in 2004). In 2008 Andrew's statement was just as true as in 2001. Except for emergency bug fixes, we still had never done two software development projects the same way.
At least with Core/SupportSoft there was always some desire to change the way we did software development projects. For whatever reason management, the architects, or the developers or whoever instead of standardizing on something that worked was always reinventing how software was to be developed.
Perhaps it's like software itself, which is perceived as infinitely flexible and changeable. The process of software development is perceived as infinitely adjustable and changeable. Some new fad or methodology. I would argue that the perception that changing software development process is cost free encourages excessive and unnecessary tinkering and adjustments.
I think most everyone would agree that the old style late and large delivery to the test team is not a good way to go. However once you get past that I don't think people recognize that the changing the software development process is disruptive and expensive. I suspect the point of diminishing returns is reached sooner than people would like to admint.
Some recent work on my street has made me think about it I guess. There are 6 apartment buildings on my street. They are all wood, 3 storey, around 30 years old, built around the mid 70s. Although the ownership of the buildings is mixed, within the last 8 months or so 4 of the 6
buildings have had their exterior renovated. Front shingles and siding replaced. Two of the buildings have also got new vinyl windows to replace the legacy metal frame windows.
For the companies doing the work, I'm sure this is a pretty standard project. Shingles and siding on a 30 something 3 storey wood 20 unit apartment building. I suspect that they followed the same methodology for each building project, and did not make material changes from building to building on the order of work done, number of people per building, starting on front vs. back, amount of cleanup done per day and at the end, what work is done by the most experienced journeymen vs. the less experienced apprentices, etc. It was just the same standard way that everyone understands, is predictable, and works well and everyone knows what to do and how and when.
Thinking about it I kind of envied them a little bit. Maybe there's something to that we could use in software.
Tuesday, January 06, 2009
swag
A little surprise to start off the work year. I guess while I was on vacation they gave some stuff to everyone for end of year. There was still some left so I went up to where HR had it and got mine.
It was a soccer theme with company logo gear from umbro. There was a carry bag with a soccer ball to inflate, a ball cap, and a long sleeve soccer shirt. It looks fairly nice.
In high tech the flow of swag is often a fairly good indicator of how the company is doing. At least it was pretty accurate back with SupportSoft and Core Networks. When the company is doing well the swag can flow pretty fast and thick with t-shirts, baseball caps, golf shirts, knickknacks, mouse pads, fridge magnets, pens, rugby shirts, jackets, free meals, etc. When the company is not doing well then you can tell because the flow of swag dries right up.
It was a soccer theme with company logo gear from umbro. There was a carry bag with a soccer ball to inflate, a ball cap, and a long sleeve soccer shirt. It looks fairly nice.
In high tech the flow of swag is often a fairly good indicator of how the company is doing. At least it was pretty accurate back with SupportSoft and Core Networks. When the company is doing well the swag can flow pretty fast and thick with t-shirts, baseball caps, golf shirts, knickknacks, mouse pads, fridge magnets, pens, rugby shirts, jackets, free meals, etc. When the company is not doing well then you can tell because the flow of swag dries right up.
Sunday, December 07, 2008
User Stories Applied
I just finished reading the book User Stories Applied. It was interesting. A co-worker lent me the book and suggested I read it. I can't remember the last time I read a work related book on my own. It's been a long time. I guess my interests outside of work are more, well, "interesting" than studying up further on what I do during the daytime to get paid.
It's good for me to get more of a grasp on what all this agile stuff I hear about all the time is about. I still don't really get it. As I read through User Stories Applied I kept thinking to myself did you actually build real software this way? Although the author is careful to consistently back up his talk with examples from real projects. So it apparently has been used on real projects and isn't just some academic thought experiment.
I guess it's hard to get comfortable with something that is such a departure from the projects I've always worked on. Still over the years people have attempted to introduce some of the concepts of agile into the software development project management. I think that's the thing with agile among established companies. We want to pick and choose the more interesting and useful aspects without going whole hog and having say 2 programmers to a workstation.
For example iterative development with feedback is good. We've all known from hard experience for a long time that the "late and large" integration at the very end of a software project is a bad way to go. So we try to build earlier and keep it in a usable working state where people outside the team can use it and give feedback. That said we were using milestones back at PRIOR on the CMS SB3 project in 1998.
One thing that really struck me was pretty much every chapter kept going on about this individual called the "customer". The customer writes the user stories (NOT the programmers!). The customer writes the acceptance tests (hmmm). The customer provides feedback between iterations and determines which stories are to be done in each sprint. This is a certainly a departure from the past with that level of customer involvement. In my experience I'm reading this and thinking, Who is this customer? I don't recall seeing him around very much in my 12 years in the cubes.
So that's something that's important and different. Agile isn't some internal fad or thing that the programmers do on their own that is opaque to everyone else. The customers have to be more involved. That involves organizational change. If the organizational change doesn't happen and it ends up being the programmers writing the stories and the acceptance tests and planning the sprints, etc. then agile probably won't be very successful.
It was a good book. I did learn a lot more about agile. It's part of the Kent Beck signature series. I think I've grasped enough for now and I'm not planning to read the rest of that Beck series. I've got some other books outside of work related lined up to read.
I remember back at TUNS in the software engineering course. The prof did a series on 4GL and code generators. He showed us this demo of some TI system called IAF or something like that. After you set up all of the screens and described the data and workflows it set about generating C code at a rate of about 100,000 lines and hour.
The prof made an interesting observation. IAF was very good at the traditional integrated order entry - inventory - shipping problem for mid to large manufacturing companies. That one specific scenario. However you wouldn't build a compiler with IAF. You wouldn't build IAF itself using IAF.
I think that would also apply to user stories as well. For example I wouldn't specify the emergency shutdown software for a nuclear power plant using user stories. I wouldn't design air traffic control software with user stories. I think user stories and agile may be useful in certain categories of software development; and inappropriate for others.
Software development is a large and diverse space. Internal IT department. Systems integrators. Shrink wrap software installed at a remote site. Web apps running off one big live website. Within this large space there are probably some situations where user stories and agile work well.
It's good for me to get more of a grasp on what all this agile stuff I hear about all the time is about. I still don't really get it. As I read through User Stories Applied I kept thinking to myself did you actually build real software this way? Although the author is careful to consistently back up his talk with examples from real projects. So it apparently has been used on real projects and isn't just some academic thought experiment.
I guess it's hard to get comfortable with something that is such a departure from the projects I've always worked on. Still over the years people have attempted to introduce some of the concepts of agile into the software development project management. I think that's the thing with agile among established companies. We want to pick and choose the more interesting and useful aspects without going whole hog and having say 2 programmers to a workstation.
For example iterative development with feedback is good. We've all known from hard experience for a long time that the "late and large" integration at the very end of a software project is a bad way to go. So we try to build earlier and keep it in a usable working state where people outside the team can use it and give feedback. That said we were using milestones back at PRIOR on the CMS SB3 project in 1998.
One thing that really struck me was pretty much every chapter kept going on about this individual called the "customer". The customer writes the user stories (NOT the programmers!). The customer writes the acceptance tests (hmmm). The customer provides feedback between iterations and determines which stories are to be done in each sprint. This is a certainly a departure from the past with that level of customer involvement. In my experience I'm reading this and thinking, Who is this customer? I don't recall seeing him around very much in my 12 years in the cubes.
So that's something that's important and different. Agile isn't some internal fad or thing that the programmers do on their own that is opaque to everyone else. The customers have to be more involved. That involves organizational change. If the organizational change doesn't happen and it ends up being the programmers writing the stories and the acceptance tests and planning the sprints, etc. then agile probably won't be very successful.
It was a good book. I did learn a lot more about agile. It's part of the Kent Beck signature series. I think I've grasped enough for now and I'm not planning to read the rest of that Beck series. I've got some other books outside of work related lined up to read.
I remember back at TUNS in the software engineering course. The prof did a series on 4GL and code generators. He showed us this demo of some TI system called IAF or something like that. After you set up all of the screens and described the data and workflows it set about generating C code at a rate of about 100,000 lines and hour.
The prof made an interesting observation. IAF was very good at the traditional integrated order entry - inventory - shipping problem for mid to large manufacturing companies. That one specific scenario. However you wouldn't build a compiler with IAF. You wouldn't build IAF itself using IAF.
I think that would also apply to user stories as well. For example I wouldn't specify the emergency shutdown software for a nuclear power plant using user stories. I wouldn't design air traffic control software with user stories. I think user stories and agile may be useful in certain categories of software development; and inappropriate for others.
Software development is a large and diverse space. Internal IT department. Systems integrators. Shrink wrap software installed at a remote site. Web apps running off one big live website. Within this large space there are probably some situations where user stories and agile work well.
Subscribe to:
Posts (Atom)