Ayende @ Rahien

Ayende Rahien commented on ALT.Net and the Enterprise

Sat, 27 Oct 2007 15:16:28 GMT

Frank, I couldn't disagree with you more. There is a significant difference between hiding the complexity (bad) and manging the complexity (good). What you present is a scenario that doesn't work for any application of real complexity.

Frank Hileman commented on ALT.Net and the Enterprise

Sat, 27 Oct 2007 14:27:22 GMT

As much as I would prefer to agree with Ayende, in my experience perhaps 5% of developers should be exposed to a continual stream of complex, new ideas. This comes from working with many people over many years and building toolkits for other developers. I won't comment on specific ideas, because it doesn't matter what the ideas are. Only the quantity of different concepts is significant. The future of software development probably goes like this: a small group of mathematical, sharp developers create general purpose tools for software development, tools that are extremely easy to use. A much larger pool of "developers" uses these tools in a simple graphical environment, to "develop" an application. These are not developers in the traditional sense. The application level "development" process becomes like the drag, drop, set properties approach currently seen for GUIs. Only you create an entire application this way. No knowledge about the underlying plumbing, design patterns, performance, etc is required. If this prediction is true, there won't be 100 person enterprise software teams. 100 person teams rarely accomplish much currently. They are too difficult to manage. One could argue this is a pessimistic view. It is not: optimistically, we will continually develop tools for working at higher and higher levels of abstraction, continually hiding details that distract us from domain-specific concerns, until finally all such details are hidden. Simplicity of development was the goal of obejct-oriented development from its inception: easier to teach (Logo's influence on Smalltalk), easier to write (small talk == less code), easier to ignore details (encapsulation and abstraction layers). The sharp people writing the tools still work with complex concepts, but it does not matter which techniques they use, as long as the end result hides those concepts.

Ayende Rahien commented on ALT.Net and the Enterprise

Sun, 14 Oct 2007 08:07:11 GMT

>> do you think they are going to stop and smell the coffee, or charge their clients (the business group or the actual client) 5 times the price and deliver it 2 weeks later, or just hack it together and move on to the next page? Sustainable development is the key here. You can do it for applications that are very small, yes, and maybe get away with it. But you can't get away with it in any reasonable size project, it collapse under its own weight, and I have seen projects that have been flat out banned from going live by the security department, or the network guys, precisely because of the reasons that you quote. That leads to a failed project, with all the implications that this entails. >> You may come across some poor in-house teams in your travels, but until you have worked within those teams you cannot begin to imagine how painful politics can be to doing your job to the standard that you consider professional, rather than the standard the management would like to see to get their invoices paid - the two are usually a very long way apart. I do a lot of work for clients, some of it is in their offices, so I am fully exposed to all the politics, back stabbing, we-always-did-it-that-way, etc that is going on. I am not unaware of this, I hold my position in spite of those hurdles.

Casey commented on ALT.Net and the Enterprise

Sun, 14 Oct 2007 07:14:04 GMT

