+972 52-548-6969
Can you succeed without good people?
The answer is a sound yes, but for a given value of success.
A bad team can still get a product out, and that product may even be successful. But the cost that this requires is far greater than it would have been otherwise, often to the point where you have no choice but to scrap the project. The really sad part is that some people accept this cost as the true cost of building software.
Oh, and good people doesn't necessarily equate to experts.
You need a few good people, but the rest of the team can follow fairly simple check list approach to development. There are a lot of stories about teams like that, and most of them end with a big project failure. Usually, this is because there was a hard separation between the people the business consider as the high end and the regular developers. This usually cause the people who actually dictate the architecture and shape of the system to become totally oblivious of any design issues that they may inflict on the rest of the team.
Having a mixed team, with the architecture and the implementation done by the same group, is a much better proposition in the long term. Note, however, that I am explicitly not saying that the whole team should take part in the design. This is an ideal circumstance, and I haven't found it to be either common or even desirable in many cases. Design by committee is rarely a good idea, and I much prefer either design by addition or design by feature / feature batch. Again, those depends on the type of team that I am working on.
Another thing to note is the difference between technological experts and business experts. In both cases, we are talking about developers, but in technological experts are good for one thing, clearing the way so the developers who actually understand the business can get things done, fast.
I will reference again my posts about JFHCI, as a good example of how I think those things should be done.
Comments
Any metrics on how you define "good people"?
This is how we currenly run our project and it works very well (re: the team and the architects both responsible for implementation). I can't say enough good things about it, I wish we had been able to make it happen earlier but I am very thankful that we finally did make it happen.
In my experience you have more chance of success if you have the architect (or one of the architects) writing code too. Even when you have not-so-good people. This has the following benefits:
It prevents the architect foisting (and persisting with) a design on the devs that turns out to be painful/unproductive.
"Less good" people on the team have a pair to work with to bring their understanding up or at least someone who can police their code (people who don't understand the design often violate it in amazingly ingenious ways!).
It breaks the us and them issue where architects sit in their ivory meeting rooms posturing around whiteboards, while the man at the coal-face suffers.
It keeps the architect honest (sometimes). It stops them from turning into someone that just designs whatever they last read in MSDN magazine.
IMO the architect should not feature on the plan, or rather they should be free to float around the team and the coding activities as needed.
Of course, being an architect that also writes code, I am biased!
From the real-world, I know a ISV company made of 10 persons, 5 developers, 3 sales persons, 1 administrative + CEO.
I am pretty sure that none of the developers (all ex VB6 developers) know anything about for example, boxing, parametric polymorphism, JIT compiler, or principle of hash tables.
The company is doing more than 4M euros per year, started 10 years ago and was sold recently 15M euros.
Does it answer your question:
Can you succeed without good people?
Patrick, just because they know nothing about boxing, parametric polymorphism (what?), JIT compiler or principles of hash tables, doesn't mean they are not good developers. It just means they have a different set of tools to work with to produce their software.
@Patrick - Who knows. Perhaps the company should have been worth 25M Euros ;)
Good people, are people that achieve the company objectives. You can't always define good people in terms of the tech they know.
I would clarify "bad" as stagnant. Any team that's learning and moving forward is a good team--regardless of their skill level.
But yes, in general, I agree with your points 100%.
I don't agree, did I mention they refuse unit test and Source Code Control System.
A developer must indeed achieve the company objectives first, but one can't do good code without knowing anything about what happen under the hood. This is the VB6 way of thinking.
The lesson from the company I mentioned is that you can make a lot of money with bad code. But a non-educated developer can't do good code. This is 2 different ways of measuring success.
@Patrick - IMO not using Unit Testing and Revision Control is in a whole other Universe of bad to not understanding JIT compiler etc. However, I basically agree with you and is covered by what I said in the last comment. To elaborate, I believe companies should make good code one of their explicit objectives. This includes defining what good code is. It then follows that if someone achieves that objective, they must be a good developer!
Of course, sometime it seems that some companies think bad code is good code, because they can bill loads to maintain it!
Comment preview