I'm learning a bit of git while in a subversion environment, mainly to do cheap dev branching. After successfully committing my first fix up from a git branch back into svn, I deleted the branch and didn't think much about it. Later I dcommit-ted a second fix on another local git branch and started to delete that branch but then got nervous. What could I do to ensure I wasn't about to delete something that had a pending change on it?

The PragProg Git book mentions that the default delete command provides a safety check and won't delete a branch that hasn't been merged. However, I realized that I hadn't merged my first bug fix branch back to my git master, so how was it that I was able to delete that branch? Had I found a loophole in the process since I was throwing some git-svn into the mix?

I found in the git-branch man a --merged option on the git branch command that should show me in advance what branches it considered safe to delete.

After playing around some, I realized I _had_ merged my original qc branch to my master branch, just not directly -- git (I presume) realized the merge had occurred because I'd done a git svn rebase command on master.

Here's a snippet from the console demonstrating this in action. Note, on the qc4042 branch I'd already done a git svn dcommit of all changes on that branch, but I hadn't dcommitted anything from the qc3937 branch.

c:\src>git branch
* master
  qc3937
  qc4042

c:\src>git branch --merged
* master

c:\src>git branch --no-merged
  qc3937
  qc4042

c:\src>git branch -d qc4042
error: The branch 'qc4042' is not an ancestor of your current HEAD.
If you are sure you want to delete it, run 'git branch -D qc4042'.

c:\src>git svn rebase
First, rewinding head to replay your work on top of it...
Fast-forwarded master to refs/remotes/svn/git-svn.

c:\src>git branch --merged
* master
  qc4042

c:\src>git branch -d qc4042
Deleted branch qc4042 (was 6516af4).

New stuff at the bottom of the page, if you've read all this before

One thing that seems to stick in my mind the more I read about keys to successful teams is simply getting the right people.

