Jeff and .NET

The .NET musings of Jeff Putz

Sponsors

News

My Sites

Archives

Is most software development really as bad as I think?

Following my lay-off over the summer from Insurance.com, I've been around quite a bit doing contract work and other sub-optimal things. Now I'm finally in what I hope is a solid job with an online marketing agency that also does app dev. As the company's technical architect, I'm not writing as much code myself as I have previously, but I do get to see a lot of stuff inherited from other places.

The common theme is that most of what I see is universally bad. I mean, throw it out if possible and start over bad. Copy-and-paste from countless blog entries bad. Uses DataTables and Session bad. Written in VB.NET bad. (OK, sorry, that was uncalled for. ;))

I'm trying to figure out the reason for this. I know part of it is the scarcity issue, that there just aren't enough good people to go around. But one would assume that every organization has some senior people in charge of maintaining some level of non-suck. Yet a lot of suck gets out into the wild.

I feel fortunate that I work with developers who are eager to learn and surprisingly open to culture change. They want to be ninjas. I now realize just how high-end the development was at ICOM, and I feel very fotunate to have had that experience, and have others now benefit from it. I like the idea that you can ease your own legacy, and others down the road will thank you for it as well.

Of course, that sounds ironic coming from a guy who often says he can do without the computer science lessons, but come on, the basic design patterns make your life infinitely better and they're not that hard to learn!

What kinds of nonsense have you seen?

Comments

Ventsislav said:

You have to see some of the projects that I have participated. In the last project there is a C# class with over than 32 000 lines of code :). Only absolute positioning in the ASP.NET and a lot of bad stuff.

# January 14, 2009 4:26 AM

adweigert said:

This is a common theme in I.T. departments in companies whose primary source of profit is not selling [via] technology.

You should feel fortunate that you have developers that want to be ninjas and not people that have been their for 10-20 years and just want to run support for the stuff they already have and not worry about learning new programming languages and/or techniques. Because, you know, the csv file and unix shell script are all a programmer really needs.

# January 14, 2009 7:24 AM

Scott said:

CSV files and Unix?  Sounds like you work in a more advanced company than myself!  I am a .NET and BI developer supporting COBOL/Mainframe/Fixed width files that we pass around all day and when those don't add up or are missing we get called at 2am to fix it as it would mean certain doom for our company...or would it?

I have been spoiled in the past with a software company who is a world leader in the market which had actually made me a little sheltered.  My development skills increased exponentially but I didn't get any experience with other parts of the SDLC.  That is the ONE thing I can say that is nice about where I am now, I think it's important to have the people writing the software in on the requirements gathering and design.

# January 14, 2009 8:03 AM

kamii47 said:

It is the exact feeling any good developer [who beliefs in best] will have if he found out Bad techniques.

It is always exciting to learn new things.

# January 14, 2009 8:46 AM

rrobbins said:

What is with the design pattern craze? I see WROX has a new book "Professional ASP.NET Design Patterns".

# January 14, 2009 8:55 AM

Jeff said:

I don't think design patterns are a craze, but there are a lot of generally accepted solutions to problems that are generally familiar. If code is your legacy (and often your own legacy), wouldn't you want to people to understand it in a familiar way?

# January 14, 2009 9:13 AM

AndrewSeven said:

I worked very briefly on a VB.Net project where the had decided that on file per namespace was sufficient and that one file per class was foolish.

# January 14, 2009 9:48 AM

steve said:

whats wrong with datatables and sessions

# January 14, 2009 11:37 AM

Jeff said:

Using session for anything is relying on an information store that could disappear at any moment if the process recycles for any reason. DataTables just generally suck, and are fairly useless in a world with generic lists.

# January 14, 2009 12:32 PM

sodablue said:

Have you ever looked the examples within MSDN on how to do things?

Where do you think most people go to figure things out?

# January 14, 2009 2:36 PM

Jeff said:

Actually, no, not really. The MSDN docs in the v1.x days were beyond useless. They've gotten better, but most of the better stuff is associated with classes added in v2 or later.

# January 14, 2009 2:44 PM

steve said:

what is the better method to store user input when moving from page to page?

# January 14, 2009 2:47 PM

Jeff said:

Databases are good for starters!

# January 14, 2009 2:50 PM

blockhead said:

i think using session/session vars is not necessarily or universally a bad thing.  it just depends how judicious you are in using and how you use it/them.  i try to avoid them in anything that holds 'real' hard info.  but for some attributes of web apps i will use (sorting being the first example that comes to mind)

