Yes, but choose wisely. :)

Back in the late '90s I worked for a company that had their own home-grown Java Web application framework. It was conceptually clean, ran fast, and was fun to work with. URLs mapped to classes and methods; example.com/foo/bar basically located and loaded the Foo class and invoked the bar method. Domains were used to select "skins": XSLT files transformed the output. Internally it was URLs and XML all-around, making it easy to grab and verify data.

(I realize that describing an application framework using the words "Java", "XML", and "XSLT" might cause some to flinch. Believe it or not this was a really, really sweet tool. I was lucky to work with some very smart people who wrote very good code. We took some liberties with how XML was handled for some interesting parsing advantages. Not a fan of XSLT, but I learned some useful coding techniques.)

Teaching this to bright and motivated developers was not hard. It ran on relatively low-powered commodity hardware and customers loved it. Everyone was happy.

Then the company was acquired, and the new bosses decided that they didn't want to have to train new devs on some hand-rolled framework. J2EE and EJB become the new frontier.

Yes, it was easier to find devs who already knew about EJBs, WAR files, and so on. Was it worth it? No. In this case they would have been better served keeping the old framework. It was just better.

If your company is using custom tools and you are concerned that this will make it harder to bring on new developers consider how your tools tack up against what's publicly available. Maybe the better choice would be to open-source what your're using, or just take the hit of training people when they get hired.

If you make things too easy for run-of-the-mill developers you may end up with run-of-the-mill developers.

I could make those XSLTs sing man. I made a pivot table out of XSLT, no shit. It was amazingly fast compared to the IE7 javascript engine. Orders of magnitude on masses of data, it actually was amazing.

Know how many times Ive used my crazy mad XSLT skills since?

Never.

In reality, your framework sucked. Just like ours did. The lack of just being able to google stuff slowed everyone down massively. The lack of extensive code examples slowed everything down. Doing the easy stuff was amazingly fast. Want to do something creative or complicated? NO!! That custom framework held back the talented programmers in so many ways.

And because every problem was novel and usually caused by some restriction in the framework you learnt solutions and patterns that you never, ever used again.

And when they left your company, those talented developers suddenly found themselves 3-5 years behind people who would previously have been their equal. They had effectively learnt a completely useless programming language.

I think the lesson is that tech is a harsh industry to be in regardless of which tech you choose, and you should count on your skillset being obsolete in 3-5 years regardless. And your goal should be to learn the latest and greatest as quickly as possible, grab all the riches and other goodies around you while you can, and bank them for the lean years when the industry completely shifts around you and you have to learn something else.

Also key is to not let what you're told to do at work decide what you're going to learn. Even if your current company is using whatever is the latest and hottest framework you need to be learning other languages, other ways of doing things.

Here's an anecdote: I did some consulting work for an Indian-owned company in the US. I was helping out with some Rails stuff. It was a curious case of out-sourcing reversal. They had a hard time finding devs in India to do Rails because those developers felt that Java and EJB would be better for their resumes so that was the work they went for.

No, that's like your experience man. Mine has been different, and I've worked with stuff from Portlets, Struts and Webwork (remember those?) to Django and Express.js

Domain specific knowledge doesn't cause this. If you are limited by how much of it you have or don't have then you have a long way to come as a programmer... having used a language or framework before is only really useful so that you don't get snagged by gotchas or weird and wonderful eccentricities of the framework or language.

In reality getting employed is more difficult without experience on a CV, but if you are intelligent and can get an interview its not usually a problem - smart people know, or can be taught quickly, the lack of value specific experience has in most contexts (i.e. anything where you aren't just urgently crunching something out of the door). :)

Well, at the time it was alta-vista not google we turned to. :)

The code was pretty straight-forward Java (about the most clever thing was use of forName and assorted reflection), so finding stuff was not a problem. We had many examples; examples as part of the rather good documentation was important for us.

We tried to avoid doing anything complicated. That was part of the point. Negative lines of code was a win.

It was easier to work with and figure out and extend than the alternatives at the time, and arguably still cleaner and more light-weight then what came after.

