+972 52-548-6969
ALT.Net and the Enterprise
Simone Chiaretta has a post that I strongly disagree with. The two parts that sum the parts that I most vehemently disagree with Simone are:
imagine you have an Enterprise-level project, with 100 developers, how many of them are likely to grasp what IoC is?
And:
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.
There are two reasons that I disagree, let us start with the one that had forced me to sleep on this post rather than send it immediately. The underlying assumption here is that "Morts can't take this stuff". It annoys me a great degree, because this is both arrogant and baseless. Those "alternative" concepts that we are talking about are not born of thin air, they are the de-facto standard of operation in many shops.
Let us focus for a second on the Java camp, shall we?
I would be greatly insulted if anyone tried to claim that Java developers are intrinsically better than .NET developers. But for some reason, those concepts - IoC, MVC, OR/M - that Morts can't ever figure out, are not only popular there, they are they default choice in many cases. And they are the choice for large, Enterprise projects.
So, what is the difference between the two? Why can Java people scale those concepts to large teams and .NET people can't?
The answer is that there is not real reason except a common misconception about the capabilities of developers to learn & grow. By assuming the "they can never understand that" attitude, you are limiting what you can do and form an elitist view of your developers.
I am pretty sure that this isn't what Simone intended, but this is how I view the general sentiments in that direction.
Now, I mentioned that I have two reasons to disagree. The second part is my own experiences working with those tools & concepts. All my projects for the last 2.5 years or so have been using IoC and OR/M, the last two are using MVC as well. I don't work alone, and I work with people of varying degrees of knowledge and interest in the technology for the sake of technology.
The reason for doing that is simple, it works, and it helps produce successful projects. I have an answer to "How does it make my job easier?" and I have successful projects to back this up.
You can see what kind of code we are writing right now, IoC, OR/M and MVC are easier than the other way around. And it is my responsibility to make sure that (a) the developers understand what is going on but (b) they shouldn't have to deal with it on a day to day basis. Properly used, IoC is completely transparent to the application. OR/M is not transparent, but it is very easy to use, and I want to split the code between the controller & the view.
So yes, you can scale this up to hundreds of developers. In fact, I can't really imagine other ways to manage this complexity without using those concepts.
Comments
Oren, my thoughts are based on the base of developers I worked with. Maybe I was very unlucky, or maybe you were very lucky, but all of them are not "into" technologies, they just want to have their work done with the least possible effort.
This, added to the usual attitude of "this <thing> must be done by yesterday" has a result these developers, both because they are not interested, and because they have to hack up something very quickly, develop the <thing> with the knowledge they currently have.
I wanted to make a comparison with Java in my post, but I forgot to add it:
Java is OO since mid 90s, MS is OO (if we exclude C++) since 2001, so almost double the time (10 years instead of 5 years).
Java coder usually come from a C++ background, .NET coders comes from a VB6 background.
MVC is the default way of doing things in Java because Struts, the defacto standard web framework, enforces it, the default framework for ASP.NET is WebForms, which doesn't enforce anything
And all the other tools like Spring, Hibernate are here since longer time then their .NET counterparts.
And last but not least, at the universities, at least in Italy, they teach Java, not MS. So most of the devs coming from the universities are into Java, not .NET, and as result, there is an higher percentage of graduates in Java than in .NET.
Again, this vision is about what I saw in my experience, studying in Italy, and working in Italy and in a small, marketing-driven company in Wellington (NZ). Maybe the figures are different in the USA or in Israel.
Hope I clarified my thoughts with this.
again... I'm not saying that they will never understand it... I'm just saying they they don't want to understand it.
Oren, I think your experience is very different from ours. Actually I haven't had a lot of professional experience so far, but for what I've seen there are very few people working in the field that are aware of all the development and design practices you use to talk about almost everyday. I'm Italian as Simone, same name actually, and I've been in the academic field for quite some years now. I never heard talking about something more "revolutionary" than object orientation.
The problem is not that IoC and similar concepts don;t scale to large teams, the reality is that 90% of those developers are unable to understand simple concepts like inheritance ... they are usually there for the body count, and a very limited number of those developers actually write real code.
Development is a creative profession, and you can't teach creativity, hence you can't just scale it by recruiting more developers. There aren't that many of them around, and you can't just put more people into training courses or university.
IoC in particular requires a creative mindset to understand, it is something you have to be able to construct in your mind, and to be able to see the chain of events.
I have done a number of teaching courses for developers, where I have introduced concepts like IoC ... almost without exception, only a few could actually understand it beyond copy/pasting the examples.
They will use whatever they need to.
If you put web forms, they will use that. If you use MVC, they will use that.
They may not be interested in those choices, but they are more than capable of using whatever they need.
Simone Busoli,
I don't think that I have different professional experience, just different perspective.
You don't need to understand all the reasoning for choosing something in order to use it. If a company decide to use WebForms, that is what will be used, and if they decide to use MVC, they will use that.
The missing piece is not whatever they will choose to use, but whatever they will be able to use if that decision is made.
I have seen that they are (a) able to use and (b) capable of doing stuff with it that make my head hurt*.
As for making this decisions, if I need to make them, I hope that I am making informed decisions, so that takes care of that. The rest is just hesitation because of prejudice.
If you think that MVC / IoC / ORM are the way to build maintainable software, and if maintainable software is your goal, you should go for it.
If you are holding back because "my devs will never grok that", I think that you are doing them a disservice.
Casey,
Grokking IoC & using IoC are two different things.
My personal goal is to get my production code to the fizz buzz level. So I could take a dev, give them a checklist of stuff they need to do, and have them go.
Some of my devs do just that, they aren't interested in doing more. They are producing value and creating maintainable code.
Some of my devs are interested in how things work, so we take them into the guts of it, point them to webcasts, explain how things work.
And by checklist I mean:
Create a class in this project, using the following naming convention.
Inherit from this class
Implement this method.
You now have the following services available to you to do your work.
Specify calling conventions using attributes.
move on to next task.
So far, less than 5% of the issues that we have run into are because of those abstractions, most of them are the usual (my users are in the wrong time zones or I passed the wrong param to the method, etc).
I agree with Oren that .NET developers can just as easily use IoC, MVC, OR/M, all they need is someone to give a nod in the right direction and experience the benefits themselves.
I have done several .NET projects (2-10 developers) in the last year where I (among a few others) introduced the concepts of IoC and OR/M (in the form of Spring and NHibernate).
These projects mostly had Junior developers (interns / 2 years of work experience) with one or two medior / senior developers and they had no problem picking up these concepts.
The only thing that was needed, was someone who took the first step in applying them.
At the moment there are hardly any new .NET (or Java) projects that don't use these concepts (only MVC isn't dully adopted fully within the .NET projects).
PS I also learned Java at school, switched to .NET (C#) at my current company and quite easily adjusted back to java.
Ayende, funny though it may sound, I suspect that you work with pretty much the elite of the development world on a daily basis. I have interviewed, over the past 2 years, at least 200 contracters earning in excess of £400 UKP per day (they all had full CVs), that do not understand what an interface is, what 'abstract' on a class means, or what the difference is between composition and inheritance.
You are very lucky to have talented people in your team, many 'enterprise' teams have to take whatever body count they can get to satisfy the management. And in that case you have to keep things really simple (and by definition produce poor quality code).
Casey,
Now you put me in a bad position, if I say that I am not working with good people, I am insulting my coworkers...
Nevertheless, my current team is not from the developer division in our company, it is from the business solution division, and as such, it is compromised of people who have so far mostly dealt with minor development to existing platforms, customizations and deployments. Maybe you need a couple of line of JS, or a quicker way to do something, so you throw a grid on a form and bind to a dataset with a few manipulation, or maybe you need to move users from one auth store to another, so you do that, etc.
I am there because we are doing a lot more development in this project than ever was done in this types of projects, and we need to have good maintainability and sustainability over this thing as we go along.
So no, my team is not compromise of the elite of the dev world, I am afraid.
I would like working in a team that is part of the elite of the dev world, for sure, but that is not the situation right now. In fact, one of the first things that I had to do when I got there was to make sure tshat they understood that development shouldn't hurt.
I share your opinion about the state of the industry, and there are people that would never want to do something anything more than they have to. But you don't have to lower your level to them, instead, they can be thought to follow blindly in the right direction. I don't like it, but this is one such approach.
As a way to free myself from the misconceptions about how "normal" devs, I am teaching an MCPD course right now, and have been for the last six or eight months.
I feel that I am talking from at least some experience with the type, therefor, when I tell you that it is not only possible, but much easier than it sounds when you think about it.
The part about simple == poor quality is going to be a post.
OK, let me explain a bit how thing works in Italy: this can be hard to accept as matter of fact, but citing a great HM band, "It's sad but true".
In Italy everything ICT is a commodity, companies don't invest in their IT staff nor stuff. An application is something that is needed because it's the way the world is going, but for them it's similar to a chair or an heater: you need a chair because you have to sit somewhere, and an heater because it's cold.
That turns into a request for cheap software, which turns again in cheap salaries for IT workers. So, if you exclude some big consulting companies, most of the people earn less than 100€ per day gross, which is around 1300€ per month net. So, workers tend to do the less possible because they already think they are doing a favor to the company accepting such a low salary (low compared to the cost of living in Milano, where you pay 6-700€ per month for an average 2 room rent).
We could fire this guys, and aim for more responsible guys, but if a company is will to pay most 1300€ per month, that will be an tough search.
This is about politics, economy and a lot of other things that I'm not into, but not about technology.
So, now that you understood why other Simone said "I think your experience is very different from ours", you can understand what is my experience. (and that's the reason why I REALLY want to go out of this country, Italy)
I don't think I'd want to work on an Enterprise project with 99 other developers if they weren't using IoC or MVC approach.
Sound about right for a low level position, yes. Although I think that the rent is hugely expensive (you can rent a house with that here).
But we have to deal with the same constraints, and companies gets what the pay for. If you are aiming for "dirt cheap developers" - a phrase once used at me as the target audience for the developers who are going to maintain my applications, you are going to get what you pay for.
If you are working with those types of developers, then they are usually new or not very good (and probably going to stay not very good).
For these type of people, give them a checklist of what must be done, and ensure that they produce maintainable code by making it harder to do otherwise.
Yes, giving them a checklist is good, but then you have to check them every minute in order to see if they are following it.
And also, these "dirt cheap developers" (btw, I should note down this term for future usage :)) usually are backed by IT managers, which know nothing about ... anything, so it's very difficult to make them understand the benefit of doing something that is "unusual" and that might take more time since the people that will maintain the sw will have to learn something new (of course during the working hours since they have no interest in studying overnight).
But, again, this is not a technology issue :)
In case I expressed myself badly ... by simple in that context, I mean simple as in "mostly drag and drop", no IoC, no inheritance, no composition, lots of "standard things" like EAAB, and most code inthe aspx.cs files ... because that is as far as most developers understand code.
"simple code" in the context I suspect you mean it is probably as I would define it... which is the hardest code in the world to write. The simpler the code is, the harder it is to write.
The art of writing code is somewhat like that of writing clear communication in English (or any other language) ... the skill is in removing absolutely everything that isn't essential to the message.
IoC, AOP, MVC all allows, among other benefits, to decrease coupling between components. This means that maintainability, by developers who knows what those technologies/methodologies, will be very easy.
Maintenability is money.
So, no, you don't need to have 100 developers understanding & using those concepts on a daily basis. You need a few ones only in order to create a good base (call it framework, base library, or whatever) that will allow other developers (whatever the reasons why they don't know/want to know about those concepts) to work in a more declarative/procedural way, following a check-list for the technical part (if needed), and to stay focused on the functional logic of the application.
It's all about 'layering' and abstractions : When you buy a car, the seller doesn't request you to know exactly how the engine is working.
You basically only need to know the driving rules and how to 'use' a car.
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.
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..
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.
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.
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...
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...
"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.
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.
:)
Substitute WebForm and CodeBehind ... now they all know what you mean, time to crack on and write some web forms!!!!
"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,
Yet I have had discussion about just those things here.
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?
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"
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.
Oren, you should REALLY come and work in Italy, with the average sized software house or IT company.
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.
It's an imperfect world Chris and that sounds like a defensible compromise to me.
Casey,
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?
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.
Simone,
I am doing consulting :-)
Send me an invite, I am willing to come and argue about software development with everyone.
Ayende, and you think they'll be willing to have your consulting if they have to pay you?! ;)
Don't underestimate the power of "that is what you are paying me for, no? :-D
"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.
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 ...
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 :)
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.
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.
<<
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.
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.
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.
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.
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.
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.
Comment preview