Reality or WTF?

Ascendant

Guys, I need your realistic opinion on how things are in real world companies in the U.S.

This is what I have.

There is no modeling.
So there is nobody who designs what classes we should have, what methods they should have etc.
We have Java classes that are not nouns.
Everyone just throws another method to a class to make changes.

Examples of classes we have(obfuscated)

DoXYZIfConditionIsABC
ProcessThisThingAtEveryInterval

Yup. They are the class names. So classes seem like bags of transaction scripts.

No Dependency Injection
The 'new' keyword is everywhere.
The director does not believe in TDD.
So we officially don't require unit testing.
Code doesn't use DI - so testing is nearly impossible or very difficult. Methods are private....
I try to use some unit testing as much as I can
No ORM or query templating.
We are actually weening ourselves away from Hibernate to an in-house thing that wraps around pure jdbc.
So "String query = "select * from ..." is everywhere. And I suppose this is what we WANT to do...??
Microservices without documentation!
We have +200 micro services. No documentation. :) Have fun ?
We actually found "rogue servers" that were running but nobody knew lol
Production database went down and there's no redundancy.
So the service just went kapow! This doesn't happen regularly. It was only the first time. But I'm wondering. Why no redundancy??
Normalisation ....
There is some normalisation but it doesn't seem like normalisation is valued. So I see random columns being added to random tables. No modelling here either. Just keep throwing new columns... until everything works? :D

Now...

Is this normal??
Is this not normal but the reality of an average American software company??
To be more accurate, this isn't a software company that supplies solutions to other businesses.
Rather, it is a company that solves some real world problems, using software. That's how they make money.

Carnage

I don't work in the US, but I'd say that what you're describing goes above and beyond normal fuckery.

djls45

@Ascendant said in Reality or WTF?:

Guys, I need your realistic opinion on how things are in real world companies in the U.S.

[ . . . ]

Now...

Is this normal??

Is this not normal but the reality of an average American software company??
To be more accurate, this isn't a software company that supplies solutions to other businesses.
Rather, it is a company that solves some real world problems, using software. That's how they make money.

I don't know if my company is normal among US-based companies (this is my first programming job), but I can try to compare them.
We provide SaaS and associated support to other companies to help them manage their real-world issues, so we're actually pretty close to the real-world situations.

This is what I have.

There is no modeling.
So there is nobody who designs what classes we should have, what methods they should have etc.
We have Java classes that are not nouns.
Everyone just throws another method to a class to make changes.

Examples of classes we have(obfuscated)

DoXYZIfConditionIsABC
ProcessThisThingAtEveryInterval

Yup. They are the class names. So classes seem like bags of transaction scripts.

We have pretty good modeling built around the various services we have. We have two separate development levels, so the Dev team adds new features and fixes bugs in the core product, and the DevOps team (my team) customizes the product for each client using the customizable sections of the code. Version upgrades for the core program is rarely done for the clients, so Dev is somewhat separated from them, so they have time to get the modelling correct.

No Dependency Injection
The 'new' keyword is everywhere.

I always have to google DI to remember what it means and how it works, but it seems we do use DI pretty well. We use the JBoss Component as the injector, every operation class (service object) implements an interface that other operation classes (client object) can use to support its own actions.

The director does not believe in TDD.
So we officially don't require unit testing.
Code doesn't use DI - so testing is nearly impossible or very difficult. Methods are private....
I try to use some unit testing as much as I can

The Dev team performs unit testing on the core product as they develop features and fix core bugs. The DevOps team generally assumes that the unit tests work, so we just test the customizations we add by running through the modified operation in the program itself. I guess that's a form of integration testing?

No ORM or query templating.
We are actually weening ourselves away from Hibernate to an in-house thing that wraps around pure jdbc.
So "String query = "select * from ..." is everywhere. And I suppose this is what we WANT to do...??

AWAY from Hibernate? No, that is not what you should be wanting to do. We mostly try to use the entity objects and their built-in associations, but there are still a few places where we use HQL, especially when the connections get too messy to deal with in native Java and thus HQL would be simpler and easier to follow. We very rarely use native SQL queries, which is pretty much only when the entity associations haven't been set up correctly by the Dev team or an object's one-to-many collection is transient and lazy-initialized and thus can't be loaded by the EntityManager.

