There are many different kinds of software and how it is built and why, graphics programming, mathematical computation, artificial intelligence, big data, systems programming, games programming, just to name a few. But, the one I have been involved with for the past four years has been mostly business programming. I had been a coder for a long time before this. I thought I could put together good software for a while; but, I was wrong, especially since I am getting a mind for architecture and management type landscapes.

The first things a programmer should get a hold of when doing this kind of work is the Business Domain and the Problem Space. I think the problem space is always a given for putting together software, and there is always a context to understand. Nonetheless, it seems that knowing the business is more about knowing the people and how they think. The Business Domain has to do more with the users and less with the software and consists mostly of the people that will be using it. I have seen a great deal of Information Technology professionals that start talking badly about the people they are trying to help: their own customer. These are the people you should have the most understanding of..,they are the ones they are designing and producing the software for. These users will be the one's using it for a long duration of time. They are the one's you are eliciting requirements from to make what they want. I understand a lot of the time they do not know what they want, and we need to show them. The fact is, they are who we always need to please, and the customer is always right. And, you can't expect everybody and their brother that works in business be good with computers. And even more, if they are not, it does not mean they are stupid.

The next thing a programmers needs to understand is the Engineer's Domain. Who will be looking at this code again? If you get hit by a bus, will an able body be able to take up the work easily after you have left? Are things going to be upgraded or fixed quickly and efficiently? Are the tools that are involved going to exist in ten years? Is the cost of the tools and upkeep sustainable? All of this is not necessary to know for everyone working on the project due to abstraction from the junior developers and the senior staff engineers to the architects. However, the higher you go in the chain, the more needs to be understood and the more is at stake. A staff engineer or an architect need to know the blueprint along with trusting the developers to handle the bricks appropriately. You cannot expect the bricklayers to be unintelligent if management has done a good job hiring, but they all need to be prepped in the correct way.

For all the domains entail, we need several different quality attributes that are more important to business programming and not as stressed in other kinds of programming. There is more emphasis on it being readable, testable, usable, and maintainable.

1. The code needs to be readable. So, if there is much turnover, then it can be picked up easily by the new guys. There is quick need of business programs since money must be made and there is less time than when a large operating system or program that would bring a robot to Mars. There are many stakeholders that are crying out. I would think more than with research projects. The business programmers must be writing intelligent comments. There also should not be crazy, cryptic code even if it has more performance benefits. I have seem a lot of tools and features that would be used with languages and frameworks, but most of that should be thrown out due to a lack of readability. Common sense must be used when making it make sense.
2. The code must be testable, and I think that is the same with the rest of programming fields. These may all be emphasized, I am just saying that special emphasis would be put on these attributes. The tests need to be intelligible for the next person to be able to write new features over. The tests must be maintainable. They must be neat and clean.
3. The code must be usable by the customer. There is special emphasis on this because the Business Domain requires one to know the psychology of inexperience, not-so-knowledgeable people. There must be great care involved with error handling and things like documentation and the instructions and directions the program presents the user themselves.
4. The code should be maintainable insofar that it should be able to be fluidly developed into something new if business changes or third party software changes. Not all programming is like that. Scripts are written that are scrapped if they are used to produce proofs or if there is a life cycle for a game that is short.

There is a less of a focus on performance with these kinds of things, but there is a struggle with the certain programming triad that is well know of Functionality, Usability, and Security. There is more focus on Functionality and Usability in these domains, but Security matters so much. It is a struggle to figure what must be done with that. There have been a lot of companies using videos that are like entertaining TV shows or series that teach about technology security instead of baking it into the programs. Still, there is security that needs to be put into the code despite the overarching deadlines that make things quickly pushed out. User's data is important, and the one thing that everyone cares about is at stake: money. And, one might think the other thing that people have been concerned about these days is more important than that is identity. Many bad actors out there want to steal users' identities which leads to much more lucrative profit.

All of these attributes of the code and the domains involved stress and strain with everything they are connected to. It is people that make this so difficult. People are inexperienced, need a lot of training, and change many times during their lifetimes. They are unpredictable. Computers are predictable. Mixing the two seems almost impossible. Thank goodness a great deal of this has been mapped out in the science of Software Engineering. However, as new threats happen in our society, and not even with the scope of "hacking" and crime, but environmental factors and workforce problems, these new challenges present a Business Domain with a larger scope, and an Engineering Domain that is just as unpredictable.