Action Hack: features research on github

During Action Hack I did a quick scan of GitHub.

Was looking for ideas for laying out and grouping features. I looked at 20 projects that had features folders.

Almost all of them just had a flat structure. Simply features files named for groups of features.

The one exception had sub directories that grouped the feature files by release.

Would be interested in hearing how people layout their features.

Gnoll110

Nagios and Ruby

Found these links that might interest people.

This looks like a project with some potential.
http://lusislog.blogspot.com/2008/04/nagios-and-ruby.html

Here is an example that looks like it worth pulling apart to see how it ticks.
http://blog.hungrymachine.com/2007/08/14/using-a-ruby-based-aim-notifier-in-nagios/

I've not had a chance to run either, sorry.

Enjoy.


Gnoll110

The other 95% are management problems

I do like this Mary Poppendieck post from earlier this month. Sorry to take soooo long to blog about it.

I do love the ‘The other 95% are management problems’ statement at the very end.

I’ve seen developers thrashing through multiple assignments many times, and in my experience it is usually caused by one of two things:

1) The organization can’t make up its mind what is important for one reason or another, so it tries to do everything. To me this is fundamentally a management problem – it is a basic management obligation to assure that the organization has the capacity to accomplish what it chooses to do. Releasing all sorts of work that is un-prioritized or with changing priorities is neither fair to workers nor an effective way to accomplish work. Releasing a ton of work and expecting it to flow is equivalent to sending a mass of cars onto a freeway (eg. after a sporting event) and expecting traffic to flow. Anyone who understands traffic jams should be able to understand that trying to do too much work is one of the best known ways to get less work done. There is massive evidence to support this – and managers usually know this at some level, yet often choose to ignore it. Those who do not limit assigned work to the capacity of the organization to deliver are ignoring the evidence and not doing their job.

2) There are large caches of waste sitting around the organization that are either invisible to the development team or that are impossible for them to address. This could be lack of clear definition, poor tools, a process which separates different functions and expects them to work sequentially, a practice of not testing until LOONG after coding so that test-and-fix cycles dominate the development agenda – and on and on. In almost all cases, these are SYSTEM problems, not developer problems.

One thing Deming would be sure to say, were he alive today: The likelihood that the organization’s problems are being caused by workers, or can be solved by workers, is maybe 5%. The other 95% are management problems.

Mary Poppendieck

In a previous post, I comment how Mainframe COBOLs two big problems were the nature of the language & lack of active new tool development over the last 20 plus years.

Of cause, for any organization that has these problems today, it really is a management problem. Said organizations have had lots of years to extract themselves from this situation.

The post is at: Yahoo Groups in leandevelopment

I’ve also extracted the sub-thread into this blog post:

How do you break the cycle?

Posted by: sambayer
Tue Apr 3, 2007 12:37 am (PST)

I'm working with a software services organization that wants to transition their implementation processes to lean. Today they are suffering from a lot of wip, big backlog, and lengthy implementation cycles....>8- 10 months. We're dedicating a team to get through one implementation in 1/3 that time. The problem is that everyone in the organization is multi-tasking. Everyone is handling multiple clients at various stages. To add insult to injury, a few employees just left leaving them even more shorthanded. How do we get them off of their "multi-tasking" wip addiction?

Management is behind our experiment because the potential results are dramatic. The challenge we're facing is figuring out where and how to break the multi-tasking addiction. Any suggestions would be greatly appreciated.

Tue Apr 3, 2007 11:53 pm

Hi sambayer, you wrote:

> I'm working with a software services organization that wants
> to transition their implementation processes to lean. Today
> they are suffering from a lot of wip, big backlog, and
> lengthy implementation cycles....>8-10 months. We're
> dedicating a team to get through one implementation in 1/3
> that time. The problem is that everyone in the organization
> is multi-tasking. Everyone is handling multiple clients at
> various stages. To add insult to injury, a few employees just
> left leaving them even more shorthanded. How do we get them
> off of their "multi-tasking" wip addiction?
>
> Management is behind our experiment because the potential
> results are dramatic. The challenge we're facing is figuring
> out where and how to break the multi-tasking addiction. Any
> suggestions would be greatly appreciated.

You are fortunate that management is backing your experiment.

To break your addiction I recommend that you use the [i-don't-know-what-its-called] principle:

1) Explain to everyone that their job is to improve how they accomplish their responsibilities as part of how the company delivers value to its customers.
2) Help them learn to see the waste in the way they work.
3) Help them learn to improve how they work using the Scientific method.
4) repeat all the previous steps

That's it. The learning part is where you can bring in the advice and insights of others, such as the advice from the other two people who respond to your post, into your unique environment, i.e. you learn and understand principles and apply them to develop your own best practices.

