|
Vouksh wrote: everything just feels so... hacky
Yup.
Try something simpler, like Knockout (as suggested) or even Backbone. Both have source which is fairly easy to wrap one's head around.
Like you, I come from the happy world of C# (and before that, C++ and Pascal), and it's been quite painful to discover how pathetic HTML is, how pathetic most third party HTML controls are, and how bizarre the hacks are in Javascript to supposedly make web development easier for the programmer.
When I work with other people's code, the DRY principle seems to be thrown out the window and good architecture doesn't exist except possibly what's foisted upon you by the Backbone/Angular/et al "framework", meaning the framework's implementation of a client-side MVC pattern. And debugging Javascript in a browser window can be a frustrating experience, yet I'm actually grateful that debugging is possible, I cringe whenever I put in an "alert" or console.log statement to either check on a variable or test whether the code is even being executed!
It's a mess, and the only way that I've figured out how to deal with it is to simplify, simplify, simplify.
Marc
|
|
|
|
|
Is writing good software hard?
(This should've been posted last Friday, so you will see another in four days.)
... such stuff as dreams are made on
|
|
|
|
|
There are two ways to do anything:- do it right, or do it again.
|
|
|
|
|
That implies the intention to get it right eventually, something which I'm not convinced every software producer has
If the brain were so simple we could understand it, we would be so simple we couldn't. — Lyall Watson
|
|
|
|
|
Nope, it's usually do it now as best you can and never get time to make it right
|
|
|
|
|
"software hard" is an oxymoron.
«There is a spectrum, from "clearly desirable behaviour," to "possibly dodgy behavior that still makes some sense," to "clearly undesirable behavior." We try to make the latter into warnings or, better, errors. But stuff that is in the middle category you don’t want to restrict unless there is a clear way to work around it.» Eric Lippert, May 14, 2008
|
|
|
|
|
But Soft Hardware[^] isn't!
Anything that is unrelated to elephants is irrelephant Anonymous
- The problem with quotes on the internet is that you can never tell if they're genuine Winston Churchill, 1944
- I'd just like a chance to prove that money can't make me happy. Me, all the time
|
|
|
|
|
There are too many intrinsic assumptions in that question. What is good software? Without a baseline, complete definition this is an impossible question to answer properly.
This space for rent
|
|
|
|
|
You are right, what is good? The whole question is loaded by the viewpoint. The coder sees good as bug free, the team leader wants it understandable and easy to maintain, operations want a solution they can support, the users needs it to deliver functionality and the bosses want to maximise ROI.
Pick any viewpoint and 'good software' is a very different beast.
veni bibi saltavi
|
|
|
|
|
I was told that the British are superior at creating and recognizing wordplay. Have I been misled?
... such stuff as dreams are made on
|
|
|
|
|
We also like being contrary. Guess which role I have been filling today.
This space for rent
|
|
|
|
|
Good software provides/implements the easiest possible solution.
Paradoxically, the easiest solution is the hardest to come up with...
|
|
|
|
|
Sander Rossel wrote: Good software provides/implements the easiest possible solution. But what if the easiest possible solution is also far too slow? Is it still good?
This space for rent
|
|
|
|
|
If it's far too slow it's not a(n acceptable) solution
|
|
|
|
|
But is it unacceptable? The original question has no acceptance criteria to define what good software is - it surprises me how often people miss out acceptance criteria.
This space for rent
|
|
|
|
|
It goes without saying that good software at least solves the customer's problem given the available resources (mostly time and money)
If the software does everything the customer asked for within time and budget it's acceptable.
If, for some reason, that's no do-able, a new state of acceptable should be discussed.
But given that the software is acceptable the code should be as easy as possible.
What "as easy as possible" is depends on your knowledge and experience. Assuming that's plenty software should be good if you keep it as simple as possible
*Realizes that's a lot of assumptions*
|
|
|
|
|
Easiest for who? As a case in point, all these lovely single-page-scrolly-animatronic-doodah-websites may be easy to use for someone, but not for others and they certainly aren't the easiest to implement or support.
There's a lovely theory in systems practice [nothing to do with computing] about what is the best solution. It does not necessarily delivery what was requested, but it provides the greatest transition to the required situation with all stakeholders benefitting the most they possibly can. Now put that into your software solution. If it's peas easy to use but a dog's breakfast to support, the solution is less than optimum. How about delivering slightly less functionality in a bid to build up the infrastructure to help ops, this is more evenly balanced and both users and operations benefit. But gad! What about the cost? If it costs too much the bean-counters will be sad and no-one likes sad beanies. So maybe we have to curb some of the costs while pushing use and ops. We could throw in some more stakeholders, marketing or owners, and see how the solution morphs the more we consider different viewpoints.
It sucks to look at things from another persons perspective.
veni bibi saltavi
|
|
|
|
|
To me, a solution is an answer to a problem taking into account all variables like time, cost, usability, etc.
From a programming perspective the code should be as easy as possible, but still support the requested features in the allotted time and in the given budget.
If the customer requests a single-page-scrolly-animatronic-doodah-website than implement it in the easiest way possible.
If that seems to be impossible, again, go for the easiest solution, whether that's stretching the budget, deadline, getting more programmers, or dropping features.
As long as each step is the easiest step possible towards getting to the required goal using the available resources.
Unfortunately, most of the time, everybody but the programmer agrees that making "quick and dirty" code is the easiest solution.
We all know it's probably fast and cheap in the short run, but slow, expensive, and frustrating in the long run
|
|
|
|
|
You're moving in the right direction, but you need to consider as many perspectives as possible. The quick & cheap brigade do get undone more than you'd expect.
veni bibi saltavi
|
|
|
|
|
Nagy Vilmos wrote: as many perspectives as possible Too bad the programmers perspective is rarely one of them
I think we're saying the same, but in other words
|
|
|
|
|
Doing anything well is tedious -- repetitive checking, attention to detail, etc.
That's why so many people don't do things well, and one of the reasons why even the best of us can screw up.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Salvador Dali answered a similar question with the oft quoted 'It's either easy or impossible'.
Peter Wasser
"The whole problem with the world is that fools and fanatics are always so certain of themselves, and wiser people so full of doubts." - Bertrand Russell
|
|
|
|
|
megaadam wrote: Is writing good software hard?
Yes. But writing hard software feels so good.
Marc
|
|
|
|
|
Writing good software is hard.
Resisting the temptation to jump into coding is harder.
|
|
|
|
|
No, on the part of writing code, yes on the part of figuring out what a client wants from a piece of software!
|
|
|
|