Microservices without documentation!
We have +200 micro services. No documentation. :) Have fun ?
We actually found "rogue servers" that were running but nobody knew lol

That sounds """fun""". We don't have anything like that, to my knowledge (which is pretty much just my segment of the company).

Production database went down and there's no redundancy.
So the service just went kapow! This doesn't happen regularly. It was only the first time. But I'm wondering. Why no redundancy??

We have two production servers for each database/instance, so if one fails, we have an immediate backup. If multiple servers fail, though, we do have separate backups to restore data. And the rate of data production is low enough that adding a couple day's worth of information isn't too big of a deal.

Normalisation ....
There is some normalisation but it doesn't seem like normalisation is valued. So I see random columns being added to random tables. No modelling here either. Just keep throwing new columns... until everything works? :D

Our database is very normalized. I overheard our QC team supervisor say that in his couple of decades of work in QC at various companies that he's never worked for a place that had their database as normalized as ours.

However, I have looked at the database for the system of another segment of our business that our system sometimes integrates with (if our clients use both and want that integration). That database has a lot of XML-in-varchar fields. But the "programmers" for that product mostly just use a Silverlight-based configuration webpage, so I guess that might make sense(?). A few of them are able to work directly in the database, which just makes me glad I'm not working on that part of the system.

jinpa

@Ascendant said in Reality or WTF?:

Guys, I need your realistic opinion on how things are in real world companies in the U.S.

This is what I have.

There is no modeling.
So there is nobody who designs what classes we should have, what methods they should have etc.
We have Java classes that are not nouns.
Everyone just throws another method to a class to make changes.

Examples of classes we have(obfuscated)

DoXYZIfConditionIsABC
ProcessThisThingAtEveryInterval

Yup. They are the class names. So classes seem like bags of transaction scripts.

No Dependency Injection
The 'new' keyword is everywhere.

The director does not believe in TDD.
So we officially don't require unit testing.
Code doesn't use DI - so testing is nearly impossible or very difficult. Methods are private....
I try to use some unit testing as much as I can

No ORM or query templating.
We are actually weening ourselves away from Hibernate to an in-house thing that wraps around pure jdbc.
So "String query = "select * from ..." is everywhere. And I suppose this is what we WANT to do...??

Microservices without documentation!
We have +200 micro services. No documentation. :) Have fun ?
We actually found "rogue servers" that were running but nobody knew lol

Production database went down and there's no redundancy.
So the service just went kapow! This doesn't happen regularly. It was only the first time. But I'm wondering. Why no redundancy??

Normalisation ....
There is some normalisation but it doesn't seem like normalisation is valued. So I see random columns being added to random tables. No modelling here either. Just keep throwing new columns... until everything works? :D

Now...

Is this normal??

Is this not normal but the reality of an average American software company??
To be more accurate, this isn't a software company that supplies solutions to other businesses.
Rather, it is a company that solves some real world problems, using software. That's how they make money.

I have worked at half a dozen different companies. On my current job, they review every line I write with Gerrit. It's so strict I sometimes wonder what they need the programmers for, because the senior developer's views are so specific.

Only one place I worked had unit testing. Unit testing is good, but it sure as hell ain't free. I used to wonder why everyone doesn't use unit testing, and it's because it takes a lot of programmer time.

My current and past employers used Hibernate. (Last one, only on some projects.) I'm ambivalent about Hibernate myself. I think it makes debugging more difficult. I'm an old database guy, and I like SQL, and I want to see the SQL that's being executed. My first job used stored procedures, and the developers had access to the stored procedures, and I think this was the best way.