JoelSpolsky recommends Facts and Fallacies of Software Engineering, by Robert L. Glass as a good summary of the core things we know about software development so far (which is interesting in light of SwebokAndLicensing, and I've heard some other heavyweights in the development world are not in love the Glass book). Number one in Joel's summary of the facts presented in the book:

The most important factor in software work is not the tools and techniques used by the programmers, but rather the quality of the programmers themselves.

Joel also has a great essay on how attempts to codify the successfulness of talented people just don't work.

1. Some things need talent to do really well.
2. It's hard to scale talent.
3. One way people try to scale talent is by having the talent create rules for the untalented to follow.
4. The quality of the resulting product is very low.

---

I was listening to a local sports station the other day interview John Gagliardi, who, on 11/8/03, became college football's winningest coach. A lot of the interview centered around John's coaching style, and the fact that he does a lot of things different (no tackling during practice, for example). The overall gist was that he didn't have a very detailed infrastructure for his team -- much of what a big college football program would do, he doesn't worry with. In fact, he summarized his approach this way (and I paraphrase because I didn't write down the quote being in the car at the time):

What you really need is good players. Good players don't need a lot of rules.

(Or structure: "On the best teams, different individuals provide occasional leadership, taking charge in areas where they have particular strengths. No one is the permanent leader... The structure of the team is a network, not a hierarchy." Peopleware: Productive Projects and Teams, 2nd ed., p. 155, Tom DeMarco and Timothy Lister -- via Dave Hoover's blog

---

1/12/04 - Bill Caputo posts this [quote is digestized]:

[Non-agilists] see nothing -- or very little -- in the XP process definition that will make people successfully deliver -- but its true of any process. [They] want a process that will make others succeed. Agilists believe this view of process is inherently flawed. No process makes you successful, but people who will succeed anyway can do so with a more or less painful process.

XP is simply the best collection of practices I have ever found that are generally useful in addressing the problems I try to solve on each project -- but in the end, I succeed because of me and the people around me, not our process, which we readily change in response to our current challenges.

[W]e don't claim XP will protect us from the harmful, we claim that it aids the successful.

---

1/22/04 - Jerry Weinberg, in an interview on Borland's site (via Esther Derby), chimes in with some soundbites on this topic:

What do you consider the most important thing for a programmer to do when he begins working on a new project?

I think each should be sure they are in good physical condition without nagging psychological problems.

What do you consider the most important thing for a programmer to do when he begins working on a project that has already begun?

She should get sufficient information to decide, before signing on, whether she should sign on. Most programming projects that fail have already failed before most of the programmers have signed on, but through lack of courage or due diligence, many programmers sign on anyway. It's like doctors agreeing to do surgery on corpses.

Would you recommend a career in programming to young people today?

It depends on what the young person wants to do. I always give the same career recommendation: "Do what you want to do."

What courses would you recommend they take? What languages/technologies should they key on?

They shouldn't key on languages and technologies. They should key on learning to communicate, to think, and to work well with other people. Once they have those, the languages and technologies become simple matters. Without them, no amount of language or technology expertise will do much good.

---

5/20/04 - Fast Company article on how good companies become great. The secret sauce? People. [via Clarke Ching]

Take David Maxwell's bus ride. When he became CEO of Fannie Mae in 1981, the company was losing $1 million every business day, with $56 billion worth of mortgage loans under water.

Maxwell told his management team that there would only be seats on the bus for A-level people who were willing to put out A-plus effort. He interviewed every member of the team. He told them all the same thing: It was going to be a tough ride, a very demanding trip. If they didn't want to go, fine; just say so. Now's the time to get off the bus, he said. No questions asked, no recriminations. In all, 14 of 26 executives got off the bus. They were replaced by some of the best, smartest, and hardest-working executives in the world of finance.

With the right people on the bus, in the right seats, Maxwell then turned his full attention to the "what" question. He and his team took Fannie Mae from losing $1 million a day at the start of his tenure to earning $4 million a day at the end.

---

11/11/04

[O]nly a virtuous people are capable of freedom. As nations become corrupt and vicious, they have more need of masters.

Source: Benjamin Franklin, The Writings of Benjamin Franklin, Jared Sparks, editor (Boston: Tappan, Whittemore and Mason, 1840), Vol. X, p. 297, April 17, 1787.

found at http://www.wallbuilders.com/resources/search/detail.php?ResourceID=21

---

3/25/05

MartinFowler has chimed in on this topic on his own blog:

If I had to pick one as my key to software development it's that the critical element in a software development effort are the people you have doing the work. The productivity of the best developers is far more than the average, much more than the difference in salaries.

He added another article in Feb 08 talking more about the productivity factor:

Although the technorati generally agree that talented programmers are more productive than the average, the impossibility of measurement means they cannot come up with an actual figure. So let's invent one for argument sake: 2. If you can find a factor-2 talented programmer for less than twice of the salary of an average programmer - then that programmer ends up being cheaper. To state this more generally: If the cost premium for a more productive developer is less than the higher productivity of that developer, then it's cheaper to hire the more expensive developer. The cheaper talent hypothesis is that the cost premium is indeed less, and thus it's cheaper to hire more productive developers even if they are more expensive.

---

August 2007

Alistair Cockburn:

People still trump process ... and theory, and ideas.

One of the great things I keep seeing (used to be "keep learning", but at least by now I half expect it when things blow up in my face), is how the individual chemistry between people operates outside of all the nice theory we construct.

Mary Poppendieck (via InfoQ), offers an interesting quote that seems to come across counter to the other quotes on this page:

We get brilliant results from average people managing brilliant systems. Our competitors get average results from brilliant people working around broken systems. - Fujio Cho, Chairman Toyota Motors

Elsewhere at Poppendieck's site, this paper gives more insight:

[Scholtes] says, "All of the empowered, motivated, teamed-up, self-directed, incentivized, accountable, reengineered, and reinvented people you can muster cannot compensate for a dysfunctional system...." So where does this leave us? Which is more important - process or people?

...

[The answer is both, "Process AND People"] ... People like to use effective processes, and they also like to have control over their own environment.... Process improvement may be done only "at the gemba" [the place of the problem] and it is up to the workers to decide whether or not a proposed improvement should be implemented.

Oct 2007

Joel weighs in again, this time via Inc.com:

Mistake No. 1: Start with a mediocre team of developers.
Designing software is hard, and unfortunately, a lot of the people who call themselves programmers can't really do it. But even though a bad team of developers tends to be the No. 1 cause of software project failures, you'd never know it from reading official postmortems.

...

At Fog Creek, we tend to review about 400 candidates for every full-time hire, because the best developers can be 10 times as productive as the merely excellent developers.

DaveThomas in his Herding Racehorses, Racing Sheep presentation at QCon London 2007 quotes Capers Jones from his book Software Assessments, Benchmarks, and Best Practices:

"Without excellent personnel, even good to excellent processes can only achieve marginal results."

Michael Bolton on maturity models:

Maturity Models Have It Backwards

A mature person is one who is highly conscious of when it's appropriate to follow rules and when to break them. A mature person is largely self-guided. Only in exceptional circumstances does a mature person need to refer to or appeal to a rulebook at all.

A rare (on this page) dissenting opinion from Michael Hill (though it does align with the quote earlier on this page from Fujio Cho, Chairman of Toyota Motors, "We get brilliant results from average people managing brilliant systems."):

"XP Requires High-Skill Teams"

This noxious notion burbles around the interwebs in various configurations, as it has since the beginning of XP. It’s mistaken.

I’ve worked with many more low-skill teams than high-skill ones, for two reasons:

I’m not cheap, therefore much of my business comes from teams that are in trouble. High-skill teams can hide and defer trouble far longer than low-skill ones.

There are far too few programmers, therefore the world of commerce has to settle for low-skill (and no-skill) ones. At least 75% of all programmers are low-skill ones.

I keep thinking I should give up before I start when I see a low-skill team. Fortunately, I am really bad at money, so I don’t refuse many clients. This has impressed upon me the complete irrelevance of skill level in adopting and adapting XP.

... and what Michael calls irrelevant, Brian Marick says is missing from the original Manifesto:

[Teams] should invest in one of the four values I want to talk about: skill. As someone who wants to remain anonymous said to me:

I’ve also been tired for years of software people who seem embarrassed to admit that, at some point in the proceedings, someone competent has to write some damn code.

Great summary of test name confusion by Michael Feathers.

You can name tests after their scope: (unit, component, system), their place in the development process (smoke, integration, acceptance, regression), their focus (performance, functional) their visibility (white box, black box), the role of the people writing them (developer, customer)... The list goes on. There are far more than I can remember.

Why is it so confusing? ... The thing which makes testing nomenclature [bad] is that the tests themselves aren't all that different ... we can tell the difference between a unit test and an acceptance test in most systems, but really there is no force which prevents tests of different types from bleeding through into each other.

I frequently have integration type tests mixed into my unit tests, and only after they've gained enough weight to drag out the execution time of my suite will I start to segregate them. My usual distinguishing factor is 'quick' and 'long-running'.

One of the reasons for this is I tend to favor writing tests which roundtrip to a database (for example) instead of using mocks. I'm fine with mocks (though not so much mock libraries - see DiyMocks), but if using mocks leaves a gap in integration tests, then I'd rather start with the integration test and back fill with mocked unit testing if the testing in that arena becomes intense. However, I've found with proper separation of concerns, the places where mocks would be the most useful tend not to accumulate enough logic to make it worthwhile.

Dale Emery also has an excellent article on this.

Michael Hill weighs in on Microtests vs. Unit Tests. Since he linked to his own post on the testdrivendevelopment yahoo group and I didn't see his definition of unit test in his post, I asked him about it:

The biggest single difference is scope, and the second biggest is shipping-reality.

Traditionally, unit tests involve much larger units. A typical old-school example would be a set of unit tests that run against a COM object, regardless of whether that interface involves a single class or 300 of them. Microtests are truly micro, irrespective of packaging.

Traditionally, unit tests -- indeed most tests -- pay very close attention to testing the exact binary image in the exact binary environment in which it runs. Microtests are almost entirely unconcerned with this. Microtests take for granted that they only test that object X works the way it's supposed to *with the assumption* that object X's collaborators work the way they're supposed to.

So you see that although a unit test *could* be a microtest, the word itself has a prior meaning that confuses experienced test-makers who are XP noobs.

If you buy the entire album, you can get it for $4.99 right now at CDBaby: http://pianoalbum.us.

Also available via iTunes (regular price).

Recently someone posted this question on the Test Driven Development mailing list:

What do you do about setting up test data for at system you don't own?

Here was my response:

For repeatability, I try to create tests that can create their own test data from scratch to depend on. This can be a lot of work and yield some large fixture classes. Upsides of this work: you may learn some interesting details of the system and the fixture classes themselves could grow up to become production classes. Downsides: you'll probably make some assumptions/shortcuts in your fixtures that restrict the coverage your tests.

To compensate for that last downside, it's good to also have some rigs (manually executed perhaps) that can load up lots and lots of real data (or copies of real data from production) and run that data through your production code to help flush out gaps in coverage in your automated test suite.

The PragmaticProgrammers have a great analogy for software development which I somehow overlooked (and/or probably forgot) in their similarly titled book. They discuss "software as gardening" in an interview here. An abridged quote:

Software is much more like gardening. You do plan. You put the big plants in the back and short ones in the front. What happens? This plant gets a lot bigger than you thought it would. This big plant in the back died. With a garden, there's a constant assumption of maintenance. We want people to view software as being far more organic, far more malleable, and something that you have to be prepared to interact with to improve all the time.

This interview also references a story of theirs I like to retell, relating to a contradictory law:

As an anecdote, on one project Dave and I were implementing legal requirements in code. These were actual laws that had been passed. We got about three quarters the way through it and realized that the law as stated was wrong. It was inconsistent. If you read through the law one way, it said something had to happen. But in the next paragraph it contradicted itself. Nobody had caught it up to that point, because nobody had tried to do a detailed implementation enacting this legal requirement. This mere mechanical act of coding actually catches bugs in the real world. If you dismiss it as just a mechanical translation, what are you going to do? You find genuine requirements problems while coding. You've got to be able to react and adapt to them.

The Call Graph plug-in for Eclipse will render a directed graph of the visible nodes in the JDT call hierarchy view using a separately installed version of the GraphViz program "dot".

Eclipse versions: 3.0, 3.1, 3.2. (3.4 in progress).

Latest

9/5/09 - Started hacking on a version that'll work with 3.4. I've tried it on two machines so far - one seems fine, the other is experiencing some bugs. If you have any problems, email me details from the Eclipse Error Log.

Version has been bumped up to 1.0.0 (for no real reason).

12/3/09 - Just saw another CallGraph plugin by Certiv Analytics. Haven't tried it yet, but sounds like it may be more polished than my little effort here.

Features

5 new items on the Call Hierarchy context menu, 2 graph actions, and 3 enhanced options for managing the tree (from bottom to top):

Graph	opens a new window with a GraphViz dot directed graph of the current call hierarchy tree.
Merge With Previous Graph	opens a new window with a GraphViz dot directed graph of the current call hierarchy tree adding in the nodes from the current tree.
Remove Node	removes selected nodes.
Remove Sibling Nodes	removes all sibling nodes of the selected nodes. If any of the selected nodes are siblings of each other, all selected ones will be retained.
Isolate Path To Node	removes all sibling nodes recursively. Disabled for multiple selections.

Screenshot

Screenshot from 0.9.7.

(The font used in this screenshot is MonteCarlo)

Installation

From within Eclipse, the Help menu, select Software Updates -> Find and Install...

Choose "Search for new features to install", click Next.

Click the "New Remote Site..." button, enter http://clabs.org/eclipse, then hopefully the rest will be self-explanatory.

To use it, you must install GraphViz and make sure the dot executable is on your system path. Future versions of the plug-in should allow you to input the path to the program, we'll see how long I dink with it.

License

BSD

Source

Source code can be obtained from my SourceForge project, browse it here. Eventually it will be distributed with the plug-in.

History

In 2004, I originally hacked the same functionality into the actual org.eclipse.jdt.ui .jar itself, since I didn't have the patience to figure out how to make it a plug-in (see GraphCallHierarchyForEclipse).

Since Eclipse 3.1 was released in 2005, my hand was forced to go back to my hack (which is only 3.0.0 compatible) and try to make it live as a healthy plug-in.

Contact

Please email me with any comments, bugs, requests, etc.

Plug-in Sites

Eclipse-Plugins.info
eclipseplugincentral.com

Michael Feathers writes about "Ending the Era of Patronizing Language Design", and while I seem to agree, and I also seem to have sympathy for this dissenting comment by Coda Hale:

I've worked on a few Ruby projects which have failed to deliver sufficient business value, and it usually boils down to a codebase in which it becomes progressively harder to reason about side-effects of modifications, even with good test coverage. This isn't inevitable by any stretch of the imagination, but when everything is mutable one must be incredibly disciplined at all times. (And one usually isn't.)

Maybe it's not sympathy, just fear.

It makes me think of the times working in large legacy codebases and being appreciative for tools like ReSharper and Call Hierarchy in Eclipse which helped me proactively track down every code path that could possibly be effected by a change I needed to make.

But those codebases didn't have good test coverage at all. Or good design.

It's not hard to imagine a nightmare legacy scenario in Rubyville, but is that just giving into the fear? And as my friend Glenn writes, nightmares can happen in any language.

[updates at the end of the page]

BruceEckel blogged this:

On the other hand, the WBC summit was really about psychology: why do programmers write poor code and don't seem to care about it, and what can we do to convince them to write better code and to care? At best, we succeeded in enumerating the problems that we had seen, so compared to the other summits we reached no conclusions. But perhaps the struggle was the important thing, and like Weinberg's PSL company simulation, we all needed to have these ideas inserted so we could struggle with them over the ensuing years.

I had a similar conversation with PragDave once. He related an incident with a programmer at a client that seemed 100% on board with unit testing, and then never actually did it. They'd go round and round, discussing doing it, and then it never happening.


Rick Kitts would like a "developer psychology book" (I'm quoting a comment he posted to his own article, not directly linked here...). Sounds like he wants one for the business people, too.




Luke Hohmann says:

Forcing a given team to adopt an approach that they don't believe in ... is a certain recipe for failure.

How do we change their beliefs?

Alistair Cockburn throws a log on the fire of despair:

Somewhere in here is the point I'm trying to make.

* One point is that there really are a bunch of good techniques and behaviors out there, and there are people who use them effectively.
* One point is that most people don't know of such techniques and can't use them.
* One point is that Oh So Very Many People don't have the motivation and energy either to research and learn the techniques, or to apply them. With the very many disastrous results that we see.
* One final point is that the last point limits our hopes of eventual success, whether with agile, with lean, with project management, product management, testing, architecture, etc etc etc. As long as the multitudes can't be bothered, it doesn't matter what great techniques some of us know.

So, in this sense, I'm done with the "60% projects fail, 60% features don't get used" attack (or defense).

Those failures can be ascribed to lack of caring. That has no known antidote.

As Bruce says, this is about psychology and ethics and morals. This is about the spirit and the soul.



This TED talk by Dan Ariely ("Our Buggy Moral Code") I think has some interesting parallels to some of the agile practices to increase the amount of accountability in a group. Dan doesn't use the word accountability, but it's what kept coming to my mind throughout the talk.


see FaithAndBusiness.

Dave Stagner submitted this great post on the pragprog mailing list that I think relates to CompletenessAndMaturity:

Software hovers around the line between barely works and almost works.

This has nothing to do with technology. It's human nature. Given the resources (time, skills, tools) needed to write software that more than barely works, almost everyone from the lowliest hacker to the biggest megacorporation will choose instead to write more software, or more complex software. New functionality is added or new ideas pursued until the software degenerates from "barely works" to "almost works". At this point, either the effort is made to get the software back up to the barely works state, or it just gets worse until it is abandoned.

I think this is an important point in the SoftwareAppreciation category as well. I'd wager most not-very-technical managers of tech would not see something working as 'barely working', only to be surprised when the problems in the future crop up (see also TendingSoftware).

Some thoughts (that need better organization) after listening to 2 Radio Lab podcasts: "Choice" - talking about the magic number 7 (+/- 2) and the experiment with cake and fruit, and "The Obama Effect, Perhaps" [podcast only], talking about the distraction of stereotypes in performance:


DO NOT DISTRACT your technical people. They have a multitude of decisions to make throughout the day in terms of quality (better code organization, testing considerations, etc) which WILL COST OR SAVE YOU MONEY down the road.

Schedule pressures, multitasking, anything that will offer a technical person a conscious or subconscious reason to just move on with less than their best is bad business.

Of course, this whole point is irrelevant to you if you think too much that developing software is BDUF and Mindless (Monkey?) Coding At Back (MCAB).

---

This looks like it could relate, though not exactly sure how. (HT/RT: @marick)

In one study, college students were given one of two menus. One menu featured French fries, chicken nuggets and a baked potato; the other included those same items as well as a salad. The French fries, widely perceived as the least healthful option, were three times [33% of all subjects vs. 10%] as popular with students selecting from the menu that had the salad as they were with the other group.