Stupid Question 129 and 130: Should you and how do you introduce new technologies in projects, and who pays?

I'm a freelancer who charges on a fixed bid basis for projects, so my perspective may be different from that of many others. Here's my philosophy:

My clients aren't paying for lines of code. They are paying for a business solution. My clients rarely care about the technology specifics (although there may be constraints based on their environment). I have to provide a solution, and if I pick a technology or approach that doesn't work, then I'm responsible for addressing it. So I have to be careful about my choices so that I don't waste time on solutions that must later be abandoned. (And yes, this still happens to me occasionally, although it is less likely to be a whole technology that fails me, and more likely to be an approach that I try that won't work.)

However: I price my projects in part based on how interesting they are to me. And learning something new is valuable to me. So if I am able to learn something that I think I will be able to leverage in the future (and not just something one-off), then I may price the project more attractively. If I don't learn anything new from the project and it is kind of boring grunt work, then I may charge more. 

Also: I am careful to limit the number of new things to learn in a project. The more new things, the larger the risk. And I research how much information is available online. I worked on a project once that required integration with a third party tool, and there was almost NOTHING about it online. I won't make that mistake again. Ugh. 

Staying current on new technology is just part and parcel to the job.  I tend to research and test out new ideas on my own time, and only present them to my team when I know they will work.  Once we have established that a product, framework, or idea is viable for the project, then my company doesn't mind bringing everyone up to speed on it on company time.

Sure, this means I devote a lot of free time to something my coworkers will eventually get paid to do, but when bonuses and raises come around, my efforts are recognized, so it certainly doesn't feel like wasted effort. 

My workplace is a production facility, not heavily into application development, but they have a decent development team. My colleagues were used with "Page Controller Pattern", for development, where all Display Logic, Business Logic and Data Access were packed together in one place(layer), and of course no Unit Tests! (They still maintain classic asp application)

When I was entrusted to work on a major software with abstract ideas, the Project Manager advised to stick with a "simple architecture", since some project I worked alone on n-Tier model.  But colleagues were happy to embrace n-tier model in this project.

Later we have introduced Unit Tests. We started the project from abstract ideas, so had to re-factor the code many times.The layered design helped us to easy to re-factor without breaking other layers, and unit tests ensured that re-factored code does not break. 

My point is new technologies introduced with good mentoring can can save the team from debt, but can add value to projects in the long run. 

You just made me google Page Controller Pattern - I think it will make it in the Stupid Question series :D (I've used it - not using it all now, I just wasn't aware of the name).

What a great example by the way- and answer. 

Here in Brazil, specifically in Sao Paulo city, the demand for new technology comes from the customers. Software development is a third party task for most companies, so they keep just few specialists in their internal teams to take decisions about which technologies to use. The announce of a new project is public for consulting partners and these contractors move the market, but slower than worldwide. Thus, the time is enough, but it's up to you to learn new things and be aware that your new knowledge couldn't be ever required.