First job I had had no testing server. (But they didn't make software - I just programmed the in-house software.)

So, in sum, pretty normal, I think.

Captain

@Ascendant said in Reality or WTF?:

DoXYZIfConditionIsABC
ProcessThisThingAtEveryInterval
Yup. They are the class names. So classes seem like bags of transaction scripts.

Verbs as classes don't have to be bad, but these are. These people don't know what OO is for.

No Dependency Injection
The 'new' keyword is everywhere.

Functor? I never even met her.

The director does not believe in TDD.
So we officially don't require unit testing.

No ORM or query templating.
We are actually weening ourselves away from Hibernate to an in-house thing that wraps around pure jdbc.
So "String query = "select * from ..." is everywhere. And I suppose this is what we WANT to do...??

Eh. Raw queries are everywhere. Selecting * is typically stupid, though.

They just make sense to me.

Microservices without documentation!
We have +200 micro services. No documentation. :) Have fun ?
We actually found "rogue servers" that were running but nobody knew lol

Production database went down and there's no redundancy.
So the service just went kapow! This doesn't happen regularly. It was only the first time. But I'm wondering. Why no redundancy??

Normalisation ....
There is some normalisation but it doesn't seem like normalisation is valued. So I see random columns being added to random tables. No modelling here either. Just keep throwing new columns... until everything works? :D

Sounds like... a bunch of cowboy coders. Who haven't been bitten in the ass hard enough to run a ranch yet.

dkf

@jinpa said in Reality or WTF?:

Unit testing is good, but it sure as hell ain't free.

Nor is having code be untested, leaving you to hunt for weird bugs all over it. Unit testing is no panacea, but it definitely helps cut the search space.

anonymous234

@Ascendant said in Reality or WTF?:

No Dependency Injection
The 'new' keyword is everywhere

That seems... pretty darn normal?

JBert

@Ascendant said in Reality or WTF?:

Microservices without documentation!
We have +200 micro services. No documentation. :) Have fun ?
We actually found "rogue servers" that were running but nobody knew lol

Are they even microservices, as in fully isolated?

Could you take half of them down (including their database tables) and still have the other half working?

If not they have built a "distributed monolith", with all the pain of frequent deployments but no real benefits.

Gąska

@Ascendant said in Reality or WTF?:

There is no modeling.
So there is nobody who designs what classes we should have, what methods they should have etc.

On one hand, modeling each and every class long ahead of writing any code is just a waste of time - you don't know what's the best way to do something until you do it. On the other, some planning should be done. At least the high level overall architecture of the system.

The director does not believe in TDD.

Good. TDD loons are just one notch below fosstards.

So we officially don't require unit testing.

This, however, is totally wrong.

Code doesn't use DI - so testing is nearly impossible or very difficult.

You don't need DI for that - parametrized constructors suffice. But if they don't even do that (and sounds like they don't) - yeah, that sucks big time.

Microservices without documentation!
We have +200 micro services. No documentation. :)

Your company would be best described as "suicidal".

@Ascendant said in Reality or WTF?:

Is this not normal but the reality of an average American software company??

No, not really. You should always expect some shittiness everywhere - but what you described sounds like the worst of the worst. You should start looking for another job - this one will make you insane.

Ascendant

@Gąska said in Reality or WTF?:

@Ascendant said in Reality or WTF?:

There is no modeling.
So there is nobody who designs what classes we should have, what methods they should have etc.

On one hand, modeling each and every class long ahead of writing any code is just a waste of time - you don't know what's the best way to do something until you do it. On the other, some planning should be done. At least the high level overall architecture of the system.

I agree. Trying to plan everything ahead is futile.
What we do have is an inhouse Maven archetype. This thing takes care of the configuration of the application. We use Guava and Guice for this. This makes me even more confused though.
If we use Guice, why not use it for DI as well?

The director does not believe in TDD.

Good. TDD loons are just one notch below fosstards.

I understand that following TDD blindly may not be helpful.

So we officially don't require unit testing.

This, however, is totally wrong.

I was guessing so.

Code doesn't use DI - so testing is nearly impossible or very difficult.

You don't need DI for that - parametrized constructors suffice. But if they don't even do that (and sounds like they don't) - yeah, that sucks big time.

I can't remember top of my head but to test one method that I had to modify, this one is a private method.
So... I had to just change it to public to have access to it :D AND to properly initialise the instance, I needed a whole bunch other classes which needed more and more classes and down this rabbit hole, I had to initialise a host of unrelated objects and there were some process tangled to it that some methods would just run....

Microservices without documentation!
We have +200 micro services. No documentation. :)

Your company would be best described as "suicidal".

