in Search

Do you Twitter? Follow us @CodeBetter

Karl Seguin

.NET From Ottawa, Ontario

Judging a book by it's cover - or - Are Java Developers Bad Developers?

Building on Peter's entry about RADRace, I wanted to throw out my own experience with those "serious" guys (aka, Java Developers)

First, I want to preface this post with an honest statement. I'm asking a genuine question. I want to know if I was just dealing with a few bad apples, or if the hole barrel sticks of rot. I have no doubt whatsoever that you could easily round up a bunch of bad .NET programmers.

Over a period of time, I had the opportunity to work with an outside consulting agency that provided a number of ".NET experts" to our development effort. These .NET Experts had strong Java background but very little .NET experience (.NET was relatively new then). Truth be told, they did most of the work and by the time I was brought in, everything was already set in stone (and sinking very quickly) - so maybe I'm just armchair quarterbacking. I've labeled the project a failure many times and have heard that the existing management team is throwing it all out (this isn't where I'm currently working obviously).

Now, there's no doubt that it was a very challenging project, with very difficult clients, users and timelines. Nonetheless, I was appalled at the type of code I saw. We'll set aside the SQL injection vulnerabilities, the lack of viewstate optimization and the fact that all the html was generated dynamically in codebehind (new HtmlTable(), table.Add(new Cell()...).

The developers treated the Database like a dumb filling cabinet - never coming close to taking advantage of what it had to offer (and I'm not just talking about indexes, udfs and stored procedures, but if you're curious, they didn't exist either). Much of the data was stored in a meta-like repository (at an extreme, think of having a single table with two columns "name" and "value"). Calculations were never cached (either in memory or in the database), but always done on the fly, in the business layer. Want to display the top level total of the 10 root items? Load thousands of child items into memory and add them up. Instead of caching the sum, those thousands of items were stored in the session (yes, we got a lot of OutOfMemoryExceptions), and if you wanted to recalculate you'd wait another 2 minutes. What took minutes and 20+ megs of memory (per user), could have been achieved in microseconds with a more explicit data model and the powerful SQL SUM function.

Most ASP.NET applications have far too thick a presentation layer in my opinion. For the first time in my life, I was seeing too heavy a business layer - and it wasn't any better. Sure, storing a cached value in the database is a pain in the ass, because you need to worry about keeping it up to date. But when the system is getting rebooted every 15 minutes 'cuz you've taken up all the memory, you're arguments don't have much of a leg to stand on, right? In essence, the best way to describe it was as programming purism. I'm sure the application would have made a great school paper, but when reality can't handle more than 5 users, you're in trouble.

Is this typical Java development? Is .NET development too presentation-layer focused, Oracle development too data-layer focused and Java development too business-layer focused?

On a side note, the architecture was based on analysis patterns (not to be mixed with design patterns). Pinging architects inside and outside Microsoft, I learnt that analysis patterns aren't overwhelmingly used. Further research indicated that those specific patterns (accountability and observation) are very implicit and come with a lot of drawbacks (they have advantages as well, don't get me wrong!). It's just that you really have to do some deep analysis to figure out if it's right (of course, that wasn't done). If anyone has any experience with this, I'd love to hear it, even though I've thankfully moved on.

Published Mar 27 2006, 04:23 PM by karl

Filed under: Grab a coffee before reading

Comments

Eric Wise said:

I may have to vote for the rot of the barrell. I have experience with a company I also will not name where I inherited an application that was built under the same circumstances: java and foxpro (!) developers who were taking their first stab at a C# web application.

To make a long story short, the database was the same as you experienced, no relations, keys, indexes, etc. They also took the initiative to rewrite pretty much the entire codebehind flow, overriding the page events repeatedly in a huge chain of hierarchical inheritance.

Same thing in the business layer. You would literally jump through > 10 classes and base classes to get through the simplest data retrieval function. Caching and session were also misused to the point where the system would literally crash or boot users out after 5-10 minutes of use in a seemly random manner.

This company, with their "experienced" consultants charged well over $100 / hr and now the poor company has sunk hundreds of thousands of dollars into a system that is not only bad, but is nearly unmaintainable since the code is so twisted and poorly designed.

# March 27, 2006 5:00 PM

Eric Wise said:

I come across situations like this&nbsp;all the time.&nbsp; Literally 70% of the project work I've done...

# March 27, 2006 5:07 PM

Ronald Woan said:

.Net and Java patterns for database backed web applications have been fundamentally different with differing requirements and expectations. For example, Java developers in/out of J2EE space have often valued database vendor flexibility and even data schema deployment mapping.

Java folks tend to have a stronger framework and particularly MVC orientation which for similar minded folks can lead to more maintainable systems. It is very disconcerting to move to .Net where there is much less of this established framework.

Also business logic is typically modeled and implemented in the middle tier as opposed to being pushed to the database engine, just as you saw.

Performance is an interesting question in an agile world where you optimize your bottlenecks after you get it to work. In green field development where I am with a number of experienced developers on other platforms moving to MS, we tend to start with a more generalized/framework schema model than our MS colleagues who are more application specific in approach.

I think you can end up with a lot of suboptimal stuff either approach you take, it depends on the experience and quaality of the people.

From my point of view software engineering best practices have been largely driven out of the Java community (with many ex-OO folks) with refactoring, test driven development, agile methodologies, etc...

# March 27, 2006 7:35 PM

karl said:

Nice insight Ronald...I agree with much of what you said. Of course it's easy for me to say "my way is better", when it truth it's likely more familiar. Your comments do highlight something I've realized - platform and technology play a huge part in architecture, which is unfortunetly to some degree.

Eric, rebuilding stuff that already exists, like codebehind flow is something I had to deal with too. Maybe it's the same people ;)

# March 27, 2006 7:57 PM

Eric Wise said:

Ronald,

I would like to point out that ASP .NET in and of itself is an MVC style framework. It just takes most of the hard work out.

# March 27, 2006 8:03 PM

Eric Wise said:

Karl,

I believe the code smell you're referring to is "rebuilding the square wheel".

# March 27, 2006 8:24 PM

Jeremy D. Miller said:

I'd have to mildly disagree with you Eric. ASP.Net is not inherently an MVC style framework out of the box. The code-behind model is too entertwined with the View code and does not do enough to create a separation of concerns between view and controller logic. You can do MVC development with ASP.Net, but you've got to do it yourself. The Java world might not be any better, but at least they have multiple established MVC frameworks to choose from (Struts, Spring, etc.). All we've got is the code behind and some second class ports.

# March 27, 2006 8:26 PM

Jens Winter said:

Karl, Eric,

Interesting post and comments. But what I'd really like to know is if you tried do solve the problems. If you tried have you been successful and how did you do it?

# March 28, 2006 1:11 AM

pvanooijen said:

I'm afraid you can find rotten projects built with every technology you can imagine. And you can find good projects built with anything. FI, nobody over here does take php that serious. But I know very good sites, constantly changing, completely built in php. It can be done and done good.

When it comes to flying they say "It's the man, not the machine", when it comes to software I would say "It's the team, not the tool". But the tool does shape the team by "forcing" it into coding and archtecting habits. What happens when a set of Java habits is let loose on .net might be frightening. The same might be applicable for asp.net 1 to .net 2. New archtecture, old habits, a lot of people (including myself) do have trouble with the shift.

So far I've always had great respect for Java, as it is widely considered that "other" important platform and is the source of so many tools and practices coming to .net. Taking a look from a closer distance I'm not always seeing what I had expected...

# March 28, 2006 2:31 AM

etk said:

I use both Java and .NET ad I've had to interview both C# and Java developers. Without exception, the Java developers were better than the C# developers, often significantly better. Java developers could complete a coding test in 20 minutes and C# developers were unable to even understand the problem well enough to start without a lot of hand-holding. We eventually hired Java developers for C# work because interviewing .NET developers was a waste of time.

However, most Java developers are not particularly good in the grand scheme of things. If you want to hire good programmers don't look for short-term skills like Java or C# knowledge. Any competent programmer can pick that up in a day or two. Use behavioural interview techniques. Look for programmers with experience of a wide range of different languages and technologies. And program with them on a non-trivial task as part of the interview process.

I think your analysis is correct. .NET overly concentrates on the UI and database and doesn't help you create a good domain model -- it's tools actively hinder writing good, testable dmoain abstractions. Java frameworks (EJB or Hibernate for example) act as if the database layer can be magically generated from Java objects. Experienced Java developers, however, tune the ORM mapping and database access to ensure good performance.

The difficulty your Java guys had with ASP WebForms sounds like a culture clash. Coming from the world of Java web frameworks, ASP is very primitive and makes an application very hard to test. They should have ignored WebForms as experienced .NET web developers do and used IHTTPHandler to create a clean architecture with good model/view separation and good testability.

# March 28, 2006 6:35 AM

karl said:

Jens:
My success in correcting the problem was minimal and only after a long time. I was one of the driving forces behind the push to scrap the systems - which is bittersweet success. There were certainly technical improvements done during that periode, but I'd say the main success I got was from learning. As I said, the challenges were also cultural.

# March 28, 2006 7:36 AM

Eric Wise said:

"They should have ignored WebForms as experienced .NET web developers do and used IHTTPHandler to create a clean architecture with good model/view separation and good testability"

I'm unconvinced as to why, when ASP .NET has such great UI capabilities out of the box that I would sit down and write my own implementation just for testing the UI. What you might gain in testing you're going to lose big time in clarity and the % of the developer population out there that will be able to effectively work in your framework.

In addition, nearly EVERY project I've come across where developers thought they could do it better their way ended up with the code smell of re-inventing the square wheel. I tend to fall into the crowd that if you look at a robust package like ASP .NET and say "I can do it better my way" you're bordering on an arrogance level that should be a big warning flag and from a pure business/cost perspective you should rethink what you're doing.

# March 28, 2006 2:45 PM

Ronald Woan said:

I may be missing something having only been on the platform for two years, but I have yet to see clean MVC based ASP.Net website in the same way that Spring/Struts/etc... are more commonly applied in the Java World. Codebehind blends everything into effectively one layer (at least there is no longer a single front controller and controller and model is blended, but in most cases codebehind is also used in direct UI generation/manipulation.

Don't get me wrong, I am not saying ASP.Net is bad in the same way that PHP, etc... are all nice for certain types of projects. It is a different architectural pattern and best use of its framework looks a lot different than others.

To a certain degree there are things that carry across all of these infrastructure, but a lot of things are different in the MS world.

Preventing SQL injection through stored procedures is an interesting panacea that some MS programmers that have come through our shop have expoused to the point of not validating input parameters or using strong typing at userinput/method levels per more traditional secure coding convention.

# March 28, 2006 4:47 PM

Eric Wise said:

Note that I did comment that ASP .NET is an "mvc style" framework. Not a pure implementation by any means, but it attempts to make code separation concepts more intuitive, the clean separation being the goal of MVC. They just didn't take it all the way.

My opinion though *shrug*

# March 28, 2006 5:14 PM

Jeremy D. Miller said:

Eric - I love the "reinvent the square wheel" comment

The problem is that ASP.Net doesn't attempt the separation of concerns at all. The code behind model by itself is better than ASP Classic for sure (like that was really hard), but it's still *View* code. For better or for worse MS is putting most of their eggs into the RAD/Design Time control bucket. If you build a system primarily by dragging and dropping data aware controls in a visual designer and code from the top down in event handlers you're unlikely to achieve a clean, maintainable separation. The architecture naturally leads teams to a very thick user interface layer based on an Active View approach.

You can most certainly design a good architecture in ASP.Net that is maintainable and testable, but it doesn't lead you in that direction like Ruby on Rails does.

Of course I'm plenty glad we missed out on all the J2EE/EJB over-architecture stuff here in .Net land, but the MS world's abuse of stored procedures might be worse.

I've always thought that going around the ASP.Net pipeline with a custom IHttpHandler architecture to be a bit nuts though. If you really dislike the ASP.Net pipeline that much, just switch to Java or Ruby on Rails or something else.

# March 29, 2006 12:04 AM

Etk said:

ASP.NET makes it hard to test the application's main logic, it forces you to put code into the aspx templates, it makes it too hard to instantiate the "code behind" outside the web app, and the UIs you end up with are clunky. ASP.NET is great for developers who just want to slap a few controls on a form and not care about building a maintainable architecture. If you want clear separation of concerns, easy testability and simple ongoing maintenance you have to fight the tools all the way. The tools should be helping, but instead they hinder. It's much easier to use NVelocity to generate HTML from a clean domain model and presentation objects.

# March 29, 2006 11:57 AM

Paul said:

Not a fan or C# or Java for that matter. C# was created to answer the java platform. The author of C# is the guy responsible for turbo pascal. The person who is saying Asp.net is mvc like.. is dead wrong. Try Ruby On Rails, or do some MacOS X Cocoa programming before speaking on that topic again. Now thats MVC.

In reality, I get paid to get a job done, if the code has to look ugly and unmaintainable, so be it. Simply put, companies pay for a solution. Instead, it sounds like to me, the developers are not focusing on getting the client a working solution, instead getting "all the cool" technologies inside the client application.

The best thing in coding is find the shortest quickest way, that has less code involved. Less code, means better stability. More code means more maintance problems.

Paul

# March 31, 2006 9:32 AM

karl said:

"In reality, I get paid to get a job done, if the code has to look ugly and unmaintainable, so be it."

I have to disagree with this completly. First of all, in the long run, this "solution" is going to cost clients a lot more than having it done right in the first place. If your clients don't understand this, you need to educate them, or find new clients. Any solution needs to take into account the total cost of ownership, not just the initial development cost.

If you can't find out how to do something cleanly, cheaply and timely, you either underbid the competition (even if you aren't a contractor, it's an apt analogy), you don't have the necessary skills, or you are using the wrong tools.

Of course, in some projects quick and crappy will be fine and the project will never really grow in scope, so you'll never see crap getting through the cracks. In my experience it's hard to tell ahead of time if a project is going to be like that, so you're much better off doing it right in the first place.

# March 31, 2006 11:44 AM

Eric Wise said:

I really don't understand what people are doing that they are so freaked about the "testability of the UI". Your UI/codebehind should not be performing business logic. Period.

For convenience, use some regex/required field validators but everything that goes to the database or comes out should come directly from your middle tier. You should not be putting sql statements in the codebehind, or anything else like that. The UI is just a dummy retrieve / store layer.

While the UI isn't easily testable in ASP .NET, if all the complexity and validation is in the middle tier which IS testable, the loss of testing the UI isn't all that much of an impact. And ASP .NET provides you with a framework which is damn fast at putting things together. That's what it does! If you want some pure MVC 100% easily testable framework you should take jeremy's suggestion and stay out of .NET. You're going to pay for it in productivity though and I have high skepticism that your code is going to be that much more reliable.

# March 31, 2006 2:25 PM

Old and tired said:

Paul: a developers job is not to provide the business with a short term solution, but to provide a viable ongoing business platform. If you slap together an unmaintainable application for your client that cannot easily be changed you have basically killed that client's ability to react to the changing business environment or saddled that client with the cost of an unnecessary rewrite when their requirements change... and they always do change.

Now I know the MS culture is to knock up any old crap as quick as possible and run off to the next contract before the shit hits the fan, but that attitude is exactly what's fuelling the rise of open-source and making major enterprise institutions turn people away at the interview if they put a microsoft certification on their CV.

# March 31, 2006 3:18 PM

ewise... said:

ewise... the middle tier is domain abstraction. The presentation layer is both the "look-and-feel" layer of the UI and the "dialogue" between the user and the domain model. In pattern lingo, you have a model (domain model), view (rendering and translating UI events to domain actions) and presenter (the dialogue between user and domain model). The presenter still needs to be tested because it often contains complex logic synchronising the UI events to the domain model. ASP.NET makes it bloody hard to test that.

# March 31, 2006 3:22 PM

Name (required)

Your URL (optional)

Comments (required)

Remember Me?

Enter the numbers above:

Add

Karl Seguin

Judging a book by it's cover - or - Are Java Developers Bad Developers?

Comments

Eric Wise said:

Eric Wise said:

Ronald Woan said:

karl said:

Eric Wise said:

Eric Wise said:

Jeremy D. Miller said:

Jens Winter said:

pvanooijen said:

etk said:

karl said:

Eric Wise said:

Ronald Woan said:

Eric Wise said:

Jeremy D. Miller said:

Etk said:

Paul said:

karl said:

Eric Wise said:

Old and tired said:

ewise... said:

Leave a Comment

Our Sponsors

Free Tech Publications

This Blog

Syndication

Recent Posts

Tags

Blogs I Read

Archives