Everything is a tradeoff. Optimizing for less code is de-optimizing for detailed control over appearance and behavior and independence from some vendor’s concept of how the app ought to appear / behave plus their vision for the best approach to the solution (and inevitably at some point your client will disagree with the vendor – and there’s little you can do to accommodate them).
I considered for example Lianja which is targeting more the low-code approach and I found that you have to endure a shotgun marriage to their concept of data binding and components that respond to DB relations in particular ways. It could be arguably great for CRUD apps and terribly confining for anything else. And now they have decided to ditch their community edition and raise their subscription prices, which takes them out of the running entirely so far as I’m concerned. I can no longer do a proof of concept over some weeks or months and find most of the box canyons they have built for me and figure out if I can live with them before buying. Now I have to commit $1K for the privilege. How they think they’re such hot sh_t that anyone is going to put up with that is beyond me.
This is where all the low/no-code platforms end up taking you, down the path of their architectural vision and emphasis, which to make matters worse tends to thrash around and change all the time as the vendors are mostly smaller and struggling for purchase and identity. We see this happening with Xojo as well – are we targeting pros or “citizen devs”? Can’t seem to decide.
I lean more toward a general purpose language / framework than you for this reason. Xojo could be a nice compromise if they had the resources and humility to make it so. But I think inherently that the only platforms that will remain reasonably stable and viable for decades at a time (e.g., 20 years and counting for .NET; during this same period RealBasic became Xojo and still struggles to target the web which you could reach with .NET from the beginning) are the ones with broad enough utility to bring in a large number of devs and support many different project types. And even with ecosystems like Java and .NET there are evolutionary breaking changes that don’t cleanly run through some kind of converter (e.g., ASP.NET => ASP.NET MVC 5 => ASP.NET Core and now Blazor – it’s nice to have choices but god help you if you make the wrong choice).
As someone aptly pointed out in an opinion piece the other day, devs should be happy that software development is hard, otherwise they would not pay us the big bucks.
Always implement the simplest algorithm first, rather than bogging down in the details of an optimal algorithm. Once it’s all working, go back and optimize. In 80% of cases optimization won’t be required anyway.
When a large project starts getting crufty or suffering from bit rot, suppress the urge to rewrite it from scratch. That is the road to disaster. Rather start refactoring the nasty bits, and keep going until the cruft has (largely) gone. Added to the fact, your client is not going to pay you for that rewrite.
Make sure any alpha or beta builds that are released into the wild for users to test are, to the best of your ability, free of obvious bugs. If this can’t be done, make sure you warn your testers about the dodgy bits.
This has started as an interesting and informative topic, but developed into a completely different direction.
Would be nice to have the off-topic ones split into an own thread…
When managing new-and-eager engineers and computer scientists for a summer job, I would have them work on a significant project. Throughout the summer they would also work on a powerpoint presentation on this project and then on their last day, they would present their work to the team.
When the student returned back to university, they would be able to easily answer the question ‘What did you learn during your summer job’? Some were nervous when presenting to the team, and it was a good learning moment for the student.
True, but sometimes the client doesn’t want to pay for the harder/better way. Sometimes you have to put a bandaid on code rather than do the major refactor it truly needs. Plus, we’ve all, I’m sure, avoided doing some refactoring because it was going to be a lot of work and the client was happy-ish with it the way it was.
True, and the trick is to make sure you don’t get set up to take the blame for technical debt, but a certain amount of this has been bread and butter for me actually. I spent 13 years building out a whole operational system with data hygiene etc and since the company was bought out it has been in Keep The Lights On (KTLO) mode while they pick its bones clean. Eventually things start to fail – for example a lot of our data contributions come by email and MSFT no longer allows simple authentication to Outlook Server so that our processing services can auto-route the data, so rather than invest a substantial amount in the asynchronous coding needed for whatever they are using now I just offered to hand-route the emails since it’s only about 5% of our volume anymore (although that’s still over a hundred companies). Still, it keeps me super busy about 10 days out of the month, at a very nice hourly rate, so why not. Since they really only care about the customer list and the data, it even makes a kind of warped sense. I just keep reminding them of the hole they’re digging, should they ever come to their senses.
Code is so ever rarely “done” in a way it never needs to be touched again
Like real life the world around evolves & changes and systems need to be updated to adapt
Otherwise they die