Yeah.... this one is... pretty "difficult".
On a side note, most of the current devs and the director himself all just inherited this mess. The ones who designed these left long ago.

The local lore goes that there used to be 2 competing dev teams. They disagreed on implementation specifics. So they created 2 separate applications to solve the one problem they were tasked to solve.
They used 2 different DBMSs(different venders), different naming conventions and they modelled the real life objects with different names.

@Ascendant said in Reality or WTF?:

Is this not normal but the reality of an average American software company??

No, not really. You should always expect some shittiness everywhere - but what you described sounds like the worst of the worst. You should start looking for another job - this one will make you insane.

Ascendant

@JBert said in Reality or WTF?:

@Ascendant said in Reality or WTF?:

Microservices without documentation!
We have +200 micro services. No documentation. :) Have fun ?
We actually found "rogue servers" that were running but nobody knew lol

Are they even microservices, as in fully isolated?

Could you take half of them down (including their database tables) and still have the other half working?

If not they have built a "distributed monolith", with all the pain of frequent deployments but no real benefits.

Uh, I think it a mix of both. But you're right. Distributed monolith is a good descriptions of (part of, to say the least) what we have.

I guess they used to have truelly monolith app that one instance did all the work on a single server.
So currently they are making an effort to chop bits out of the monolith and turn that into a micro service.

But then like you said, the new things are also... kinda... distributed monolith I guess.

The concept that I can see they are trying to use, is "pipeline". I've never heard of this pattern before.
So App1 processes something, then signals that it's done and the output is ready.
App2 will accept the output of App1 and process, then it will signal that it's done.
This goes, I guess, up to +200 micro services....?

One of my task was to "figure out how this works".
You read that right. It was this particular application that everyone knew this thing worked. But nobody knew how exactly.
I was tasked to figure out how and document it.

So I went around asking ~~village elders~~ older employees about the lores and what little they do remember.

I did finally figure out how to some degree.

In the process, we found rogue servers running secretly.
Oh by the way, did I mention that within the same cluster of servers( multi instances of the same service ),
the versions are different? :)

Gribnit

@Ascendant You are in hell for the sins you have yet to commit, which will be as many as lines of code you contribute here, good luck.

Ascendant

So the current state of testibility is that the mega giant monolithra is untestible, we simply make code changes, deploy and cross fingers. We do this every time there is a change.

True story.

The other +200 micro services are better compared to this one. Still very difficult to test though.

Ascendant

@djls45
Come to think of it, we basically provide SaaS as well.
I guess you work at a good place! I'm happy for you.

The guys at my workplace aren't bad. All these apps were just grandfathered to them.(without documentation!)

So I guess we're trying to make things work.... now....?
:)

As for Hibernate, I found it sometimes too bloated. But all in all, if you don't use something like Hibernate, or at least MyBatis, you have queries everywhere. I kinda love and hate Hibernate but then again, without it, transaction management can be tricky, especially what you have is an inhouse wrap-around on JDBC.

And I really don't know why they don't have rendundant instances. But oh well, I guess they are ok with this?

Gąska

@Ascendant said in Reality or WTF?:

The director does not believe in TDD.

Good. TDD loons are just one notch below fosstards.

I understand that following TDD ~~blindly~~ may not be helpful.

FTFY. TDD doesn't mean writing tests. It means writing tests in a specific way, and structuring your entire development workflow around the way you write the tests. It's a whole methodology of software development, and it's a very retarded methodology.

You can write lots of unit tests even without TDD. That's my personal approach, and I strongly recommend it.

Code doesn't use DI - so testing is nearly impossible or very difficult.

You don't need DI for that - parametrized constructors suffice. But if they don't even do that (and sounds like they don't) - yeah, that sucks big time.

I can't remember top of my head but to test one method that I had to modify, this one is a private method.
So... I had to just change it to public to have access to it :D AND to properly initialise the instance, I needed a whole bunch other classes which needed more and more classes and down this rabbit hole, I had to initialise a host of unrelated objects and there were some process tangled to it that some methods would just run....

I know that feel. Sounds like your codebase is just very badly designed overall, tests or not. It'll be equally as much fun when you'll suddenly find yourself having to support new data format, or new external service, or something else that's similar enough to what you're already doing that it should be mostly handled by the same code.

@Ascendant said in Reality or WTF?:

The concept that I can see they are trying to use, is "pipeline". I've never heard of this pattern before.

It's a very common pattern - whenever you have some large data to process in a complex way, most of the time you have a pipeline. In its core, it's simply splitting the entire task in a sequence of individual steps, with each step only reading data from previous step's (or steps') output, and producing a single bundle of output for other steps to use. The best "real life" analogy would be a conveyor belt in some factory that takes the product through several processing steps in order.

