Is most software development really as bad as I think?

24 Comments

• 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.
  

• 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.
  

• 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.
  

• 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.
  

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

• 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?
  

• 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.
  
  
  

• whats wrong with datatables and sessions
  

• 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.
  

• Have you ever looked the examples within MSDN on how to do things?
  
  Where do you think most people go to figure things out?
  

• 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.
  

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

• Databases are good for starters!
  

• 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)
  

• 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?
  

• 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!
  

• 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.
  

• 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. :)
  

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

• 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.
  

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

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

• 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.
  

• 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...