Ego-Driven Development
deliberate-software.com
Ego-Driven Development
1–10 of 45 posts
Re: Ego-Driven Development
#2every software company in the US is using pair programming ? is that wrong not having pair programming ?
Re: Ego-Driven Development
#3every software company in the US is using pair programming ? is that wrong not having pair programming ?
No, not every company uses it, nor is it good for every company or circumstance. It is just a smell that the developers do not believe that working with someone else will help them increase their quality or speed. Some developers really are fast enough that it would slow them down to pair, but then generally, their slower team members might be hugely benefited by just a few hours a week of pairing. So it is a trade-off, do they go fast alone, or go pretty fast with a partner, and increase the _total_ productivity over time?
Re: Ego-Driven Development
#4every 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
#5""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 organization."
The answer is yes, they (CMSes) are all terrible. :)
"No dedicated QA for externally-facing software: Someone who is experienced at breaking software should have a crack at it before it goes to users. Developers (including me) are too enamored with their own work to really take the time to break it, so someone with a sense of pride in finding problems needs to be given the task."
Having dedicated QA is not always good. In fact it is often counter-productive.
"Low Joel Test score: The Joel Test remains a great indicator of institutional ego. A team that scores low on the Joel Test does so because someone along the way decided that, "nah, we don't need that here, we are special", and almost certainly they are not. I have yet to hear of a team with a legitimate reason for a low Joel Test score."
The joel test is actually quite out of date. Specifically the stuff about fixing bugs before writing features, hallway usability testing, testers, having a 'spec', and having a bug database are all not necessary or good to have in all cases.
Re: Ego-Driven Development
#6I used to apply the Joel test religiously, but I've gradually come to the opinion that dedicated QA is a net negative. It creates a natural opposition between two halves of what should be the same team, and removes the focus that comes from knowing that what you create will be what's deployed. It also adds friction that goes against the agile "deploy early, deploy often" approach.
Re: Ego-Driven Development
#7Sometimes it's not so much "NIH syndrome" as "Everything else really, truly is crap". Scottschulthess mentiones that all CMSes are terrible. Some of my colleagues, for example, needed to spin up hundreds of virtual machines very very quickly, and as it turns out, OpenStack is absolute crap. So they took 2 weeks and wrote something a fraction of the size of OpenStack which can have hundreds of virtual machines running in the time it takes OpenStack to boot up 1/10th as many... and crash.
Re: Ego-Driven Development
#8Sometimes it's not so much "NIH syndrome" as "Everything else really, truly is crap". Scottschulthess mentiones that all CMSes are terrible. Some of my colleagues, for example, needed to spin up hundreds of virtual machines very very quickly, and as it turns out, OpenStack is absolute crap. So they took 2 weeks and wrote something a fraction of the size of OpenStack which can have hundreds of virtual machines running…
Yeah, that is very true. These are meant to be smells, just something to watch out for. I personally think its impractical to remove all smells, just to be wary of having too many.
Re: Ego-Driven Development
#9""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…
> Having dedicated QA is not always good. In fact it is often counter-productive.
Maybe 'dedicated QA' is a bad but a developer must at least be point man for test, even if the responsibilities aren't 100% of their workload. One could argue that having a horde of peons to click randomly is counter-productive, but teams >6 or so need a specific dev responsible for automating test. Its too specific a domain, and intermittently demanding, and to force all devs to split the duties.
Re: Ego-Driven Development
#10""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 wouldn't say that a perfect score means you are good to go, but just that it is a list of things that either should be addressed or deliberately discussed and weighed. You want to make sure that you are leaving in known bugs, not using a bug tracker, or not having requirements for a a very good reason. If the reason is "we are a one man shop, and I am fine without it", OK, just realize that will not scale very efficiently.