Gąska

@Ascendant also - it's "testable", not "testible". The latter sounds like something related to testicles.

Ascendant

@Gąska Whats wrong with soundling like testicles? XD

Gąska

@Ascendant it might look bad on task board at work. Just saying.

Ascendant

@Gąska no worries. I was just kidding :)

marczellm

@Gąska said in Reality or WTF?:

So we officially don't require unit testing.

This, however, is totally wrong.

I'm writing a 3D viewer on top of a 3D engine and I can't help but wonder if most of our classes are simply impossible to unit test. Also UI view classes, classes implementing the application networking protocol, classes implementing UI design requirements, classes implementing image processing algorithms...

The_Quiet_One

@Ascendant said in Reality or WTF?:

Guys, I need your realistic opinion on how things are in real world companies in the U.S.

This is what I have.

There is no modeling.
So there is nobody who designs what classes we should have, what methods they should have etc.
We have Java classes that are not nouns.
Everyone just throws another method to a class to make changes.

Examples of classes we have(obfuscated)

DoXYZIfConditionIsABC
ProcessThisThingAtEveryInterval

The only way I could see this "make sense" is if it's meant for some kind of fluent interface where you wish these to be sentence fragments that are put together into one big one.

Yup. They are the class names. So classes seem like bags of transaction scripts.

No Dependency Injection
The 'new' keyword is everywhere.

Every job I've had since 2010 had DI. To me it's just essential to have a well-designed and loosely coupled application.

The director does not believe in TDD.
So we officially don't require unit testing.
Code doesn't use DI - so testing is nearly impossible or very difficult. Methods are private....
I try to use some unit testing as much as I can

Unit testing has always been a crapshoot for me. Where I am now, we do some integration testing, but not unit testing. And even then it's spotty. The problem with TDD is you really need everyone to be 100% on-board with it for it to work. As soon as you make it lax or certain team members just don't do it, the methodology is going to collapse.

No ORM or query templating.
We are actually weening ourselves away from Hibernate to an in-house thing that wraps around pure jdbc.
So "String query = "select * from ..." is everywhere. And I suppose this is what we WANT to do...??

Is it at least parameterized query? If not, then that's not only poor design, it's just asking for Bobby Tables to come and wreak havoc on your database.

This is not reflective of any US company I've worked for. Everyone has had some kind of ORM since I started my career roughly 15 years ago.

Microservices without documentation!
We have +200 micro services. No documentation. :) Have fun ?
We actually found "rogue servers" that were running but nobody knew lol

That's a signal of poor leadership and bad code review. When you make changes that obsoletes things, you need to remove those obsoleted modules. And, yes, documentation is key to make that easy. Every US company I've worked for at least makes an effort.

Production database went down and there's no redundancy.
So the service just went kapow! This doesn't happen regularly. It was only the first time. But I'm wondering. Why no redundancy??

Because they're morons. Was it at least recoverable? Was it that the DB became unavailable, or did you lose the data???

Normalisation ....
There is some normalisation but it doesn't seem like normalisation is valued. So I see random columns being added to random tables. No modelling here either. Just keep throwing new columns... until everything works? :D

Normalization is something to strive for. Now, I've seen DB designs that slightly denormalizes a database table in the name of optimization, but usually you don't need that.

Now...

Is this normal??

Depends on the company. A business who is specifically in the software industry is less likely to make these kinds of anti-designs. If you're working for a company who is in a different department with an internal IT department, I think you're more likely to find this kind of thing. Reason being, usually the leadership of a software company are less likely to be made up of real s and have an actual CTO who knows what he/she is doing. In a company that is in, say, the fashion business, they're lead by non-technical people who might even consider IT to be an afterthought. Thus, their hiring practices are not as robust as you would find in a software company.

