Agree with your initial point. It's quite easy and intuitive for us non-designers too. Been using it past couple of months and prototyping my apps here.
Don't agree on Unit test being trivial. Infact, it is one of the things that aid you with changing specs and code. It helps you change your code with confidence. That really matters.
I appreciate your overall point, had just one correction. thanks.
I should have explained what I mean by trivial: I think any competent programmer knows the value of testing. So in that sense saying that you should write tests is like saying you should write good code - it is true, but not very insightful.
In a time constraint environment, you often need to make a choice between more tests and more features, etc... I have seen a lot of people who said their code was great because it was well tested, but then the tests depend so much on the implementation that it actually goes against better code (since refactoring may mean breaking a lot of unit tests). So the more interesting question is: what to test, how, and how far. For example, my own rule for testing is that in general, I don't test something if testing it takes more code than the feature itself (except for regression testing, and things which really play well with testing, like parsers and the likes, and code which needs to run on many different platforms).
It is also useful to recognize when testing has value, and to avoid overestimating its actual benefits. Too often, people don't really think about failures when testing, or how the API it exercices can be used in a straightforward manner or not. For example, I don't get so much the value of TDD - I find it much more useful to think in terms of API usecases, for which small tests are often not well suited. Sure, designing for easy testing can help, but you can get the same benefit without TDD in my opinion.
Finally, too often, I see "this library is well tested" sold as a feature in open source projects - but test coverage is not a feature. Sure, everything else being equal, I would prefer a well tested library to a not well tested library. But everything else is not equal: there is a constant tradeoff between designing better API, getting a better documentation or installation process and testing.
@RiderOfGiraffes The write-up is about a bottom-up approach in making organizational decisions. Most of the decisions as we know are made right at the top, with minimal understanding of what people on the ground are actually thinking about.
Once you start listening to your people and pick your organizational directions from there, the whole decision making process gets more efficient.
Keep the floor open for different kind of discussions. Keep looking at what discussions are catching heat (more people talking about it). Pick your directions from them. That was the intent.
Eg. Which technology is the most popular among our folks? What kind of clients are liked by our folks? What kind of work do our people prefer? etc. etc.
* For these sorts of decisions, why not empower the employees to do things without requiring decision/dictats from on high?
* Most "chat" in forums like the ones you seem to be suggesting are a genuine, complete waste of time, and ...
* Most proposals from "the floor" have been really, really poorly thought through, and just won't work.
Now, let me say that I agree with what you're trying to accomplish, and that your comments/thoughts have some merit, but as they stand they seem poorly thought through and unimplementable in practice. I'd really like to see you have something more concrete and practical to suggest that solve the problem you think you've seen.
I manage a company with around 30 employees - not real big, but the sort of shop where your ideas might be relevant, especially to implement them before we get any bigger and change is harder. However:
* Which technology is the most popular among our folks?
We let them use whatever technology they want, provided they can then justify their decision. We empower our people to make decisions and stand by them.
* What kind of clients are liked by our folks?
We don't have a choice as to our clients. We have multi-million dollar contracts in a fairly small market.
* What kind of work do our people prefer?
I don't understand how that kind of question can be made relevant. Our database people work on database stuff, our embedded people work on the embedded stuff, our user experience people work on user experience stuff, and everyone talks to everyone else, because all of the software modules talk to all the other software modules. If a database programmer wants to work more on the embedded side then he studies up on his own, asks for some tasks, gets given some tasks under supervision, then his skill set is bigger and the task allocations can be more favorable to him.
In short, it sounds like you're sounding off without really thinking about how things really work. I'd like to see a better, more thought through presentation.
Finally, it might sound like I'm attacking you, or picking on you, but I am genuinely interested in any ideas on how better to manage. I'd hoped there was something interesting in your article, I feel like there's a hint of something interesting in your article, but then it all went away and feel like I was left with nothing.
@brazzy yeah.. that stands out a bit. It just means that technology is chosen without understanding what it is for. There are so many choices available nowadays.. e.g. if one needs faster development/release cycle, you choose Rails, etc..
@satyan - absurred should be absurd, in the article. I can't help nitpicking spelling/grammar mistakes. Sadly, they seem to be so commonplace on the internet.
