4 ms·
It all boils down to what is good software? Everyone understands good software has to fulfill its functional requirements; but what about the non-functional req
by taylodl 6y ago
It all boils down to what is good software? Everyone understands good software has to fulfill its functional requirements; but what about the non-functional requirements, the operational requirements, or the "ilities"?
I've seen a lot of programmers simply assume flexibility and scalability are de facto requirements. Are they? For some systems they are, for others they're not. Embedded systems don't typically concern themselves with scalability and oftentimes don't even worry about flexibility. Simplicity and testability are their major criterion. You need to know your actual non-functional requirements and not make assumptions. This oftentimes requires of years of experience, especially if working in a corporate setting.
Then there's the question of brownfield and greenfield deployment. Companies prefer to evolve software, they're generally not in favor of throwing everything out and starting over. Are you more interested in solving people's needs or using the most popular languages and frameworks du jour?
Greenfield development is risky. Programmers love getting a shot "to do things right." The problem is too many of those programmers are too inexperienced to understand how things became the way they are. They just assume everyone before them was a "bad" programmer and they, of course, are the "good" programmers. All these people are going to do is re-create today's problems, and possibly add in brand-new problems, using the latest languages and frameworks. All at an exorbitant cost.
Software is all about people, processes & tools and tools are rarely, if ever, the problem. Unless you understand people and processes I'm confident you can fail with any software stack you choose. Of course the converse is true too - if you understand the people, their needs and expectations, and the processes then you're way ahead of the game and are likely to succeed regardless of the software stack you choose or are forced to use. That's why I don't care about what programming language you use.
BTW - I like Clojure, I've used it a lot on little side projects. I've never once seen it used for commercial work. Too few people know it for most businesses to risk investing in it. Yes it's a chicken-and-egg problem but remember what I said earlier about people and processes?