Dinner Zero of Girl Geek Dinners Sydney is on for 21st February at the Lindt Cafe at Cockle Bay Wharf.
Should be a fun evening. Guys are allowed to attend, but only if one of the girls invites them first...
When many people say "standard approach" they are referring to a de jure standard, that is, one that was established by a committee from a standards body. This may or may not be based on a de facto standard, that is, one that has been established and proven in the field.
So do I care about "standard approaches"? Not so much. I'm more interested in proven approaches.
And then of course, on continuous improvement.
We were looking at various improvement activities that we're engaged in and which ones should be named "Completed". I suggested that given a mindset of continuous improvement we shouldn't really say that these things are completed so much that they were "Good enough for now" so we would divert focus to other aspects.
Thus was born GEFN.
For whatever reason, sometimes you end up with fat, non-cohesive interfaces. The Interface Segregation Principle is about protecting clients from fat interfaces by providing more narrow, segregated interfaces for them to depend on.
How does this migrate to a web service context?
Well, providers should still expose targeted interfaces for clients rather than a single fat interface.
Some issues...
I noticed that the Yahoo! Design Pattern Library has a curious definition for a Pattern borrowed from the IAWiki:
Patterns are optimal solutions to common problems. As common problems are tossed around a community and are resolved, common solutions often spontaneously emerge. Eventually, the best of these rise above the din and self-identify and become refined until they reach the status of a Design Pattern.The emphasis is on the optimal solution out of a set of common solutions (aka Best Practice)
Each pattern is a three-part rule, which expresses a relation between a certain context, a problem, and a solution.Instead of emphasising "optimal solution", the emphasis is on context, on a system of forces, and on a configuration that allows the forces to resolve themselves.As an element in the world, each pattern is a relationship between a certain context, a certain system of forces which occurs repeatedly in that context, and a certain spatial configuration which allows these forces to resolve themselves.
As an element of language, a pattern is an instruction, which shows how this spatial configuration can be used, over and over again, to resolve the given system of forces, wherever the context makes it relevant.
The pattern is, in short, at the same time a thing, which happens in the world, and the rule which tells us how to create that thing, and when we must create it. It is both a process and a thing; both a description of a thing which is alive, and a description of the process which will generate that thing
There is something called standard work, but standards should be changing constantly. Instead, if you think of the standard as the best you can do, it's all over. The standard is only a baseline for doing further kaizen.The emphasis is on a baseline for continuous improvement, on documenting exactly what is done rather than the best way, on rewriting the standard immediately when improvements are made, and on doing all of this at the place of work.
...
When creating Standard Work, it will be difficult to establish a standard if you are trying to achieve "the best way." This is a big mistake. Document exactly what you are doing now.
...
If you are observing every day you ought to be finding things you don't like, and rewriting the standard immediately. Even if the document hanging here is from last month, this is wrong.
...
If it takes one or two months to create these documents, this is nonsense. You should not create these away from the job. See what is happening on the gemba and write it down.
Dan Markovitz at Superfactory suggests that time, not inventory, is the water level knowledge workers need to reduce to expose hidden waste and efficiency in their processes.
But (to go back to the analogy I started with) when the water level - your inventory of time - is high, there's less urgency to reduce the waste and the inefficiencies. Why bother removing the waste in your work habits when you can just stay at the office an hour later, or get it done over the weekend?This suggests that the old XP practice of 40 hour week isn't really about sustainability or even energy level. Working a lot of overtime prevents us from exposing systemic problems.
In Workplace Management, Taiichi Ohno talks about having to encourage people to go beyond common sense since the common view may actually be full of misconceptions. This appeals to me since I've always disliked the phrase "common sense" as opposed to "correct sense".
Via The Elegant Solution, Ohno advocated four things in fighting intuitive, common sense that I thought was worth communicating here:
Via O'Reilly Radar,
Virgil Griffith had the idea of scraping Facebook to find the most popular books of universities and plot that against the average SAT/ACT score.
The result is amusing though obviously questionable in terms of validity.
Via Clarke Ching,
Fast Company article on Duncan Watts who replicated Stanley Milgram's six degrees of separation experiment at a larger scale and found that highly influential connectors were not crucial:
Why did Milgram get it wrong? Watts thinks it's simply because his sample was so small--only a few dozen letters reached their mark. The dominance of the three friends could have been a statistical accident. "And since Milgram's finding sort of made sense, nobody even bothered to redo the experiment," Watts shrugs. But when you perform the experiment with hundreds of successfully completed letters, a different picture emerges: Influentials don't govern person-to-person communication. We all do.
Robert Charette writes about what he calls "Open Source warfare" as demonstrated by insurgents in Iraq. I don't think that "Open Source" is the point so much as simply valuing fast learning cycles and short lead times, which requires empowerment of the individual.
A few of the more interesting bits...
According to some estimates, it now takes Iraqi insurgents less than a month to adapt their methods of attack, much faster than coalition troops can respond. “For every move we make, the enemy makes three,” U.S. Brigadier General Joe E. Ramirez Jr. told attendees at a May conference on IEDs. “The enemy changes techniques, tactics, and procedures every two to three weeks. Our biggest task is staying current and relevant.”...
You might think that the lag time was due to bureaucratic screwups, but in fact, that's just how long the bureaucracy takes to respond.
Via Tycho at Penny Arcade,
Johnny Chung Lee has been doing some very cool experiments with his Nintendo Wii. Check out this video about simulated 3D using Wii-enabled head tracking.
FogBugz has apparently had a recent outage. What's interesting is what happens after.
"Had we produced a written standard prior to deploying the switch and subsequently reviewed our work to match the standard, this outage would not have occurred," Michael wrote. "Or, it would occur once, and the standard would get updated as appropriate."
After some internal discussion we all agreed that rather than imposing a statistically meaningless measurement and hoping that the mere measurement of something meaningless would cause it to get better, what we really needed was a process of continuous improvement. Instead of setting up a SLA for our customers, we set up a blog where we would document every outage in real time, provide complete post-mortems, ask the five whys, get to the root cause, and tell our customers what we're doing to prevent that problem in the future. In this case, the change is that our internal documentation will include detailed checklists for all operational procedures in the live environment.
Bridget Grenville-Cleave at Positive Psychology News Daily blogs about potential dangers of focusing on strengths in organisations.
A fixed mindset individual lives in a world where some people are superior (having the sought-after natural talent) and some are inferior (without natural talent). In an organizational context, Dweck suggests, a fixed mindset starts to influence how the team behaves (for example, discouraging open and honest expression of disagreements over management decisions), and can even lead to groupthink.I'm thinking that it's not at all clear that focusing on strengths would be any more likely to be associated with believing in the unmodifiability of talent than focusing on weaknesses. I'd expect that the real point is that the focus should be on modifiability with a recognition that your strengths are the things that you can modify the most easily.
Damana created the blog and I've posted the first entry.http://girlgeekdinnerssydney.blogspot.com/
Stay tuned over there if you're interested.
Via The Sandbox,
An interview with Gabe Newell from Valve which touches on something that even projects outside of gaming can learn from.I think part of the reason we are doing episodic releases and smaller content releases is to allow us to take some of the risk out of the schedule and instead put it into the gameplay. So Portal, if we'd said let's go out and spend five years building a hundred million dollar game, it would have been fairly scary to have both that financial risk along with the game design risk, but by focussing it in to the Orange Box, it allows us to take that risk.
For people outside the gaming community, Portal was one of the most innovative and critically acclaimed games of last year.
I'm currently investigating the Toyota/Lean concept of Visual Management, also known as Visual Control, and I'm noticing an interesting difference compared to how the XP/Agile community has traditionally talked about Big Visible Charts or Information Radiators.
We've usually emphasised providing information. That's why we're using the term "charts" and discuss radiating information (as opposed to refrigerating it).
At least in terms of definitions, we've seem to have missed out on emphasising the importance of the information being signals for action.
I'm thinking "signals for action" is a more important aspect to acknowledge than the form of the signal (e.g., big visible charts) or the property of the signal (e.g., radiates).
What triggered this for me was hearing people refer to story tracking walls (aka kanban boards) as Big Visible Charts and thinking... "that's not really a chart".
Po Bronson writes about How Not to Talk to Your Kids based on existing research.
Main points:
Kathryn Britton at Positive Psychology News Daily blogs about Scott Sherman's research into what is and isn't correlated to success in environmental social activism.
Not associated with success:
Associated with success:
Apparently the science indicates that we're compassionate by default (excluding sociopaths). So what are the factors that change that?
Very interesting TED talk by Daniel Goleman of Emotional Intelligence fame.
Via Chris Spagnuolo,
Andy Hunt references Pablo Picasso on multitasking:
You must always work not just within but below your means. If you can handle three elements, handle only two. If you can handle ten, then handle five. In that way the ones you do handle, you handle with more ease, more mastery and you create a feeling of strength in reserve.
I was thinking about blogging this but it seems Keith Braithwaite already has.
And now don't we get down to it? If you use patterns in your work, then you must be an idiot. Not only are you working on one of those weak languages, but you don't even know enough to know that GoF is only a bunch of work-arounds for C++'s failings, right? I think Dick Gabriel's comment goes to the heart of it. If patterns are the master programmers advice to the beginning programmer, codified, then to use patterns is to admit to being a beginner. And who'd want to do that?
From www.refactoring.com,
Refactoring is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior.Refactoring doesn't have to be object-oriented. Refactoring doesn't have to actually improve the code in any way. Refactoring Databases is an example that refactoring doesn't have to even be about application code.
The way I like to derive this is to think about what is most important. The most important thing is that the code works. We use tests to show us that the code works therefore the first point must be that all the tests must run. The next most important thing is that the code is as easy to understand as possible, therefore we need to ensure that it expresses every idea that we need to express clearly. Even though it works and it's understandable, we still need to consider maintainability. Therefore say everything once and only once and minimize the number of classes and methods.If you're paying attention, you'll notice my reasoning put Once and Only Once (the old school XP way of saying DRY) after expressing ideas clearly. The ordering of the rules changed since removing duplication became generally seen as more important than expressing ideas in ways that maintained duplication. Avoiding repetition just seemed to be a simple but very effective focus in pushing toward better designs.
