In an ideal setup it’s the job of programmers to do most of the coal-face delivery of code, analysts to figure out what business features are needed, designers to make sure the implementation is good, and architects to focus on technical direction. In smaller projects / teams it’s of course common for one person to be doing all of these roles, which means it’s very hard to get as much focus and inevitably, results win and things like analysis & strategy tend to get glossed over, in my experience. As you say, it can easily be a full-time job to keep on top of everything – which is precisely why the good architects (the real ones, not the ones who just like to use the title) spend most of their time doing exactly this. We used to have access to these kinds of people and it was really very useful – they’d not only do their own small-scale tests but they had access to tens of real-sized projects in the last 12 months, each feeding back practical experiences from their design / senior programming teams on what worked well, what could be done better. It’s not easy to get hold of the good ones, because they’re in demand, but I learned a lot from the time I spent with them.

I accept that most of this is idealistic in Guernsey where you’re lucky if your team is bigger than you can count on one hand. One of teams I worked in was considered small by the standards of the people I was working with, but it had 2-4 analysts, 2-3 designers, an architect (part time, needed less as time went on), 12 programmers, 5 system testers, and a couple of managers. I operated mostly in the designer and programmer roles, and ended up being a local manager and occasional architect. I tried to learn as much as I could from the others while I had the opportunity. ‘Large’ teams have their own problems of course, not least communication, organisation and agility to change, but once you’ve experienced that kind of full-cycle process it’s hard not to want to at least pull the best aspects of it into your normal working practice, and one of those is really trying to keep an open mind about what’s out there. It’s why I’ll happily listen to .Net presentations even though I doubt I’ll use it in the near future, given my particular needs, and why I enjoy debating issues like this. It’s all good, experience-building stuff and I’m sure it’ll all come in handy some day.

At the end of the day I need to deliver functionality because that’s what they’re paying for.

The search for the holy grail combination of frameworks and architecture isn’t what they ordered.

[)amien

“You’ll need some guidance and whoever gives it will be recommending either what they are invested in or what they think is the latest and greatest unproven technology depending on their persona.”

How is that any different to .Net? Some people will recommend VB.Net, some will prefer C#, some (like you) will push the bleeding edge features like LINQ, others will stick with older tech.

“Even 5 solutions to a single problem is too much when you are starting out. It has been described as The Tyranny of Too Much Choice and piecing together software…”

That might apply to juniors, but as experienced engineers / consultants it’s our job to make sure we know the landscape a little better than most and to be able to make these kinds of choices. There is no universal ‘best’ answer of course, but the reason people pay us is so that we can make informed decisions about the best approach for the particular problem at hand. It’s not like we have to do it in a vaccuum, there are a ton of books and articles discussing the relative pros and cons of different set ups. Probably none are entirely objective of course because everyone has their favourite, but as professionals we’re supposed to be able to sift through all that to make as balanced a recommendation as we’re able to. We should be able to leave the language/platform loyalty to the junior programmers and make a rational judgement, although of course we each have our own leanings.

Open source solutions don’t suddenly die but experience a kind of half-life radioactive decay if I understand your other response. They stick around on sites like SourceForge getting little or no attention – is it because it they are mature or abandoned?

Coming to Java for the first time wanting to write a web app is a daunting experience. You’ll need some guidance and whoever gives it will be recommending either what they are invested in or what they think is the latest and greatest unproven technology depending on their persona.

Even 5 solutions to a single problem is too much when you are starting out. It has been described as The Tyranny of Too Much Choice and piecing together software is worse given you must choose a solution before you understand the problem. You could spend months selecting components, tools and framework before starting to deliver real end-user requirements which may, and often do, take you in a different direction to the one you thought you were going in.

Give me a single set of tools to start and when I outgrow one I’ll have a clear idea of what I want to replace it.

[)amien

This actually illustrates my reasons for preferring choice. The ‘one solution’ set up is easier to grasp, but WebForms haven’t exactly set the world on fire. If the one option you’re offered isn’t very good, that’s not a great position to be in. In an open source world, there might have been 5-10 projects targetting this, and the rubbish ones would just fall by the wayside, leaving a small number of good options. Which one you like best is down to precisely what kind of application you’re making and perhaps personal preference.

True in some cases, but very untrue in others. By ‘actively developed’ perhaps you mean ‘adding more features’. There are a ton of cases I can cite where adding new features is just disruptive – if a solution does what you need, and it’s getting bugfixes, that’s enough. Stable systems are stable because they don’t change that much. When I’m developing on top of libraries, I actually prefer if they’re not changing much, beyond routine maintenance, because changes underneath me are a distraction. Of course that only works if the solution is mature enough in the first place – and I personally find that Java frameworks are more mature, so don’t change anywhere near as much as .Net does. Personally I view that volatility as a lack of maturity rather than an attribute to be lauded.

Re Devil: it had bugs that weren’t getting fixed, that’s why we switched – it had nothing to do with wanting an actively changing feature list. Had DevIL been fixing bugs more often it would have been less of an issue, because feature wise it was fine.

There tends to be one obvious way to do things based on what is provided in the .NET box. If you want to write web apps WebForms is where you start. Where you start with Java is anyone’s guess.

A project not being actively developed is as good as dead unless your project isn’t moving either.

You yourself have had first hand experience of this with the graphic file format decoding mechanism you used in Ogre3D. You wanted to support Mac OS X and newer formats and Devil wasn’t moving so you switched to FreeImage. The fact the source was open might have been fine for a bug fix or two but you certainly didn’t want to start maintaining image loading code or you’d have not used a library in the first place.

[)amien

What makes you think CVS is dead? It’s just stable, and needs few updates anymore. Sure, SVN is the current darling (I use it for new projects too) but that doesn’t for a second that existing CVS repositories aren’t perfectly happy the way they are. This is something I have a major problem with – people thinking that ‘no longer fashionable’ means ‘dead’. If we go by that rule, .Net is dead and Ruby is king (in a couple of years it’ll be something else). It might be the case in the proprietary world because suppliers deliberately EOL their products to sell you a new one, but popular open source projects don’t die – ever. Unfortunately you don’t have a lot of choice in the .Net community so perhaps you’ve ended up backing projects that didn’t have much serious long-term support. Fashion is fickle, what matters for investment in real systems is stability and maturity. Mature systems might be boring, but they work and are here to stay.

“Competition is important but I can not, in a professional capacity, recommend to customers something that I believe is less suitable in the interest of keeping the competition healthy.”

You’ve got that entirely backwards. It’s not a case of ‘keeping competition healthy’ at all – competition is always in the customer’s interest, it’s basic economics. You may have never experienced the detrimental aspects of a lack of competition, but that doesn’t mean they don’t exist.

“Have a support contract with somebody else to work on it (single-supplier scenario?)”

Paying for support isn’t a single-supplier scenario, it’s just a safety net. You don’t need it, you’re not forced to take it, and it has no bearing on your use, development or deployment of the product. Single-supplier issues are about a lack of consumer control; taking out an optional supplementary service doesn’t affect the underlying dynamics of who controls what.