Ayende @ Rahien

Casey commented on Scaling ALT.Net Concepts

Sun, 14 Oct 2007 08:36:40 GMT

>>You've had one bad experience trying to sell better techniques to an organization and yet you come to the conclusion that it is "near impossible" to sell better techniques in any organization. << Not one experience, many many many ... I've had many small successes along the way, but wholesale adoption has no benefit to most organisations - maintainability is something the next manager or director will have to worry about. This one has to worry about budget for this year. Also remeber I contrasted this with the Java world where this discussion started. In the Java world these things aren't considered ALT.Java, because for the large part, they are the norm ... design patterns, rails, ORM, IoC, unit testing ... all Java concepts introduced to .NET as ALT.NET ... because in Java they are just done that way on almost every project. Pete w sees the issue, Java developers don't rely on Visual Studio, because in the Java world you may be asked to use any one of 10 different IDEs, and any one of a dozen different frameworks ... a .NET developer can make a (very good) living just dragging and dropping

Michael Morton commented on Scaling ALT.Net Concepts

Sat, 13 Oct 2007 21:57:59 GMT

>> Having been in this situation in my last role, where as the architect my job was to convince the organisation to use better techniques for a *massive* enterprise project, I can assure you it is near impossible. << You've had one bad experience trying to sell better techniques to an organization and yet you come to the conclusion that it is "near impossible" to sell better techniques in any organization. Casey, I'll be honest with you, that's just not true. There are serveral job openings in my area looking for people with NHibernate experience and these aren't small companies. These are global companies that are building sellable products with NHibernate and other .NET OSS offerings. Also, I've been able to sell the benefits of using MonoRail / ActiveRecord to my company and now our global customer portal is built on top of it. In reality, if it was "near impossible" to convince organizations to use better techniques, there would not be any better techniques *to* use and we'd still be programming with punch cards. Problems change, better techniques are created to better solve those changing problems, and judging by the evolution of our industry, organizations are adopting them. Just think back... - I remember, personally, having to convince others on the benefits of the .NET Framework, of C#, and of ASP.NET. - There was a time when people had to be convinced on the benefits of C++ and OOP. - There was a time when organizations had to be convinced that the internet was the future of business. A lot of the techinques and technologies that you would consider run-of-the-mill and take foregranted, simple would not be here today, if it was "near impossible" to convince organizations that they were better techinques / technologies than before and that they should use them.

Pete w commented on Scaling ALT.Net Concepts

Sat, 13 Oct 2007 13:09:40 GMT

Casey--- I think I understand where you are coming from. I wanted to apologize for my smart remarks earlier; it is bad form for me to label the majority as "lesser programmers" just because they take more time to adapt. I would like to share a story with you: There was this big company, with a team of very clever programmers. They were wizards with C++, most of them had been programming since the 70s, and .NET was new to them and the management. What do you do when .NET is new and the company refuses to pay for training? You learn by the basic examples bundled with visual studio. Do you remember the first time you saw the datagrid wizard, how you could drag and drop tables into a strongly typed datasets, and you had your app up and running in seconds? There are some many of these examples. They were led to believe this was _the_ best practice for developing in .NET. One thing about datasets: they bring the relational data directly into the object realm. Writing all of your business logic around datasets in .NET is not unlike writing all of your business logic in stored procedures: you are working with tables, not objects. Nonetheless, they rolled their own persistence framework, sql generators, it was clever, and it worked. It was like NHibernate for datasets, and it was not pretty. I arrived, I looked at their code for the first time, and I got a migraine headache. What to do? I can recommend to rewrite most of the application, but they will not listen: they became skilled artists with the dataset. They were insulted by my criticism. NHibernate/windsor is not bundled with visual studio, it has no wizard, it is not worth considering. Time passed by, and an alpha release was presented to the client. The UI was confusing, everything was a datagrid, and it was almost impossible to run the application without strange relational exceptions popping up. How embarrassing to present this to the client! Finally, they were open to learning about NHibernate. They caught on quickly and naturally. We had a good laugh about datasets, and they are now learning things like MVC and IoC. They felt like they were bamboozled by microsoft's recommended best practices. The thing is, when you get eclipse, you get an IDE. When you get visual studio, you get IDE that is bundled with an extremely rich framework. The framework is so rich that people assume it is the one and only framework you will ever need. Their idea of learning new technology is reading the start page on visual studio before they open a project. So now, is anything that doesnt come bundled with visual studio considered "ALT"?