When the time came to move to some standard Java thing is was no easier (and often harder) to find decent examples or docs.

And because every problem was novel and usually caused by some restriction in the framework you learnt solutions and patterns that you never, ever used again.

No, not at all.

I really don't get this broad dismissal of all in-house frameworks. Is it so far-fetched to think that a small group of smart developers with business domain knowledge can build fast, lean, code? Maybe I was just lucky to have experienced this, but I don't think it's so rare.

The code was good, clean, Java. We ran into some issues because of garbage collection (we were really pushing things for speed and memory) for some related code but roadblocks due to our basic tools were rare.

Somehow we avoided over-engineering stuff. It actually worked, and worked well.

And when they left your company, those talented developers suddenly found themselves 3-5 years behind people who would previously have been their equal. They had effectively learnt a completely useless programming language.

Again, no, not at all. They had little trouble picking up EJBs or whatever was the Java-du-jour, if they needed, but unlike devs who only knew how to piece together beans and JSPs (basically plug-and-play coders) they knew how to handle things when stuff didn't work as expected or as the docs insisted. They could actually program because they actually knew the language.

Contrast this to people who learn, say, only Rails, and Rails conventions, and write very little custom Ruby code. They're at the mercy of the framework because they're married to a particular tool rather then being immersed in the underlying language. Ideally if one picks a framework one should also really learn the underlying language, but given a choice in hiring I'll go with the one who knows the language over one who knows a framework.

Perhaps not every case of using your own custom tools, well-designed for the task at hand, is the same, or does not work out well for every type of programmer.

I have worked places where they used poorly-conceived in-house tools, and it was not good. But that's not the case everyplace, and a business can get a competitive advantage using tools streamlined for their domain.

http://www.php.net/manual/en/history.php.php http://en.wikipedia.org/wiki/Django_(web_framework)#History

I've had people tell me about in-house tools they use, and some sound quite good.

One reason some companies do not release their source is because part of their business is in the licensing of the code. If a client could just take it and have others work on it because it was fundamentally OSS they'd lose that.

But hey, XSLT 1.0 runs in like, every browser in the world, and is practically designed for emitting DOM. I wonder why it's not used more often.

XSLT is a functional language with a very weird syntax, and a very domain specific default mode - transforming XML trees in streaming mode. XSLT was the translation of SGML's DSSSL [1] into an XML syntax, DSSSL is (was?) a subset of Scheme.

XSLT is actually a pretty good tool for streaming "push" templating - writing a stylesheet that generically specifies how to handle certain kinds of elements. It really sucks at "pull" templating, i.e. writing the result and indicating where data from the input should go, how most templating languages work.

It turns out "pull" templating matches the mental model of most people much better, is easier to understand, and is in particular useful for ye olde typical website. On top of that, it inherited XML with all its baggage, and is forever coupled to that one particular data model.

I'd still use XSLT if I had to format something like a book, or a massive manual. Put for formatting programmatic results in a web app, I never would.

[1] http://www.jclark.com/dsssl/

And for that I found I was happier using a streaming parser and writing event handlers to grab data as it went by and formatting as needed in my handler code.

XSLT might be a good fit if your logic depends on whole-document handling. For example, you need to know how many foo elements there are in order to generate a TOC. Or something where you're explicitly working of irregularities and optional data so you need to have the whole XML doc at hand and apply your transformations "all at once" so to speak.

It's probably best for a business, if you want to give your employees experience architecting a framework instead of just using one, to standardize on something like Angular.js/Ember/React/etc and then encourage/incentivize your employees to become contributors to it. Almost best of both worlds - benefit from using the framework, and employees get valuable experience, resume builders, and connections. Only thing they miss in that scenario is architecting a framework from scratch, which is something only your early employees would have gotten to do anyway.

It helped us to begin with, but my view is you have to factor in what the abandonment cost might be when the industry standard starts pulling ahead of you, and that could be big. As soon as it looks like the industry is settling on a standard way of doing something, start skating to where that puck will be.

You really shouldn't be doing (2) unless you've had several go-arounds with (1). (3) is, of course, undesirable.