Live data from Hacker News

Ego-Driven Development

deliberate-software.com

21–30 of 45 posts

Re: Ego-Driven Development

#21

""Not Invented Here" syndrome: Expressed most commonly in a desire for everything needed to be developed in house. E.g.: “Need a CMS? Let’s make our own from scratch!” Perhaps, you work at a place where all your teammates do is constantly bring you bad ideas. Are they really all terrible? Or are only your ideas good enough for the organization? Not Invented Here can also apply to your own head, not just the organizat…

I don't see how you can survive without a bug database. It is useful even for 1-man projects and there are plenty of free ones available.

Re: Ego-Driven Development

#22

There is the other side of "NIH syndrome". In order to "save development time" and implement "best practices" a company decides to use an "out of the shelf" package from a big name vendor (IBM, Oracle, Microsoft, etc) and customize it to their needs. Some initial customization is done and some shortcuts are taken to make the project go live. Fast forward a couple of years. The custom code added by the company complic…

There will always be problems and headaches with off the shelf software, but the thing is that even with all of this you may still save over building it yourself. I worked for years on a Siebel implementation, and even with these issues it was worlds better than the previous incarnation which we had built in house.

Re: Ego-Driven Development

#23

every software company in the US is using pair programming ? is that wrong not having pair programming ?

Pair programming is a great way to get new developers up to speed with the code-base, but the team that is going to be using it long-term needs to apply it with discipline.

I have always thought the concept was great, but I have struggled with how to implement it.

Re: Ego-Driven Development

#24
post #23

Earlier quoted context omitted.

Pair programming is a great way to get new developers up to speed with the code-base, but the team that is going to be using it long-term needs to apply it with discipline.

I have always thought the concept was great, but I have struggled with how to implement it.

My experience: pair programming usually degenerates into having a human version of the annoying syntax checker prevalent in previous versions of Visual Basic, which required you to close the dialog and then fix the error before allowing you to move to another line. "Whoops, you forgot a semicolon there." "Are you going to close that open brace?" YES I'M GOING TO CLOSE IT I WAS GETTING TO THAT ASDFGHJKL;

Re: Ego-Driven Development

#25
post #23

Earlier quoted context omitted.

Pair programming is a great way to get new developers up to speed with the code-base, but the team that is going to be using it long-term needs to apply it with discipline.

I have always thought the concept was great, but I have struggled with how to implement it.

My preferred method for training right now is "promiscuous pairing" http://www.google.com/url?sa=t&rct=j&q=&esrc=s&#...

As for hardware setup, the best I have used is: machines with cloned monitors, two mice, and two keyboards, both side by side so the developers can talk in low tones and not bother anyone else. I do this now at work, and it is a lot of fun, and it really averages to be that we get done more than twice what we would work normally alone.

Re: Ego-Driven Development

#26
post #23

Earlier quoted context omitted.

Pair programming is a great way to get new developers up to speed with the code-base, but the team that is going to be using it long-term needs to apply it with discipline.

I have always thought the concept was great, but I have struggled with how to implement it.

Although I haven't had a chance to try this myself, I've been hearing lots of good things about the practice known as "Promiscuous Pairing". Arlo Belshee wrote a paper about it here: http://csis.pace.edu/~grossman/dcs/XR4-PromiscuousPairing.pd..., and I found an insightful blog post about someone else's real experiences with it here: http://www.semantikoz.com/blog/2012/03/25/promiscuous-pairin...

Re: Ego-Driven Development

#27
post #24
post #23

Earlier quoted context omitted.

I have always thought the concept was great, but I have struggled with how to implement it.

My experience: pair programming usually degenerates into having a human version of the annoying syntax checker prevalent in previous versions of Visual Basic, which required you to close the dialog and then fix the error before allowing you to move to another line. "Whoops, you forgot a semicolon there." "Are you going to close that open brace?" YES I'M GOING TO CLOSE IT I WAS GETTING TO THAT ASDFGHJKL;

IMHO that's either the navigator not knowing any better, or wishing he was the driver, or just being a jerk. The navigator's job isn't to focus on the nitty-gritty, that's what the driver is doing. The navigator should instead, since he's free to think more and look around, keep his eyes on the bigger picture. If the navigator is more skilled or experienced than the driver, then the navigator should be that much more patient and respectful.

Re: Ego-Driven Development

#28
post #24
post #23

Earlier quoted context omitted.

I have always thought the concept was great, but I have struggled with how to implement it.

My experience: pair programming usually degenerates into having a human version of the annoying syntax checker prevalent in previous versions of Visual Basic, which required you to close the dialog and then fix the error before allowing you to move to another line. "Whoops, you forgot a semicolon there." "Are you going to close that open brace?" YES I'M GOING TO CLOSE IT I WAS GETTING TO THAT ASDFGHJKL;

That honestly does happen at first, until you get used to the other person a bit more, then the real speed happens.

Once you really are switching every few minutes, and you learn to trust the other guy to figure that crap out himself, then you can stop watching his semi-colons and start watching ahead for what you are going to do when you get your turn to drive. I have worked with someone like that, and the effect was profound, we would get done sometimes 4-5 days of low bug count, high quality work each day. You have to learn to disengage just a bit and start actually thinking about how his work fits in the big picture, and what you are going to do next, not his spelling errata.

Re: Ego-Driven Development

#29

> developers and managers repeatedly act as if established best practices do not apply to them ... and rightly so. A junior programmer might be better off always following "established best practices", but I expect any developer worth their salt to be able to know when to break the rules .

Is it really a best practice if there's a better way of doing it?

Re: Ego-Driven Development

#30
post #23

Earlier quoted context omitted.

I have always thought the concept was great, but I have struggled with how to implement it.

My preferred method for training right now is "promiscuous pairing" http://www.google.com/url?sa=t&rct=j&q=&esrc=s&#... As for hardware setup, the best I have used is: machines with cloned monitors, two mice, and two keyboards, both side by side so the developers can talk in low tones and not bother anyone else. I do this now at work, and it is a lot of fun, and it really averages to be that we get done more than twi…

@JackMorgan and @dmiladinov, you two have eerily similar timing and views on this one :) Any chance you're co-workers and happen to know Steve?
Post reply on HN