Davy Brion has an interesting post discussing his recent interviews with .NET and Java developers. I have to say that I agree with some of his assessments. Much of what we discuss in .NET is far more common in Java as Java has a far healthier community than Microsoft. You will find terrible developers on both side but the terrible developers on the Java side have more mainstream exposure to good ideas than on the Microsoft side.
The majority of the .NET community is fake as well, led by the leash by Microsoft. I remember in particular a discussion with quite a few people in Atlanta just after Katrina when I was there for a while where I was being laughed at and talked down to (the same tired arguments about sprocs) for suggesting the use of an ORM, these are the same people who today will reiterate the same arguments and push themselves as “ORM experts”.
How to we break out of this? I had great hopes for alt.net doing this but sometimes you feel like the engineer of a freight train who can see that truck 1/2 a mile ahead and has hit the breaks but is not hoping. I believe alt.net has at the least given the small few who were doing such things already a community upon which they can draw support from when they realize just how bleak of an abyss the .NET development world is. Over time new people will continue to populate alt.net and it will grow but because of the dynamics of the general community we will either need a revolution against Microsoft or Microsoft will need to lead the charge.
The drag and drop developer
A sub-theme to the post is the putting down of “drag and drop” developers. It is obvious that Davy in his scenarios values highly things like understanding DI and the SOLID principles. I agree that these things are very important, in some contexts!
“Drag-n-drop of pure visual components is usually not a big deal… drag-n-drop of data sources on pages or forms or whatever is a different matter entirely “
The typical arrogant developer viewpoint … likely the same kind of developer who would build DTOs on top of a domain layer to support a simple forms over data web application. There are contexts where dragging and dropping datasources can be extremely effective.
When people are attempting to use DDD one of the first things I tell them is not to, there are simpler ways and most applications do not justify the expense and complexity of DDD. Can we make a similar argument for development as a whole? Think about the systems that sharepoint is replacing today… Are they being “well crafted”? probably not but they are providing near immediate value at extremely low entrance prices. To help us further identify such systems, they are generally low risk and highly volatile.
The big problem with drag and drop development is not inherent within it but when it is applied to situations that it is inappropriate for.
Microsoft has made this possible with the creation and promotion of the drag and drop developer. These developers lack education, they are easy to bring in, they can produce value almost immediately, and cost a fraction of what a true engineer would cost. There is a vast number of systems that these developers can be extremely productive on while carrying little risk to the business as a whole. They also free up engineers to work on more interesting systems.
If we want to be effective architects one of our main goals should be to isolate these types of scenarios and build bubbles around them so we can use the lower skilled work force (at lower cost) without forcing our entire system to look like this. Remember that cost and scalability of a team is a non-functional requirement that we should be optimizing as well.