Ethical professional developers optimize for business results per unit of resources over product or project lifecycles, balanced risk profiles over project portfolios, and the ablity to scale investment into a given project both up and down as the business environment changes.
Let's break this down.
The virtue of a professional acting ethically is that this allows for trust in working relations between colleagues and organizations, which in turn makes working together significantly more efficient, as there is significantly less need to verify and control. The profession of software development has plenty of in-house codes of conduct, as well as the codified ACM "Software Engineering Code of Ethics and Professional Practice".
Many of the everyday ethical questions break down to the form: should I do A which is best for me, B which is best for my employer, or C which is best for the client. Very rarely you add D, best for our society, when C is clearly detrimental to the society. Unless D is relevant, you should pick C, and you're obligated to look at the problem from the broadest point of view your client consents to provide you with.
When you're considering a product or a project, it's tempting to care only to the extent you're personally involved with it, and wash your hands of the rest. That's not consistent with the aforementioned professional ethics, though. When making decisions, you must consider the costs and benefits of your choices over the whole lifecycle.
A lifecycle means simply the time and space during which the project is being developed. It's also strongly connected to the business motivation that birthed the project in the first place, and through that, to the adjacent businesses and offerings, the marketplace in which it operates, and its competitors.
If you're paid to develop software, it's extremely likely that you're getting paid with the hope that you'll deliver business results. Those might be the capability to serve new customers, serve them better, serve them cheaper, serve more of them, serve them with a varying quality of service, enlarge market share, retarget market share, shorten supply lines, simplify them, work around risks, work around legal barriers, or anything of the sort.
It's very important to understand what business results you're expected to deliver, and how the company and its marketplace operates in those areas. As a professional, you're also expected to communicate a clear enough understanding of how exactly should resources be invested in your area, to get the best results possible. To be able to deliver that, you must understand the nature of those resources, and the process through which they are turned into results. In other words, how people of your profession and adjacent professions work, what happens in people's heads in general, what must be done to get your specific group of individuals to perform together, which skills and how much throughput is required to achieve your objectives, and how to get your hands on those.
Resources are, in our profession, mainly people, but also servers, personal desktops, licenses, enough throughput in corporate processes so that your people can work efficiently, and most importantly, correctly budgeted cash so that you can pay your people, as well as acquire outside expertise if it's needed. You need to understand how capex and opex budgeting works, so that you won't be caught with your pants down with only the kind of money you can spend on bailing water out of the boat, and no cash which you can spend to fix the giant leak in the side.
It's also easy to forget that from your client's standpoint, often the most important costs associated with your project aren't the development costs, but the cost of the its normal daily use by people, over its lifecycle. When thinking of where to spend your development resources, consider that.
Risks and uncertainties concern the probability of the shit hitting a fan in the future, as well as its color and consistency. Every choice carries its own risks. Some alternatives have been tried and tested, and you can guess what's going to happen with more certainty than with other choices.
This is a common and well-known phenomenon. If you're an expert in your field, and provide advice to people concerning your profession, you are required to have a reasonable understanding of the risks your recommendations carry, and communicate that information to your client, by all professional codes of ethics I'm familiar with. Especially in the cases where you're either unaware of the risks, or you're aware of significant unknowns.
The flipside of risks is that you can mitigate them by planning what to do if the shit hits the fan in a certain way, and provisioning for specific eventualities. A common way to handle software risks is to invest in deep in-house expertise for specific aspects of specific technologies, acquire quick-response consulting contracts for them, or to over-provision server resources. This costs a lot of resources.
In balancing risk profiles over project portfolios, you make technology or process choices which are common to many projects. That way you achieve more with the same risk mitigation investment, or you're able to mitigate a significantly larger group of risks and uncertainties.
This very seldom happens by chance - you have to understand the principles and apply this understanding when making technical choices in projects.
When you succeed and your customers are unusually excited about your product, you want to be able to invest more in its development.
If there's, say, an economic downturn, you might want to turn down the heat on your product, and invest less in its development.
Again, if you leave these abilities to chance, it's very likely that your people will get very stressed out when new people are hired, or some of the existing people are moved to other projects, and they have to cope with the change.
However, if you're aware of the fact that conditions often change, you can invest in documentation and clear code, choose languages and platforms which are easy to recruit for, and develop system architectures which isolate components which require quick adaptability and those which require stability and testing, from each other, to mention only a couple of the steps you can take.