Whenever I seek jobs, I am very picky about the competence of my colleagues and leaders, though. So, I have definitely seen businesses big and small and software/non-software focused who have lots of WTF code (Heck, just the forgotten homepage of this very site shows that is a fact; a lot of the stories are global, but a lot of them are based from the US). But I've found that most of the successful companies who have kick-ass software typically have well-designed software.

Jaloopa

@Ascendant said in Reality or WTF?:

So the current state of testibility is that the mega giant monolithra is untestible, we simply make code changes, deploy and cross fingers. We do this every time there is a change.

True story.

The other +200 micro services are better compared to this one. Still very difficult to test though.

No software is untestable. It might not be unit testable but manual and automated testing are always doable and can find defects that unit testing wouldn't anyway

boomzilla

@jinpa said in Reality or WTF?:

My current and past employers used Hibernate. (Last one, only on some projects.) I'm ambivalent about Hibernate myself. I think it makes debugging more difficult. I'm an old database guy, and I like SQL, and I want to see the SQL that's being executed. My first job used stored procedures, and the developers had access to the stored procedures, and I think this was the best way.

I love Hibernate. It makes boilerplate sort of stuff easy. HQL is even pretty nice and handy for what it does.

I still drop to raw SQL a fair amount just for performance, though. This is mainly for stuff that needs to pull in a lot of objects. I mean that both based on the number of the "main" entity I'm targeting plus all of the related objects. Our data is fairly heavily normalized so there's a lot there, and Hibernate does not scale well for that sort of stuff.

I can make some configuration switches to get the raw SQL of what Hibernate is doing when I'm debugging, but that's usually only necessary when I've added some new object and haven't gotten it correctly set up yet.

The idea of using stored procedures for everything continues to horrify me. We do have some (and even some that are wrappers for Java code!) and they are handy, but mostly used by us inside of actual queries, not as something we'd call as standalone things.

Captain

I like Dapper with raw T-SQL because it's easy. Write the query the straight-forward way, and get automatic object parsing. The only thing I wish was that Dapper could output/convert to more collection types out of the box.

Is it an ORM? I guess they call it an Micro ORM. That's good enough for me. And it's close enough to what I do in Haskell, where I use the RawSQL interface to the Persistent library (another sql-to-programming-language-mapping library).

I think @sam was involved in writing it.

Honestly, I got sick of having like 3 different SQL interfaces in my apps and have chosen to settle for a sane "raw sql" micro-orm thing in every environment. Writing the sql was easier than writing the stupid orm version in the first place. And this really helped cut back the number of libraries I have to remember.

Tsaukpaetra

@boomzilla said in Reality or WTF?:

The idea of using stored procedures for everything continues to horrify me.

It's slightly better than the string-concatenation that was being used before, but only just...

pie_flavor

@Tsaukpaetra dunno if you're confusing stored procedures with prepared statements.

boomzilla

@Tsaukpaetra said in Reality or WTF?:

@boomzilla said in Reality or WTF?:

The idea of using stored procedures for everything continues to horrify me.

It's slightly better than the string-concatenation that was being used before, but only just...

Yeah...what do you mean by "string concatenation?" Something like...

results = createQuery(
    "select bar " +
    "from foo " +
    "where id = :id" )
    .setParameter( "id", myFoo.getId() )
    .getResultList();

djls45

@boomzilla said in Reality or WTF?:

@Tsaukpaetra said in Reality or WTF?:

@boomzilla said in Reality or WTF?:

The idea of using stored procedures for everything continues to horrify me.

It's slightly better than the string-concatenation that was being used before, but only just...

Yeah...what do you mean by "string concatenation?"

I think he means something more like

results = createNativeQuery("" +
    "select bar " +
    "from foo " +
    "where id = '" + myFoo.getId().toString() +"'")
    .getResultList();

Tsaukpaetra

@pie_flavor said in Reality or WTF?:

@Tsaukpaetra dunno if you're confusing stored procedures with prepared statements.

Nope!

@boomzilla said in Reality or WTF?:

@Tsaukpaetra said in Reality or WTF?:

@boomzilla said in Reality or WTF?:

The idea of using stored procedures for everything continues to horrify me.

It's slightly better than the string-concatenation that was being used before, but only just...

Yeah...what do you mean by "string concatenation?" Something like...
results = createQuery(
    "select bar " +
    "from foo " +
    "where id = :id" )
    .setParameter( "id", myFoo.getId() )
    .getResultList();

Yes, this. But without the .setParameter and more with the:

string sql = "select bar " + barColumnName;
sql += " , foo " + fooColumnName;
sql += " from foeybahrtable where faz = '";
sql += sprintf("%s'",*fazStringSearch);

Captain

@Tsaukpaetra I see this in the legacy app I'm working with today. At least they used prepared statements.

(This string contatenation, with logic, is part of why I did all the TTTTTESTING stuff.)

Tsaukpaetra

@Captain said in Reality or WTF?:

At least they used prepared statements.

Yeah, prepared statements literally aren't a thing in this codebase. I was planning on introducing it (it's not fucking hard), but now I'm caught up as the only one in the company now, so...

Captain

@Tsaukpaetra Show the big boss that XKCD comic...

Tsaukpaetra

@Captain said in Reality or WTF?:

@Tsaukpaetra Show the big boss that XKCD comic...

Which one? They kinda run together...

Captain

@Tsaukpaetra said in Reality or WTF?:

Which one? They kinda run together...

Tsaukpaetra

@Captain said in Reality or WTF?:

@Tsaukpaetra said in Reality or WTF?:

Which one? They kinda run together...

Ah yes. It was "solved" (not by me) by banning the single-apostraphe symbol.

Captain

@Tsaukpaetra OK, then tell them prepared statements are 3-17% faster, for free. The database gets to prepare, and it saves time. That sounds like something people in a PHP shop would believe. (Just assuming PHP based on how amateurish they sound)

PleegWat

@Captain On oracle, it speeds up parsing and allows it to reuse plans even if the bind values are different. I forgot which DB we're talking about here but similar things may apply.

Captain

@PleegWat That could be really helpful on a long-running server process.

jinpa

@PleegWat said in Reality or WTF?:

@Captain On oracle, it speeds up parsing and allows it to reuse plans even if the bind values are different. I forgot which DB we're talking about here but similar things may apply.

Same with SQL Server.

hungrier

@Captain

dkf

@PleegWat said in Reality or WTF?:

I forgot which DB we're talking about here but similar things may apply.

I'd expect it on virtually all of them. Not needing to reparse the SQL at all (because it's character for character identical to a previous run) is almost always going to be a bit cheaper option than guessing that $THIS is sufficiently similar to $THAT…

japonicus

@dkf said in Reality or WTF?:

I'd expect it on virtually all of them. Not needing to reparse the SQL at all (because it's character for character identical to a previous run) is almost always going to be a bit cheaper option than guessing that $THIS is sufficiently similar to $THAT…

Does sql parsing (as distinct from query planning) take a significant amount of time, compared to the time taken to plan and then run the query?

japonicus

@Captain said in Reality or WTF?:

@Tsaukpaetra OK, then tell them prepared statements are 3-17% faster, for free. The database gets to prepare, and it saves time. That sounds like something people in a PHP shop would believe. (Just assuming PHP based on how amateurish they sound)

For PHP I suspect that much of the obsession with prepared statements is misplaced cargo-cultism: a reflection of people confusing parameterized queries (good) with prepared statements (mostly irrelevant or counter-productive in the context of a short-lived php process).

There's no point creating a prepared statement if the process uses it only once and then throws it away, which would be typical usage from PHP.

dkf

@japonicus said in Reality or WTF?:

There's no point creating a prepared statement if the process uses it only once and then throws it away, which would be typical usage from PHP.

That depends on what the database engine does with caching.

japonicus

@dkf said in Reality or WTF?:

That depends on what the database engine does with caching.

True, but neither MySql or Postgres cache prepared statements beyond the end of a session and those two databases probably account for the vast majority of php based setups.

Jaloopa

@boomzilla said in Reality or WTF?:

The idea of using stored procedures for everything continues to horrify me