>>I can't. And I don't kid about this, I have never done this (to be more correct, I have never gone beyond the demo level). << Oren if you couldn't do what I just said in under 10 mins regardless of not having done it before I would very surprised ... an 'average' developer in a large organisation (in my expereince) can do it in about 2-3 hours. >>And I think that you underestimate the amount of work most pages requires. Even trivial forms over data requires understanding complex stuff.<< Oh come on ... I do this stuff for a living too :) Of course I don't underestimate it, But people that write requirements do, and business analysts do, and managers do. So when they have all agreed that the page will take 2 days work, and you tell them that fundamentally their design is lacking authorisation, security, protection against injection, proper validation, cannot be scaled vertically or horizontally, and needs multiple firewalls opened due to direct datbase access ... do you think they are going to stop and smell the coffee, or charge their clients (the business group or the actual client) 5 times the price and deliver it 2 weeks later, or just hack it together and move on to the next page? I have actually seen organisations where (in one case actually explicitly expressed, and in many where it wasn't spoken out loud) software delivered roughly meeting the requirements on how the UI worked was considered delivered. The work to make it work (usually way more work than the initial delivery) was considered 'bug fixing' and therefore was billable additinally by the IT department or outsourcer. Again Oren, I strongly suspect that those working in *your* team are the elite of the development world (ie in the top 20% of developers), whether you choose to believe it or not . You may come across some poor in-house teams in your travels, but until you have worked within those teams you cannot begin to imagine how painful politics can be to doing your job to the standard that you consider professional, rather than the standard the management would like to see to get their invoices paid - the two are usually a very long way apart.

Ayende Rahien commented on ALT.Net and the Enterprise

Sat, 13 Oct 2007 20:44:13 GMT

> Anyone with .NET on their CV can drag and drop a page together and put a dataset in the code behind I can't. And I don't kid about this, I have never done this (to be more correct, I have never gone beyond the demo level). And I think that you underestimate the amount of work most pages requires. Even trivial forms over data requires understanding complex stuff. Just say I want a CRUD interface for the Employees table, but I need to validate name not empty, on the server side. You now need to handle a lot more stuff suddenly.

Simone Chiaretta commented on ALT.Net and the Enterprise

Sat, 13 Oct 2007 17:00:35 GMT

One last thought as disclaimer: my opinion on the topic might have been a bit biased also by the fact that I just left my job mainly due to the fact that my idea about development were too complex for the developers in the development team.

Casey commented on ALT.Net and the Enterprise

Sat, 13 Oct 2007 14:27:01 GMT

Should have added ... the cost to bring Oren over, in full with all expenses was less than £10,000 ... the project had a budget in excess of £10 million ... that's called short sighted :)

Casey commented on ALT.Net and the Enterprise

Sat, 13 Oct 2007 14:24:24 GMT

2 quick points ... actually I spoke to Oren's company about bringing him over to the UK for 1 week to 'evangelise' on MonoRail and good development in general, had full prices, quotation, full written arguments why we needed this insight to set us on the right path ... after a bit of umm and ahhh and my managers backing me, the senior management rejected the idea as there was no case for bringing in anyone when thier consultancies could hire people at half the cost in the UK and they promised to just make it all work. :) And to Steven R's point, sure they don't understand page lifecycle, but they can drag, drop, hook up a dataset without knowing the page lifecycle .. sure it's going to bitye them at some point, but at leastthey will have got some good months coding done before they get any problems! Anyone with .NET on their CV can drag and drop a page together and put a dataset in the code behind - hell with ObjectDataSource they don't even need the code behind, just put the SQL in the .aspx ...

Steven R commented on ALT.Net and the Enterprise

Sat, 13 Oct 2007 04:27:37 GMT

"Substitute WebForm and CodeBehind ... now they all know what you mean, time to crack on and write some web forms!!!!" If we are talking about the same developers then no they won't. Ask them to explain the page lifecycle to you or write an aspx page from scratch. They won't be able to do it. My point is that the original post is picking on Windsor and MonoRail because they are associated with ALT.NET and that to me is pure FUD. If the developers you and Simone talk about are able to pick up everything except for Windsor, MonoRail and NHibernate then yes those communities would have a problem. The problem isn't that these concepts are hard to understand the problem is that these developers aren't inspired to keep up with any technology period. You are going to have to educate them no matter what you use. It is agnostic.

Ayende Rahien commented on ALT.Net and the Enterprise

Fri, 12 Oct 2007 21:20:13 GMT

Don't underestimate the power of "that is what you are paying me for, no? :-D

Simone Busoli commented on ALT.Net and the Enterprise

Fri, 12 Oct 2007 19:55:28 GMT

Ayende, and you think they'll be willing to have your consulting if they have to pay you?! ;)

Ayende Rahien commented on ALT.Net and the Enterprise

Fri, 12 Oct 2007 19:16:36 GMT

Simone, I _am_ doing consulting :-) Send me an invite, I am willing to come and argue about software development with everyone.

Ayende Rahien commented on ALT.Net and the Enterprise

Fri, 12 Oct 2007 19:09:23 GMT

> why should I believe you over them? They told me that you "were using stuff that was way too complicated and would take them too long to learn" Okay, now you are talking about selling an approach to management. That is a different issue, but basically I would point out maintainability vs. cost concerns, talk about TCO, etc. I may even go as far as to produce a graph with wavy lines and colors and everything. In the end, if I have not won you over, I would request a few weeks for a test trial.

Luke Breuer commented on ALT.Net and the Enterprise

Fri, 12 Oct 2007 18:36:56 GMT

Casey, > why should I believe you over them? Compare the end results of both methods. Ayende claimed that the ALT.NET methods result in more maintainable software. I'll add that structured, rigorous testing leads to fewer defects throughout the product lifecycle. Now, tell me this: when you ask for new features, do your developers groan, take a long time to implement them, and/or when they are implemented, do you find more bugs than you would like?

Jeremy commented on ALT.Net and the Enterprise

Fri, 12 Oct 2007 18:36:08 GMT

