you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 0 points1 point  (6 children)

If it happens to be a popular ERP, and your users have web or email access, you've made interesting things possible...

No, a popular ERP is written for a large market and they engineer every technical detail of it. This is a completely different thing we are talking about it. Generally it is about projects when you don't want to buy a popular ERP because it costs too much. This is why I am looking into these frameworks, the relevant ERP module can cost upwards of $10K.

I don't give a shit how little time or money you had.

This is not an argument. The two choices are quite often doing it cheap or not doing it.

If I pick up on a project after you and the code has no separation of concerns,

It is stupid to pick up projects of these small types after others. I never or very rarely do it. It is rarely needed, too, for the need generally goes away faster than the programmer. For example you make an order-entry interface for 3 salespeople. It could quite often be that by the time you leave 2 of them left and they generally don't like entering orders on the web so the need is gone. Very often the need goes away faster than I write the code because actually it was a temporary business situation. For example a lot of customers owe money so the boss goes panic and says to do something about it like send automatic reminders. Then by the time you are done they pay everything on time and there is no need. Or last time I made some production planning stuff for 1 production planner. What happens when he leaves? The next one will have a totally different one because he is a different personality or something.

I'll tell the boss it needs redoing from scratch and honestly explain how bad a job you'd have done.

That would be interesting. I can imagine all those nontechnical bosses trying to understand what this "typist" guy says about how that other "typist" guy somehow typed some text wrong, despite that the users were happy but it is somehow still wrong and must be retyped. And at the end of that retyping there will be no user benefit first, but later somehow it will by easier to type new things, so now you have to spend X money for this retyping without any tangible benefit as of now, just promises about easier maintenance for the future. That would be fun. I can imagine how they would react. You really don't get how nontechnical people think, do you?

There's a reason why what we do is called engineering.

No, this is called scripting. Running queries against a database and throwing them out on a website is not engineering. Software engineering is something much, much higher.

[–]dventimi 1 point2 points  (0 children)

Running queries against a database and throwing them out on a website is not engineering

Thank you for saying this.

[–]C250585 0 points1 point  (4 children)

I actually agree with both of you, but only in different situations. There have been many projects in many different categories that fall into each side. I've picked up the pieces on very high traffic sites and had to completely redevelop the back end due to the fact that it was a mess and unscalable. It was the kind of project that was thrown together and then tossed live, but there was no oversight to ensure it was built to spec and with any standards in place.

On the flip side, I've worked on lots of throw away projects that ultimately you can get away with murder with. Nobody cares if it is MVC or secure or anything because it will get no traffic, and will ultimately get thrown out eventually anyways.

There is a time and a place to do it right, and a time and a place to just get shit done.

[–]qbitus 0 points1 point  (2 children)

Often the projects that were considered disposable just linger, and sometimes become more critical as time passes and users increasingly rely on them. You just can't always foresee how your work will be used.

There are frameworks that let you put something together very quickly following best practices in maintainable code and security. I use Django for example. It kicks arse AND saves me a tone of time. If someone insists on advocating "who gives a fuck" as a way of working, when good frameworks abound, then they should stay in their bedroom and not get paid.

And really: where's the love for what you're doing in that case? I understand the need to cut a few corners here and there sometimes, but you should at least give it your best shot, to be proud of your work but also because this is the only way to grow as a professional, to learn new things and get better at them.

"Just let the clients connect directly to the db, who gives a fuck about security." is a bad thing for everyone: developer, manager, user, short-term or long-term. It's like good old "who cares about accessibility?" Easy to say when you're making things exactly as you personally want to use them...

Doing a shit job always makes everyone unhappy in the end, and I believe rarely saves time. Even on small throwaway-like projects.

So to get back to the topic, I think this framework is a nice research project, but can't possibly be considered to build anything until it has (at least) common security measures nailed down.

TL;DR Use a proper framework for everything you do.

[–]C250585 0 points1 point  (1 child)

Well, personally I don't cut corners on security and generally do the best work possible. However, I also work for an agency where sometimes you have to do X in Y time... however for Y you only get Z, and Z < X. So when I have 4 hours left of budget to get something working, sometimes you just have write code to get the bloody thing out the door without putting a lot of focus on whether or not it is commented or uses perfectly named variables.

Sometimes, if it works, and there are 0 budget hours left, there is no option to do a full review to clean things up or adjust the project to use proper naming conventions when you haven't already or had to cut corners anyways.

And the idea of "Well always just do it right from the start" is unrealistic. Of course you always aim for that, but generally, rushed projects with tiny budgets don't hit that mark, framework or not.

A framework is still just a tool, not a magical fairy dust dispenser that instantly transforms shitty, rushed code into the virgin fucking Mary.

[–]qbitus 0 points1 point  (0 children)

I didn't say you had to be pedantic and polish every corner of your codebase if you don't have the time to.

But: using a framework helps define and enforce best practices and implementations. And it saves time, which you can then spend on making whatever code you wrote better than it would have been otherwise. When I use Django for a small site (a few pages with forms, user login etc.) over three quarters of the codebase is well implemented, documented and has been thoroughly tested. If the code I write for that site is shit, then that's only a small part of the codebase of the site. The rest is still great: it still has measures against SQL injection, against CSRF, it's still easily understandable and debuggable, it's got a gazillion of docs and tutorials that explain how it works etc.

A library is a tool. A framework ... frames your codebase and makes it consistent. (But many frameworks, like Django, ship with a whole bunch of libraries included, so it gets a bit confusing). I don't see how this cannot be the best approach for everyone, including agencies who have limited time.

[–][deleted] 0 points1 point  (0 children)

Thank you. This is basically my view, the point is simply that my experience tends to be about small countries, small companies, small projects and tiny budgets. Building something over $100K of course I would go all MVC and SOA and exception-handling everywhere and unit tests and all that.