Where I work it's a permissions management thing. The user the software rubs under has no read or write access and can only run stored procedures, meaning in theory we know exactly what can and can't be done by a non DBA/DevOps. In practice, DevOps set up an automated process in live only that created insert, update and select procedures for every table in the database. We only found out when trying to add our own select sp for a table and being told there was a naming clash when it was time to go live

BernieTheBernie

@Ascendant Welcome to the Real World of Software Development.
We're looking forward to your valuable contributions to Errored, CodeSOD, etc. - you are next to a good source!

Zenith

@Ascendant said in Reality or WTF?:

Is this not normal but the reality of an average American software company??

This is usually when an "American" software company is full of Indian fuckups.

Except the ORM complaint. I don't know why it's so hard for developers these days to do their own queries and objects. Every Entity-dependent dump that I've ever worked at wasted far more time rebuilding the database or regenerating classes every time they changed a field from VARCHAR(4) to VARCHAR(5) than they saved by being fwightened of ADO.

boomzilla

@Zenith said in Reality or WTF?:

Except the ORM complaint. I don't know why it's so hard for developers these days to do their own queries and objects. Every Entity-dependent dump that I've ever worked at wasted far more time rebuilding the database or regenerating classes every time they changed a field from VARCHAR(4) to VARCHAR(5) than they saved by being fwightened of ADO.

We used to regenerate everything when we were first building the application but we haven't done that for over a decade. I'm not sure what "regenerating" classes means, but I've never used ADO. We just update the classes in code (including annotations for stuff like field size).

In the java portion of the application I use the ORM's basic CRUD methods and its query language and native queries as the task makes sense. When dealing with a single object it's a lot more convenient to just update its data and save it than to write the associated update query. Ditto for loading. In the C++ portion I use all native queries. It's nicer to have the facilities of the ORM if I want them.

It's not that people can't do all that stuff by hand, but if you don't need to, why would you?

Zenith

@boomzilla said in Reality or WTF?:

We used to regenerate everything when we were first building the application but we haven't done that for over a decade. I'm not sure what "regenerating" classes means, but I've never used ADO. We just update the classes in code (including annotations for stuff like field size).

The two places I worked that used Entity, in 2015, had to lock TFS and regenerate every single object class after a change to the database. It took hours to run whatever they did and, when it was over, you lost all of your customization. For some people, that's the meager handful of attributes it allowed you to define. For others, that's the real business rules that said meager handful of attributes provided didn't cover. Absolute nightmare.

It's not that people can't do all that stuff by hand, but if you don't need to, why would you?

Don't be so sure about that first part. I suspect the reason one place in particular fought and fought and fought the tooling to do stuff it couldn't do was because they couldn't do it without the crutch of tooling. When you're spending MONTHS on a single page/form and not getting anywhere, something's clearly gone wrong.

As for why you'd want to....do you want a list?

The number of database-derived objects in a properly designed system is really small. In that case, it's like paying somebody to clip your toenails. You saved 30 seconds on the clipping and lost 30 minutes driving, waiting in line, making small talk with the professional clipper, and being rung up at the register.
The number of database-derived objects in a properly designed system is really small. Once you hide the "pain" of setting them up, you open the door for that number, and the complexity of the database, to fucking explode. Good luck navigating, troubleshooting, or refactoring that once the problems start (and they will, believe me).
You lose the ability to actually optimize code. Maybe I don't need all 50 columns off a table. Maybe I don't need the boilerplate.
Sometimes you don't need another dependency that throws up word salad when it doesn't want to work. Sometimes you don't need the dependencies it's dependent on either. Sometimes you don't want pulled along the update treadmill.
Sometimes you need to do something the library won't let you do ("you don't need..."). Sometimes you know better than some nebulous "community" of "experts" whose credentials are basically being the right color to pass a Google interview. When every idea is summarily shot down because "library/service something something dark side," what you're really being told is that you're never good enough, What if everybody thought that way? Where would any progress or differentiation come from? How the hell are you supposed to learn anything if your job is plugging half-baked black-box shit together all of the time? At that point, you're not even a developer anymore.

It's not that you can't use a library/service, It's the insane tunnel vision that forces the library/service to the exclusion of all else.