... don't use Google to see what SQL Server DBA's use for data modeling. Definitely more productive to stick to your contortions, as a protest to MS for wanting you to support the greater good of capitalism by buying a 3rd party tool.

Sounds like you'd fit in great where I work. Wanna replace me? I tried introducing writing unit tests at this place, for example, but like all good software engineering ideas, the team probably considers it what you said: "Overkill". That's why I need to get out of there. I suppose being a contractor, expediency is mostly all that matters. Maybe I could've done that has a younger dev, when I didn't know anything, but atrocious practices are just too frustrating for me now. Now that I'm a grumpy old programmer I guess.

I don't believe the technical parts of that article. It could've started small, and iterated over the 3 years to be ready on "Day One". And I don't believe it was a "very hard technical problem". Silicon Valley is full of good communist techies; they built the Obama campaign a kick-ass system. They could've built a good Obamacare web site.

But I do agree on the federal contracting system. To avoid corruption, the rules are they have to choose the lowest bidder, not the vendor they think is most likely able to do the job. But then, as the author says, some corruption is avoided, but what's built doesn't fit the bill. The solution is to remove the impossibility of firing a government worker. Make them accountable for the shit getting done and working, and better not have any ties to the vendor. People are lined up around the block trying to get a cushy government job; be successful and honest in what you do, and your job is safe, otherwise, they are plenty of others to replace you.

Most people would rather talk about how capital punishment is inhumane and unjust. Because there could be a case where the person is innocent, and didn't deserve to die.

Proper software design is slightly costly, in performance. Luckily for typical web CRUD apps, it doesn't make any difference. Except for the gains in all the other desirable qualities of code.

One thing the kid at work said I do agree with: It's a lot easier to scale the web site than it is the database.

Ease of deployment is what is cited by my coworkers as well. Well, then why are we using MVC to generate our HTML, when we can write T-SQL to do that, and everything else. Then we'd be ready to change literally anything, immediately, without deployment troubles and delays.

Then again, my coworkers come from VB programming backgrounds, so I'm not surprised.

God help you then.

If performance were the top criteria, I'd advocate writing web sites all in assembly language. Fortunately, it's not; readability and maintainability are.

Which means that besides being a software engineering best practice, doing the business logic in a modern, powerful middle-tier language typically also means less code to express the same logic (which then is more readable and maintainable).

But you're right about the 70's part. The last time developers thought it was a good idea to implement business logic in a scripting language was during the dot-com era, when people were doing PHP, and Perl, and ColdFusion, and I was doing now-classic ASP (with VBScript).

It's 15 years later, and as I code a morass of business logic in a fucking scripting language, I know I have to leave this place. Just as sure as I would never accept a classic ASP job again.

And it occurred to be today as I was coding presentation layer logic in T-SQL, that this app is an n-tier architecture, but n=1!

p.s. I've seen opposite cases too, BTW, where for example sorting was written in application code because the developer didn't know ORDER BY apparently. Basically, SQL should be used for persistence and querying. Nothing more. The only time that for example string manipulation T-SQL functions should be used is if you're doing SSRS reports, where you have no other choice. (That is, that's the only time this bad choice is an acceptable one.)

I've been in SQL hell the last couple of weeks, so I'm definitely not making jokes about it. The brilliant non-engineers where I work basically put all of the non- UI-related business logic in the fucking data layer, so the powerful and modern language C#, with its extensive .NET library at its disposal, is used merely for marshalling data from the UI to SQL Server, and all of the business logic has to be written in a fucking scripting language (T-SQL).

I like T-SQL, but not for doing 90% of the application's logic in!!! So I've gotten the chance to learn about MERGE and its OUTPUT clause. And PIVOT. And this week I get to learn about recursive queries and STUFF. God I want a job where they use an OR/M.

p.s. And our database schema, and who dictated how we would use it, is from a 30-year-old junior DBA, who my brilliant fucking PHB hired into a Database Manager V level position. (At most companies a level 5 position requires 20+ years of experience to be eligible for; i.e. not exactly meant for a sysadmin (and he's really good at that, incidently) who just recently added DBA stuff and who apparently has never worked on a development project before.

So data for an entity is scattered across multiple tables, entities' ID's aren't stable (because no updates are allowed, everything has to be an archive and insert), so integer PK's mean nothing as an additional GUID column is what remains stable across "updates", and no updates are allowed that aren't strictly changes, so everything has to be checked on a save to see what parts of a conceptual record aren't changed in the tables they're located in!

Mapping tables out the wazoo, for relationships that aren't 1:M or M:N, in a big mess of inconsistently named columns across tables. The data layer is wagging the application, and an infant is in charge because the big boss is an apathetic asshole. Thankfully, I think I have only one more week left of this, where my save sproc calls seven others, because there's so much logic to perform for a save of a simple form, and then it'll be done. Until the next project, which I hope and pray I'm not around for.

p.p.s. And he doesn't care about isolation levels. So if any of the views in our web application are ever edited concurrently by two or more users, data corruption. God I miss working with software engineers.

Presumably easier interaction with computers would be considered a positive adaptation by the magic god of Evolution, and would be selected for.

Some of my best thinking is done in the shower in the morning. Would not be pretty to watch that.

Then again, this is really the kind of thing that computers are good at (identifying extra whitespace) and people are bad at, and therefore should be automated. Either with user input validation, or automatic detection and correction (say if no commands may legally have more than one space between words). Or, it should've been "NOLOGO", like command-line parameters.

I was thinking sensor technology, not implant technology. Borgifying people creeps them out, but if a computer can eventually read and interpret my brain waves or something, without having to drill any holes (!), then that would take off.

p.s. Polygraph administerers would be out of a job, I guess.

They want the pathetically outdated notion that what makes a good editor is something that runs on a dumb terminal and uses a user-hostile endless number of cryptic keyboard combinations back.

Seriously, it'll be 2060 and its ilk like VMS and DOS will have long been forgotten, but there'll still be UNIX luddites clutching to their clumsy, antiquated operating system and editors.

By then we'll be have neural inputs into computers, and just think our messages and commands, and get basic operations with computers done with lightening speed and ease. There'll probably still be Slashdotters, who'll say wait, let me fire up a relic that requires me to type everything, including cursor navigation.