- 1) Choose languages that developers are familiar with, not the best tool for the job 95% of the time, a language that your developers are familiar with is the correct tool for the job simply for that reason! There are cases where it is not the case but those involve special case languages and special case systems. If you don't know what special case means then you're situation is almost certainly on that list. - 2)…
Ask HN: Are we overcomplicating software development?
371–378 of 378 posts
Re: Ask HN: Are we overcomplicating software development?
#372Earlier quoted context omitted.
I asked the same question last year and to be honest, building a SPA is tough with just jQuery. It's more of my needs changing, I don't think SPA can be ignored in 2017, the progressive web app and AMP will put a huge dent in the native apps space. I just like to think that I'm developing a mobile app with front-end javascript framework....it's just the tooling and prerequisite knowledge is quite chaotic. Finding the…
I'm not sure why an SPA with jQuery is tough. $.ajax. Send data. Do stuff in a back-end. Return data. Update divs. If it is tough, you might be trying too hard. I'm not trying to be glib... it just sounds like you might be buying into the over-complexity that the original question was talking about.
Re: Ask HN: Are we overcomplicating software development?
#373Earlier quoted context omitted.
One thing that bothers me is the 'relational databases are good enough' statement, that is repeated in other contexts as well. But especially here, where we're talking about reducing complexity, it feels off to me. PostgreSQL and MySQL seem to me like incredibly complex packages. SQL, the language, is not easy to master either; most programmers I meet know mostly basics. On top of that, there's a long ongoing history…
The implementation of PostgreSQL is complex, no doubt about that. But if you need strong data consistency and durability guarantees, it provides a rock-solid foundation. SQL might take some getting used, but it is also not rocket science. It shouldn't take more than a week's study to master the basics. There is of course a lot of awful SQL code out there, exactly because most programmers don't even know the basics. Y…
Re: Ask HN: Are we overcomplicating software development?
#374One of my fav tech talks ever (and I watch a lot of tech talks) is Alan Kay's "Is it really 'complex'? Or, did we just make it 'complicated'?" It addresses your question directly, but at a very, very high level. https://m.youtube.com/watch?v=ubaX1Smg6pY Note that the laptop he is presenting on is not running Linux/Windows/OSX and that the presentation software he is using is not OoO/PowerPoint/Keynote. Instead, it is…
Re: Ask HN: Are we overcomplicating software development?
#375Earlier quoted context omitted.
I'm not sure why an SPA with jQuery is tough. $.ajax. Send data. Do stuff in a back-end. Return data. Update divs. If it is tough, you might be trying too hard. I'm not trying to be glib... it just sounds like you might be buying into the over-complexity that the original question was talking about.
The problem with jquery is that the state is stored in html elements. It makes it hard to debug, maintain and learn bigger applications. Things like accessing a hidden variable become DOM traversals rather than property accessors.
Frequently, I do store metadata in a DOM element because the next event I will react to is a click on that DOM element, so I already have a handle on it from the ui element jQuery gives me... I do not have to traverse the DOM. But if the future use of the data is NOT going to be a response to a click on a specific DOM element, then no, I will do something else with the data.
Again, just because everyone else does it doesn't mean you have to, and doesn't mean it is inherent in the tools. I'm not saying jQuery is the best tool out there... I'm saying that complexity in an SPA doesn't come from jQuery itself, but from design choices made with it.
Re: Ask HN: Are we overcomplicating software development?
#376Earlier quoted context omitted.
The problem with jquery is that the state is stored in html elements. It makes it hard to debug, maintain and learn bigger applications. Things like accessing a hidden variable become DOM traversals rather than property accessors.
jQuery is just a framework, if even that. If you choose to use it to store state in html elements, that is your choice. And yes, a common one. But the framework does not force it. If you make an AJAX call in jQuery, you get JSON back. (Or, I use it to get JSON back... you can send whatever you want back.) You can do whatever you want with that JSON. Frequently, I do store metadata in a DOM element because the next ev…
Re: Ask HN: Are we overcomplicating software development?
#377Earlier quoted context omitted.
It doesn't sound like the 'Agile' team is doing standups right. There are either too many people in the room, or people are talking too much, and probably about the wrong things. And, if they are doing standups wrong, I question how much else they are cargo-culting.
Generally claiming that a person is doing the method wrong when the method brings no percieved benefits raises a red flag on the general applicability and value of the methodology itself on the problem the person is trying to solve. There is no one true way to organize development of software and generally shoehorning dogma without proof of value is counterproductive.
Agree completely. When incredibly common complaints about a methodology are raised and the response is "you're doing the method wrong" you start to err towards dogma and a "No true Scotsman" approach to management.
Sticking to any technique, including agile, no matter what and with no modification is a symptom of a problem. Projects are unique, there's no one size fits all way to manage them.
Re: Ask HN: Are we overcomplicating software development?
#3782) Is a pet peeve of mine. Theoretically microservices are good, but we don't have a way to orchestrate them. What's lacking (in programming languages terms) is a "runtime" and "debugger" and of course a widely-tested & reliable set of "libraries" for most common tasks. I think it's possible to do something like that, as long as you start imposing some restrictions on what a "microservice" is and how it talks to the outside world. Also, in this frame of thinking, it becomes apparent that "deployment" is actually "programming the system, at a high level". It's not "just configuration", configuration is code - if you moved the complexity from your "code" to your configuration, you just moved the complexity into a language that has very poor tools to work with.
3) My rule of thumb for most systems is "avoid redundancy in the control plane; you can and should have redundancy in the data/data processing plane; don't plan for 100% uptime in the control plane, plan for very short downtimes/ for fast recovery when something goes wrong"
4) My experience is that continuous integration is good for all but the very small teams. For multiple reasons, not just "microservices"
5) "Agile" is horrendously misused, the cargo cult is in full force. It should be about prioritising & doing the important things, reducing overhead to the minimum necessary. It has become an overhead in itself, with "sprints" reduced to ridiculously low periods, meeting over meeting at each sprint, etc.