Tobi commented on Scaling ALT.Net Concepts

Sat, 13 Oct 2007 12:02:57 GMT

Ok, time to feel stupid - implicity operators - I see and use them so rarely, that I don't recognize them when one jumps into my face :( I still don't like the use of the null coalescing operator her, maybe just a matter of taste.

Ayende Rahien commented on Scaling ALT.Net Concepts

Sat, 13 Oct 2007 10:04:16 GMT

Tobi, serviceOrder is a web service proxy class, the only way you get to interact with the CRM. CrmNumber is also something that is generated by the web service proxy. I am extending that with partial classes, so I have support of implicit operators, among many other things.

Tobi commented on Scaling ALT.Net Concepts

Sat, 13 Oct 2007 09:33:08 GMT

Slightly off topic, but how exactly, does this work? serviceOrder.wbs_serviceordermanningcount = (serviceOrder.wbs_serviceordermanningcount ?? 0); serviceOrder.wbs_serviceordermanningcount.Value += 1; This reads like: If the wbs_serviceordermanningcount property of serviceOrder is not null, assign it to itself, otherwerise assign 0. But shouldn't the "0" be "new CrmNumber()" and isn't the self assignment kinda superfluous (don't know yet if it gets optimized away in the IL). I would prefer the code above, probably slightly modified (assuming CrmNumber.Value defaults to 0): if (serviceOrder.wbs_serviceordermanningcount == null) { serviceOrder.wbs_serviceordermanningcount = new CrmNumber(); } serviceOrder.wbs_serviceordermanningcount.Value++; Looks like wbs_serviceorder should have an IncreaseServiceManningCount() method or at least initialize wbs_serviceordermanningcount with a default CrmNumber of value 0. But I must confess, that I have absolutely no idea, how this Microsoft CRM thing works at all :-)

Ayende Rahien commented on Scaling ALT.Net Concepts

Sat, 13 Oct 2007 08:01:20 GMT

> Having been in this situation in my last role, where as the architect my job was to convince the organisation to use better techniques for a *massive* enterprise project, I can assure you it is near impossible. Better ask for forgiveness than permission :-) That is a good way to go about it in many cases. (Yeah, I know about cowboy coders and cowboy architects, bear with me) Allow me to apologize in advance, I am going to use marketing speak here. You can say to the org: We are going to build a enterprise platform based on the best new stuff, IoC, MVC, OR/M, TLD, XYZ, ETC. I will really make us work faster, honest! Or you can say: Since this is a massive project, I intend to sit with the team leads and work out a viable architecture for the application, this architecture will ensure both that we get a maintainable product and, at the same time, we can finish our tasks faster. The main idea is to have the architecture directly support the business concerns that we need to handle and simplify as much as possible the work of the developers in the trenches. This means that we are going to have a complex foundation, because we are dealing with a complex application and a complex domain, that will be very simple work with, since it aggregate and hide all the complexity. I acknowledge in advance that not all developers are equals, so maintaining this core piece is going to require good people, but maintaining / developing the rest of the application can be done by any average joe programmer, after a few days of aquinting themselves with the code base. Of course, we can go with XYZ's suggestion of a graphical tool that would allow our developers to drag & drop boxes and arrows around. But if I wanted my developers to do that, I would rather buy them photoshop (it is even cheaper). We are all familiar with the success of such tools in the past, they demo very well, and they even work, for the simplest of scenarios. But they usually have severe problems in the areas of maintainability, handling complex tasks, deployment, control, etc.

Ayende Rahien commented on Scaling ALT.Net Concepts

Sat, 13 Oct 2007 08:01:08 GMT

