I’m not saying it’s a good idea. I completely agree with your point. I’m just saying that the people who decide to protect the developers might not care about the downsides you point out, or might have already concluded that it’s cheaper to work around them than to fix them.

When contracting I have often found that doing advanced techniques gets the criticism from “in house” developers as they do not want to have to code outside there box of knowledge. This is the type of attitude that is worse than guidelines or libraries as it usually provides a negative impact on the dev’s and the end users.

If they aren’t introducing needless complexity, and the devs really don’t want to learn, i’d suggest writing some docs about it. It might be boring, but that way you’d only have to waste time on explaining it once. And for those devs that do care, you can still go through it with them

But i’d really try to look at the root cause as to why they don’t want to learn (or appear that they don’t want to learn)… there might be a bigger problem lurking there

In my group, similar things are happening. But, the difference is, there are some people who do not want to learn the new way of doing things. I am currently working on creating an application framework that works similar to plug-ins. There are many interfaces and base classes to learn and use. I am using dependency injection (using spring.net) and nhibernate for DAL. People in my group, who will be using those, want me to simplify them further because they think they will not be able to grasp and understand how to whole thing fits together. I have been trying to educate them by sitting with each developer and explaining what is what.

Looks like in this case, I will need to hide certain things from them.
Any suggestions on what I should do?

with protecting, i mean it’s more about hiding power that could potentially be used wrongly. Instead of fearing that developers will make mistakes, and thus hiding power from them, i think it’s better to invest time into educating them so they are less likely to make the mistake in the first place

opinionated api’s aren’t really an example of that, though they certainly can be. Having one and only one way of doing something isn’t wrong, unless that way isn’t sufficient once you get beyond the trivial stuff.

I have been moving to more and more to having a highly opinionated api. This will basically setup a mechanism where there is one and only one way to do something. Am I protecting developers and myself by creating an opinionated api?

And I think that’s the point Davy wants to emphasize (correct me if I’m wrong) … teaching less experienced developers is important, but from a business point of view, when you start to have several development teams that needs to coordinate and all apply the same guidelines & best practices, it makes total sense aim for maximum reusability & higher abstraction levels.

Otherwise, we should all quit our fancy UIs and go back to the command line ;o) lol

Sadly, the framework was given in closed-source form for exactly the kind of protective reasons I think Davy is talking about. Whether I liked it or not, this worked relatively well in the beginning. Problems were quickly dealt with and guidance was always available – until after a few months things got a bit busier. We ran into a problem (actually, more of a missing feature) but were unable to get help because everyone at the competence center was busy helping out on other projects. After losing plenty of time trying to go through the ‘correct’ channels, we used reflector to decompile the framework, learned how it works, made the necessary modifications and went on using that version instead. I left before the project was finished, so I’m not sure if the modifications ever made it back into the official version.

I’m not saying the framework was a bad idea, but if they had chosen to given out the source code to developers instead of ‘protecting’ them from what was going on, not only would we have saved alot of time, but it might have educated those few developers that would have had the interest in looking at the source code while using the framework.

i’m sure in all of the examples you mentioned, the originators of the ideas had the best intentions in mind. the fact it got screwed up (e.g. that state machine that was horribly misused) is most probably just the result of bad follow-up. which you will need to do anyway, whether you hide all the difficult stuff or not. just make sure that if you do, everyone GETS why it’s done like that
i don’t think guidelines/principles of any kind are bad for a team working on a project (as long as it makes sense and you’re not overcomplicating…)

@rce: yeah that’s pretty retarded

Wow Davy, I am kind of withthe other poster. I have never seen this behavior in people before. I agree with idea of your post but never ran into the situation.

i’m not saying that you shouldn’t offer reusable libraries… i’m saying that you shouldn’t _hide_ things that you deem as too powerful or potentially risky behind these reusable libraries

as for practical examples… one thing that i’ve seen way too often is that people offer datalayers that are easy when you’re doing simple stuff, but don’t really offer a clean way to do more powerful things. I once tried to introduce NHibernate at a client, and their initial response was “NHibernate is powerful and can be misused very easily… we should wrap it and make sure people can’t access it directly”. It would’ve worked great for simple stuff, and it would’ve gotten very messy once you need something beyond the simple stuff. Codegen’d DAL’s often show the same problem IMO.

Another example was also at a client where the Microsoft consultants basically wanted to hide exception handling from application developers because “they don’t understand it anyway”. Which led to a shitload of code where people were constantly checking return values, which was obviously a lot more error prone than typical .NET exception handling code would’ve been.

Another example was a ASP.NET Webforms based state machine which did all of the navigation and state management that you typically have to do on your own. The developers were writing pages and use cases with it, but they no longer thought about it… which lead to horrible abuse of the state management that was provided because the developers weren’t properly educated on how to deal with state management in a web application.

ViewState in ASP.NET is another nice example… it’s an easy to use abstraction so developers can do some form of state management in an easy manner without using server memory for it. Until people dump everything in it because they don’t know any better.

There are tons of examples available…

Still,
if you can abstract a certain reusable functionality to a library that can be reused by other people that need it in your company, why shouldn’t you?
As a matter of fact, i think we do it that way… Or am i totally missing the point here?