While multi-tasking is bad, see Peter Abilla's excellent analysis based on the physics of systems showing this,
http://www.shmula.com/375/multi-tasking-leads-to-lower-productivity, you and your colleagues need to understand your context and commitments and what the issues are in your environment before you start making changes. You need to ensure that you make improvements not just change. The good news is that you and your colleagues already are Subject Matter Experts (SME) on your environment, so you just need to change how you look at your work and environment. There is a wonderful example of this in Matthew May's book, The Elegant Solution. In Chapter 15 he recounts how instructors from Toyota, worked with LAPD staff and in 1 day came up with significant suggestions for improvements in many different problem areas. The LAPD staff were the SME, the Toyota instructors just help them to see their environment and what were the root causes of some their problems and then they helped the LAPD staff to suggest ways to they could improve their ways of operating.

Regards
Norbert
-----
Norbert Winklareth
Agile Renaissance

Wed Apr 4, 2007 1:22 am

>>>
While multi-tasking is bad, see Peter Abilla's excellent analysis based on the physics of systems showing this, http://www.shmula.com/375/multi-tasking-leads-to-lower-productivity, you and
<<<


Hey, I'm *against* multi-tasking as much as anyone. But if it's so bad for us humans, then why is it *good* for operating systems? I'm at my best when I'm mulling over several problems at once. To make a broad statement that multi-tasking is bad is awfully sweeping. Maybe some types are ok afterall. The main thing that I I try to provide for developers is an uninterrupted *zone* time of 2 hrs, twice a day. During the zone there are no interruptions, no context switching, no nothing!

Mel Bartels

Wed Apr 4, 2007 1:32 am

Management is behind our experiment because the potential results are dramatic. The challenge we're facing is figuring out where and how to break the multi-tasking addiction. Any suggestions would be greatly appreciated. I think there is a fine line between multi-tasking providing a "cross fertilization" of ideas, and inundating you with so much "fertilizer" that you can't see the daylight.

I guess it's all about moderation.

All of our employees complain about being overworked and too much multitasking going on. How do you know if that's really the case, or if they are just complaining?

Sam

Posted by: Mary Poppendieck
Tue Apr 3, 2007 7:12 pm (PST)

Hi Sam,

I've seen developers thrashing through multiple assignments many times, and in my experience it is usually caused by one of two things:

1) The organization can't make up its mind what is important for one reason or another, so it tries to do everything. To me this is fundamentally a management problem - it is a basic management obligation to assure that the organization has the capacity to accomplish what it chooses to do. Releasing all sorts of work that is un-prioritized or with changing priorities is neither fair to workers nor an effective way to accomplish work. Releasing a ton of work and expecting it to flow is equivalent to sending a mass of cars onto a freeway (eg. after a sporting event) and expecting traffic to flow. Anyone who understands traffic jams should be able to understand that trying to do too much work is one of the best known ways to get less work done. There is massive evidence to support this - and managers usually know this at some level, yet often choose to ignore it. Those who do not limit assigned work to the capacity of the organization to deliver are ignoring the evidence and not doing their job.

2) There are large caches of waste sitting around the organization that are either invisible to the development team or that are impossible for them to address. This could be lack of clear definition, poor tools, a process which separates different functions and expects them to work sequentially, a practice of not testing until LOONG after coding so that test-and-fix cycles dominate the development agenda - and on and on. In almost all cases, these are SYSTEM problems, not developer problems.

One thing Deming would be sure to say, were he alive today: The likelihood that the organization' s problems are being caused by workers, or can be solved by workers, is maybe 5%. The other 95% are management problems.

Mary Poppendieck

952-934-7998

www@poppendieck. com

Author of: Lean Software Development & Implementing Lean Software
Development

Design Improvement and COBOL

Last weekend I ventured down to Melbourne to attend Cogent Consulting’s Design Improvement workshop at the Northcote Town Hall. It’s the first time Cogent has offered this workshop as a public course. It’s great value, a few hundred dollars, for what would normally be a $500+ a day, for a weekday course at a CBD venue.

I thing that the course brought home to me, is the gap between current best practice and mainframe COBOL. I understood the gap conceptually, the workshop made the gap much more concrete.

The gap has two roots.
1. The nature of COBOL, its global memory model, granularity (particularly regarding testing) etc.
2. Lack of active tool development on mainframe environments for over 20 years.

A primary tool for ongoing design improvement is refacturing. That is, modifying internal design, without changing the codes external behavior.

Why send time/money without added functionality? To bring out new abstraction that lead to more elegant solutions. These new refactured objects/concept make it easier and cheaper to test and easier, faster and cheaper to extend.

It's ongoing maintanence, it extends the life of the system and reduces the total lifecycle cost/annum. It reduces the number and size (cost not being linear to increasing size) of major revamps!


Gnoll110

Bedding a new system

I was in Melbourne last week.

I can across an new system that was being bedded in.

At the new Southern Cross station, in the Bus interchange area, they have some new lockers. They are from a Chinese maker.

They have had an engineer from the maker on site, hacking Linux based code. He been on-site from several weeks, installing and hacking daily builds from home!

They got big problems with touch screen sensitivity. It's that bad they got a minder on hand to help traveller!

They touch keypad is none standard too.

The '0' key is right of the '6', instead of being below the '8' key!

1	2	3
4	5	6	0
7	8	9
	0

Now pick up your mobile phone and check its keypad.


Gnoll110

software testing china daily+build interface+design touch+screen+sensitivity