It's an imperfect world Chris and that sounds like a defensible compromise to me.

Chris Wuestefeld commented on ALT.Net and the Enterprise

Fri, 12 Oct 2007 18:33:51 GMT

It's not all about the technical stuff. I mentioned earlier that I had wanted to set out on this project using MVP and IoC through Windsor. And I'm in a position where I probably could have forced the issue and mandated that. The thing is, at the same time that I'm seeking the best technical solution, I'm also seeking the best MANAGERIAL solution for the team I have available to me (or could reasonably assemble). With that significant restriction, following the "traditional" WebForms approach with a mandate for automated unit testing on the non-UI tiers and scripted tests of the UI were the best I could really get.

Simone Chiaretta commented on ALT.Net and the Enterprise

Fri, 12 Oct 2007 18:12:34 GMT

>I have no problem of having a discussion with IT managers about code quality. Oren, you should REALLY come and work in Italy, with the average sized software house or IT company.

Ayende Rahien commented on ALT.Net and the Enterprise

Fri, 12 Oct 2007 17:11:09 GMT

> because it IS NOT EASY, it takes A LOT (and I mean a lot) of effort to get a team to start using good patterns, Depending on the team and the way you introduce it to them. My team has seen about x10 (and that is something we measured, yes) improvement for using the more complex approach over the "simple" common one. Time to finish a task dropped from about a day for a single developer (and you can't have two developers working on it) to about an hour, and we can get parallel development going. The investment was about a week of my time, up front, for getting this to work. As I mentioned before, this isn't a start dev team. There are several ways to introduce good practices, considering the type of developers that people are tossing about (which I would generally toss out the window), I would go with the "because I told you so". I would rather use the "here are the reasons for why we are doing this", but the other one works as well.

Casey commented on ALT.Net and the Enterprise

Fri, 12 Oct 2007 16:54:17 GMT

>>But, if you are non technical, what do you care about impl strategies? << And as a non-technical person, that has hired 5 developers and you, all of whom had similar CVs, had done similar jobs in the past, and all of you tell me you know what you are doing ... now build me the system I want .. oh and if you tell me that the other developers aren;t doing things the best way... why should I believe you over them? They told me that you "were using stuff that was way too complicated and would take them too long to learn"

Ayende Rahien commented on ALT.Net and the Enterprise

Fri, 12 Oct 2007 16:50:42 GMT

Casey, > I doubt anyone smart enough to be reading this blog would argue against IoC or anything similar. In fact the exact opposite I would suggest. Yet I have had discussion about just those things here. > Prove to me (as a non-technical bean counter) that IoC, SRP, MVC, etc etc will save me money. Easier maintainability, responding to change. == more money. You want a chart, there are many studies showing that the true cost of a project is in maintenance. But, if you are non technical, what do you care about impl strategies?

Eber Irigoyen commented on ALT.Net and the Enterprise

Fri, 12 Oct 2007 16:34:59 GMT

"So, what is the difference between the two? Why can Java people scale those concepts to large teams and .NET people can't?" One of the big differences is in the tools, in the adoption, and the "standard" way of doing things that millions of developers follow, is that MS fault? it doesn't matter, the point is that millions of developers are used to that and is easy! "If you put web forms, they will use that. If you use MVC, they will use that." no they won't, why? because it IS NOT EASY, it takes A LOT (and I mean a lot) of effort to get a team to start using good patterns, then comes management (and this is a big problem), which won't like the fact that the team is working slower because you are forcing them to use something that they are not good at sure is easy for all of us having this discussion maybe, but that doesn't speak for the majority of the developers, at least in the .NET area, and I know that from experience, from talking/working with a bunch of .NET developers in different places "Substitute WebForm and CodeBehind ... now they all know what you mean, time to crack on and write some web forms!!!!" exactly!

Casey commented on ALT.Net and the Enterprise

Fri, 12 Oct 2007 15:49:38 GMT

>>>Substitute the words MonoRail and Windsor in the above sentence with WCF and WPF, 40 of them will still not know what you are talking about. << Substitute WebForm and CodeBehind ... now they all know what you mean, time to crack on and write some web forms!!!!

Casey commented on ALT.Net and the Enterprise

Fri, 12 Oct 2007 15:47:58 GMT

>>Maybe you can get this message across to the bean-counters, seeing as effort is directly proportional to money... << I doubt anyone smart enough to be reading this blog would argue against IoC or anything similar. In fact the exact opposite I would suggest. How would you get that message across? Prove to me (as a non-technical bean counter) that IoC, SRP, MVC, etc etc will save me money. Remember, I'm non-technical so as soon as you start mentioneing any of those things, you will lose my interest and the guy that just said "sure I can do that in ASP.NET, will take me a day to put together, its all drag and drop these days" will get the job. After all - he said something I understood. :)

Steven R commented on ALT.Net and the Enterprise

Fri, 12 Oct 2007 15:46:13 GMT

"if you have 50 developers in your team you can't use MonoRail or Windsor or even the kind of main-stream NHibernate, because 40 of them will not know what you talking about." Substitute the words MonoRail and Windsor in the above sentence with WCF and WPF, 40 of them will still not know what you are talking about.

Luke Breuer commented on ALT.Net and the Enterprise

Fri, 12 Oct 2007 15:40:26 GMT

Those arguing against IoC, MVC, etc., should read up on technical debt: http://martinfowler.com/bliki/TechnicalDebt.html . The easy way, even for non-genius programmers, isn't necessarily easy for long. Consider a graph of effort vs. time: while IoC & team might require a higher initial effort, the integral of effort over time will be lower for IoC than the haphazard methods the dev already knows. Maybe you can get this message across to the bean-counters, seeing as effort is directly proportional to money...

Luke Breuer commented on ALT.Net and the Enterprise

Fri, 12 Oct 2007 15:40:26 GMT

Chris Wuestefeld commented on ALT.Net and the Enterprise

Fri, 12 Oct 2007 15:10:38 GMT

I think that the difference in characterization between Mort and Einstein holds true, and few fall into the latter category. For most of the people -- the Morts -- they want to get the job done, and with the MS environment have a toolbox they know how to use. In the Java world (or Ruby, etc) there isn't a single encompassing suite, so developers NEED to pick and choose. So MS developers wind up having some inertia, having invested in learning the out-of-the-box designs. It's tough to sell to them the investment in learning other approaches, when they've got something that they can make work, even if it's inefficient, inelegant, brute-force. Part of it, too, is that the out-of-box stuff has significant support behind it, as well as some guarantee of a lifespan that will last at least the life of the project's deliverables. With MonoRail or Windsor or various OR/Ms, who knows (for example) whether it will be ported to the next .Net that we need to upgrade to in a couple of years? I've dealt with this many times, usually with only marginal success. I've lobbied hard, eg, for MVP and Windsor Container in order to facilitate automated unit testing. I got the automated unit testing, but only to the degree that WebForms lends itself to this approach. And the WebForms model, especially with data binding, doesn't lend itself very well.

Markus Zywitza commented on ALT.Net and the Enterprise

Fri, 12 Oct 2007 14:25:56 GMT

I have developed here with two other persons the last year. We are here in an administration department, so the developers I work with are not bleeding-edge-buzzword-followers, but rather the kind of guys, Microsoft targets with designers and code generators. I have some development background in a lot of environments, including Java and C++. My experience is that even inexperienced developers that had barely one week of training in OOP concepts and .NET-Programming are capable of using IoC, MVC and the whole bunch of Alt.NET-Stuff. I'm not saying that they understand what's going on internally; but they accept it as a kind of black magic helping them to create software as long as someone's there to take their hand if something goes horribly wrong. This attitude should scale to large teams as well. Don't take me wrong: I'm not going to say that they can't get it or that they are "morts" or something; I'm sure they will understand once they gathered experience with the frameworks used.

Tudor Turcu commented on ALT.Net and the Enterprise

Fri, 12 Oct 2007 14:13:04 GMT

This is mostly a question of project and company management: the desire to produce good-quality products and to use better practices and patterns must come from the upper management, and they must be willing to invest in this, at least at the beginning. If the management gathers from 'the streets' 50 developers, to quickly produce a cheap application, it is hard to apply better practices, even if 2 or 3 of them are willing to apply them. Without proper planning, organization, when there is pressure to produce quickly some forms to show to the customer, no mater the quality, when arbitrary deadlines are set from outside the development team, it is hard to raise the quality of the development process... Even if I am fortunate not to work in such a place, I know that there are many such programming shops around here..

Ayende Rahien commented on ALT.Net and the Enterprise

Fri, 12 Oct 2007 13:28:33 GMT

> you have to check them every minute in order to see if they are following it. If I have to do more than the usual code reviews, then they should go. Then you replace them. If they can't be good they should at least be disciplined. But frankly, at this point it is dealing with what ifs... I have no problem of having a discussion with IT managers about code quality. Usually with a simple sheet of cost per bug vs. bug amount vs. code quality.