Or is it more the lack of ideas actually being executed?
Via Johannes Brodwall,
Litrik de Roy created an Eclipse plugin that controls the lights on a Dell XPS, turning them red when the your JUnit test fails and green when it passes.
Now all I need is a Dell XPS and I can create a pretty expensive build light...
Think about testing. How hard is the technology to test? How expensive will testing be to setup? This includes all the bureaucracy of setting up a test environment.
Be idiomatic OR Don't leave alien artifacts. Don't use unfamiliar technology unecessarily. And that's unfamiliar with the current group of people, not the "organisation", whatever that means. It doesn't matter that the "organisation" knows COBOL if most of your current people don't. Limit experimentation to one or a few aspects, not all of them at once.
Avoid duplication. Don't re-invent the wheel. Post-modern programming and all that. Don't write if you can reuse. If there is existing duplication, consider extracting (and offering) a library or service.
Minimise the number of parts. The more lines you have on the diagram, the worse it's going to be. And that's for your current system, not for some overall enterprise architecture diagram. Enterprise architecture is supposed to make it easier to build each individual system. So I don't care if the enterprise architecture diagram looks like spaghetti if most systems are being built quickly. I'll trust performance numbers over the aesthetics of a doodle. The doodle is misleading because you have other non-technical issues that come into play. Do we have people who know that system? Are the administrators of that system hostile? Do the consultants charge too much money? etc.
Yes, but hours aren't burndown. Accomplishments are. A team that focuses on hours isn't focusing on getting things done. Tracking hours makes it "OK" to do whatever you're doing so long as you're keeping the hours up to date.
The point of the Sprint or iteration is getting backlog items done, not getting tasks done. Tracking hours, in my experience, obfuscates that key fact.
-- Ron Jeffries on the Scrum Development mailing list
I've repeatedly encountered a belief that it is safer to lag in technology, let everyone else experiment first, let everyone else lead the way.
Is this actually safer?
I immediately think that this kind of behaviour will affect the types of personalities that the organisation will attract and retain. Specifically, people who are driven to do things better probably won't stick around.
The first BarCamp is being held in Australia this year! BarCamps, those crazy unconferences, will be held in states across Australia at the same time on the 3rd and 4th of March. BarCampSydney is calling you!
NO SPECTATORS, ONLY PARTICIPANTS
When you come, be prepared to share with BarCampers.
When you leave, be prepared to share it with the world.
BarCamp is an ad-hoc unconference born from the desire for people to share and learn in an open environment.
It is an intense event with discussions, demos and interaction from attendees.
Anyone with something to contribute or with the desire to learn is welcome and invited to participate.
What’s Next?
Sign up on the wiki, check out the blog, tell all your friends, prepare your presentation, ask your company if they’re interested in sponsoring…
Don't progress stories/features until they are tested. Or better yet demonstrated. Or better yet tested against users.
If you have them, unit test your stored procedures.
Accept stories in more realistic environments.
Include explicit tasks for "write story test first" and "refactor after".
Use probabilistic estimation and reporting.
Try answering requests with "Yes, and..." it will cost this much, it will introduce this risk, etc.
Encourage more direct interaction between programmers and users and other stakeholders. Use analysts as aides, not as gatekeepers.
Cross-skill to allow resource balancing for constraint management. At least cross-skill the easy stuff, and work on doing the same for the harder stuff.
Decide on and document your own conventions and process.
To put the question in general terms would be comparable to the question posed to a chess champion: "Tell me, Master, what is the best move in the world?" There is simply no such thing as the best or even a good move apart from a particular situation in a game and the particular personality of one's opponent. The same holds for human existence.... and the same holds for engineering software.
-- Viktor E. Frankl, Man's Search For Meaning
CruiseControl 2.6 has been released.
Jeffrey describes some highlights here.
I'm interested in working out where we go from here so if there is a key desire or problem you have with CruiseControl, please add a comment here, on the user's list, or on our JIRA.
I blogged about Kiva over a year ago but it took Mike Cannon-Brookes and fellow ThoughtWorker, James Webster, to get me to finally take action and become a Kiva lender.
There seems to be another one of those pointless blog memes going around. I say instead of blogging five things people don't know about you, how about becoming a Kiva lender instead?
If you're reading, consider yourself tagged.
I created a feature request for this in 2005, though it looks like they didn't see it. No matter, Squirrel SQL 2.4 has refactoring.
Allows you to view SQL alterations for several refactorings or apply them directly to existing tables. Refactorings supported are Add/Modify/Drop columns and Add/Drop Primary Key.
Creating an Informative Workspace is not about papering the walls with material. You are communicating and too much irrelevant information will distract.
Just because the information is there doesn't mean that I will see it, especially if it is buried in noise, written in tiny fonts, etc.
Make information visible, yes. But also minimal and focused.
Mark Graban at Lean Blog referred back to an old entry about his tour at NUMMI:
At previous companies, not as lean as NUMMI, it was pretty common to see a box of parts tagged with a sign that said, sternly, "DO NOT USE." Sometimes there was an important manager's name associated to illustrate who is making that pronouncement.One of the key things people new to Lean (as well as Agile) tend to miss or ignore is the concept of "respect for people". It's interesting how savvy observers can pick up on this by noticing the small things like how signs and guidelines are worded and presented.
At NUMMI, a box was labeled with a sign that included the "why." The sign said something like “using these parts would result in brake failures or problems for the customer.”
Several of us from the ThoughtWorks Sydney office have been meeting up for a book study group, starting with Jerry Weinberg's Secrets of Consulting.
I've actually read this a while ago but going through it again is great for a reminder.
For example, the advice that being reasonable is more important than being rational.
If you can't accept dealing with less than pure designs/systems/approaches/processes, you won't survive being a consultant nor will you ever be an effective problem solver since only easy problems are purely rational.
Have you ever been a situation where you receive a last minute change request that you have to refuse because you're just too close to release for that change to be safe?
That's responsible behaviour. It's utterly foolish to risk system stability by making non-critical changes just before a release.
Of course, there is a much higher probability that changes will be re-interpreted as non-critical just before a release even if it may eventually turn out that a minor issue as seen by the engineering team is the final annoyance that encourages a customer to go elsewhere.
So what would it take for last minute changes to be safe?