> Oren, the "on the job training" as your third approach I mentioned as my second "train 90 developers to use better techniques (while paying them) " No, it is not. Again, talking about the type of developer that you portray and thinking of them in the body count term. I wouldn't try to train them on the job. I would set down the rules and standards for working on this project. Direct exposure to good practices leads to good practices. I think that the main difference is that I am not even going to try to train most of them up front. I will do an architecture overview and show them how we approach stuff, but that about it. What I call OJT is what they will learn while _perfomring tasks that translate to business value_. I am talking about putting them in an environment where the easiest thing to do is produce good code. My approach says, let them start working, right now, here are the samples, here are the tasks, now go and make merry. No wasted time. > consulting companies coming along and claiming they can outsource the whole thing at a much lower cost than your internal teams will cost, and they can guarantee you don;t need expert developers. If they could do it, and devliver actual value, great! That _would_ be in the client's best interests, no? But the arguments against it are well known, quality control, responsability and responsiveness among them. > That organisation will, in a few years, realise their whole IT strategy (which depended on the promises of 3 consultancies), doesn't exist. And then they will repeat the process, because they were in exactly that position already from the last consultancies that promised the same and still haven't delivered. That is the client's own fault, frankly. If they do stupid things, bad stuff happens.If they don't learn from their mistakes, they deserve to pay. Is client education something that I should be concerned about? Maybe, if I am trying to selll my services (and I am a _lousy_ sellsman), but I think that I have already re-iterated the arguments for this approach enough.

Casey commented on Scaling ALT.Net Concepts

Sat, 13 Oct 2007 07:30:31 GMT

Oren, the "on the job training" as your third approach I mentioned as my second "train 90 developers to use better techniques (while paying them) " The reality in an enterprise situation is, that just isn't an option. You have a massive historical legacy to fight, at all levels of managemnt, at all levels of finance, at all levels of the user base. They are all fighting against you,because humans by their very nature are cautious and wary of new things. Having been in this situation in my last role, where as the architect my job was to convince the organisation to use better techniques for a *massive* enterprise project, I can assure you it is near impossible. And when you do make some progress (by delivering a number of high quality prototype systems in record breaking time), you then have to deal with Microsoft, IBM, and third part yconsulting companies coming along and claiming they can outsource the whole thing at a much lower cost than your internal teams will cost, and they can guarantee you don;t need expert developers. In this case the organisation was promised massive savings, delivery in a very short (comparitivly) timescale, and an industry standard solution. It involved a lot of Mort developes dragging and dropping within an off the shelf workflow system (for the most part), linking services into WebSphere. WebSphere would be delivered as a black box product, with all services for all systems enterprise wide. The realty is, it will never work. The reality is also that it won't be seen to have failed for at least a year (despite delivery dates long before then). It also will be covered up by the management that bought it for at least a year beyond that to allow them to move to another organisation first. The 'enterprise' system is too complex to allow failure to be detected early (as it would be with Agile approaches), and by the time is is realised, it is too late to stop. That organisation will, in a few years, realise their whole IT strategy (which depended on the promises of 3 consultancies), doesn't exist. And then they will repeat the process, because they were in exactly that position already from the last consultancies that promised the same and still haven't delivered. I think it was put best in the film Armageddon... "You know we're sitting on four million pounds of fuel, one nuclear weapon and a thing that has 270,000 moving parts built by the lowest bidder. Makes you feel good, doesn't it? " That is the reality of most enterprise projects I have encountered.

Chad Myers commented on Scaling ALT.Net Concepts

Sat, 13 Oct 2007 00:58:55 GMT

There's a professional honesty question here as well. As professionals, they (customers, business folks, management, executives) trust and expect us to constantly practice our art and better ourselves. If we're just towing the line and not really doing anything to advance the state of the art, we're really doing a disservice to our customers. It's tantamount to stealing. We're just doing the easiest, laziest thing that gets it done and maintenance and future cost be damned! We have an obligation as professionals to try to do the best thing for the customer which means practicing the art and not settling for what gets the job done today. Bubble gum and duct tape will solve most problems for a few days, but they don't last. We need to build lasting, maintainable solutions. It may be hard, it may be complicated, it may involve some discomfort for junior or lightweight developers, but there should be professional shame involved if you're not actively participating in the community and striving for excellence and learning from your mistakes.