# January 14, 2009 2:59 PM

steve said:

so you write all these values to a database and then the user closes their browser before finishing all the required steps. now how do you cleanse this nebulous data?

# January 14, 2009 3:03 PM

justinsaraceno said:

sodablue was right about MSDN docs.  Better yet, you ever go to an MSDN event?  If you had, the concept of a datatable would be advanced because all you see is them drag a SQLDataSource control on to the page for an automagical demo.

# January 14, 2009 3:06 PM

steve said:

I guess it's not that hard to build container objects.  I've just gotten in the habit of not committing data into the database until all required fields have been populated and validated. I've been using objects with properties and what not that also contain LINQ objects stored in a session and then just committ them when the time comes.

Is this bad form?  Would you really want to pull records from a database to populate some grid/view and have incomplete records in there?  Seems like you'd have to write more logic to only pull valid records from the database or have an extra column in the database if the record was complete.

seems goofy.  Help me write better code!

# January 14, 2009 3:24 PM

Jeff said:

If you're displaying incomplete data, doesn't that seem more like a querying issue to you?

Let me give two real world examples. There's the classic shopping cart app. User puts stuff in the cart, fills out some data for the order, blah blah blah, doesn't click submit order on the last page. You still have a great deal of rich information, including what they wanted, the milestone they reached in checkout, etc. You aren't going to ship that order, because you presumably have some way of knowing if their card was charged.

Imagine putting that in session, and the app recycles at the wrong time. At best it could just annoy the user, at worst it could charge them and not commit the order. That, and if they abandon, you have zero metrics on why. In fact, they don't even exist.

Or imagine you're conducting an interview of some kind, for insurance (something near and dear to me), a dating site like eHarmony, or even an app that collects information for an auto license plate renewal. Again, there's the obvious benefit in knowing how people are moving through your funnel, but the more info you collect, the more likely you want to make sure that data doesn't go anywhere for return visits or disappear midstream.

If you absolutely must delete data, it's easy enough to set up a job in SQL or some kind of service or something.

# January 14, 2009 3:43 PM

Jeff said:

Well, just don't use session in anything I may inherit. :)

I don't entirely see your point on what cluttered data is. It still sits in a table in a database, and there aren't dirty 0's and 1's dripping out of the server. :)

# January 14, 2009 3:59 PM

steve said:

this a great discussion.  thanks for participating.  I think i understand both sides of the story.

# January 14, 2009 4:20 PM

Matthew Doyle said:

What I have seen lately is just awful CSS practices... such as calling classes s1, s2, etc, and some of the creative ways people try to style their websites is almost comical, until you take on their project.

I am not positive that there "aren't enough people to go around."  I think the likely cause for crappy code is:

1. Great developers burnt out on boring, lame projects with crippling guidelines and unachievable deadlines

2. Good developers that either don't sufficiently train themselves correctly or work for businesses that have no training opportunities

3. Non-developers that have 'dabbled in Access' so they feel they can build enterprise software

4. In relation to #1, the deadline is coming up and you promised a feature that isn't complete to a client and it would be detrimental to extend the deadline.

# January 15, 2009 1:49 PM

kumar reddi said:

And what about the round trips you are making between database and web server to save everything in database

# January 15, 2009 6:57 PM

Jeff said:

What about them? If a page will still render in .1 or .15 seconds, I feel like I'm in pretty good shape.

# January 15, 2009 9:17 PM

Wim Hollebrandse said:

Trouble is, for high availability sites with huge numbers of concurrent users, these database roundtrips will be major bottlenecks and affect your throughput beyond imagination.

A combination of caching for certain data objects (even for less than a minute or even a few seconds) and a dedicated State Server for Session management would improve on that significantly.

Memory is cheap these days too.

# January 19, 2009 9:28 AM

Old Guy said:

I worked at a place where the kid used arrays for everything.  EVERYTHING.  That was great where arrays were the right tool, but he used them for everything.  If he read in a dataset from SQL, he would put it in an array, loop through the aray to process it, then put the array back into the database.  In doing that, he used the very looping capabilities of the datasets that would have allowed him to avoid the arrays.  Despite his expertise in the world of array manipulation, he would still forget from time to time that arrays were zero-based.  At  least we always knew to check for that first when new code failed...

# January 19, 2009 11:51 AM
Leave a Comment

(required) 

(required) 

(optional)

(required)