The Cost of Development
I hear many people mention the phrase working smarter and not harder but what does that mean for software development? If we could ask the question:
What do we want out of development?
1. Faster delivery (nothing changes but death and taxes)
2. Confidence (Testing)
I appreciate the two points above can be solved in a of multiple ways, like developing a pipeline. For the time being just focus on a question:
How many changes do we have to make in order to make to achieve the business requirement?
Addressing the vague consideration: The impact of existing code base and technical relations
If we have previous solution that took into consideration of object orientated principles, like Single Purpose, Open for extension close for alteration, Livskovs’ substitution principle, Interface segregation and Dependency injection, (SOLID). Depending on the nature of the requirement it would be easier to achieve the requirement than having a code base that did not subscribe to OOP, (less to change). Furthermore, if the requirement is pretty much greenfield starting with OOP would be a good way to invest and build blocks of components. In short: the number of changes is related to state of code base and if the requirement would mean new or existing code to be created/changed. It could also be argued that this makes the developers experience nicer too.
By rule of thumb: the fewer the changes required the less time the job is required in development. So, if there is an existing code base that is a nightmare and did not subscribe to OOP, then more changes, vice versa.
So, the first criteria:
Faster delivery is achieved through standing on good previous OOP code bases. This means less things having to be changed. If it is a greenfield or new approach, then smaller the change the faster the less time in development.
Second Point: Confidence
Suppose this is to say tests, tests and tests.
Question:
What tests are we actually concerned with?
These are tests that pertain to proving code behaves well and answers the business requirement. If we focus on these tests than we have the minimum to prove working code.
Two come into consideration:
1. Unit Tests
2. End to end (E2E) Tests
Unit test to prove that the class in question will behave as the developer expects.
E2E tests: scenario based, much like:
As a <Personna>
I want to <do something incredible>
So that < I can move onto the next thing in my life>
This proves the business requirement has been achieved or not. Typically, Selenium or other flavoured web drivers are used in conjuncture with test runners like Junit with Cucumber, CypressIO seems like a good offering from NodeJS land.
To answer: The cost of development
To get the costs down
The fewer the change the better, often driven through OOP and technical approach
Prove change is working as expected using minimal testing: Unit and E2E testing. This may require some setup for E2E
So overall, the cost of development at its basic form can be conceived as being proportionally with how many changes to be made with respect to technical complexity. The confidence should be the minimum which could be seen as unit tests with E2E tests. There are lots of other details that could enhance but not define the development costs.
