""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…
Ego-Driven Development
21–30 of 45 posts
Re: Ego-Driven Development
#22There 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…
Re: Ego-Driven Development
#23every 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.
Re: Ego-Driven Development
#24Earlier 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.
Re: Ego-Driven Development
#25Earlier 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.
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
#26Earlier 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.
Re: Ego-Driven Development
#27Earlier 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;
Re: Ego-Driven Development
#28Earlier 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;
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 .
Re: Ego-Driven Development
#30Earlier 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…