Page 106 - DCAP405_SOFTWARE_ENGINEERING

Unit 7: Software Engineering Practice

Things such as Test Driven Development, Domain Driven Design, Behavior Driven Development, Notes
proper adherence to the SOLID principles, etc. are all practices that you would expect at the
mature end of the spectrum. At the other end of the spectrum would be the quick-and-dirty
solutions that are done using something like an Access Database, Excel Spreadsheet, or maybe
some quick “drag-and-drop coding”.

We believe there is a time and a place for projects at every part of that SEMS. The risks and costs
associated with under-engineering solutions have been written about a million times over so
we won’t bother going into them again here, but there are also (unnecessary) costs with over-
engineering a solution. Sometimes putting multiple layers, and IoC containers, and abstracting
out the persistence, etc. is complete overkill if a one-time use Access database could solve the
problem perfectly well.
A lot of software developers we talk to seem to automatically jump to the very right-hand side
of this SEMS in everything they do. A common rationalization we hear is that it may seem like
a small trivial application today, but these things always grow and stick around for many years,
then you’re stuck maintaining a big ball of mud. We think this is a cop-out. Sure you can’t
always anticipate how an application will be used or grow over its lifetime (can you ever??), but
that doesn’t mean you can’t manage it and evolve the underlying software architecture as
necessary (even if that means having to toss the code out and rewrite it at some point…maybe
even multiple times).
Our thoughts are that we should be making a conscious decision around the start of each project
approximately where on the SEMS we want the project to exist. We believe this decision should
be based on 3 factors:
1. Importance: How important to the business is this application? What is the impact if the
application were to suddenly stop working?
2. Complexity: How complex is the application functionality?
3. Life-Expectancy: How long is this application expected to be in use? Is this a one-time use
application, does it fill a short-term need, or is it more strategic and is expected to be in-
use for many years to come?
Of course this isn’t an exact science. You can’t say that Project X should be at the 73% mark on the
SEMS and expect that to be helpful. Our point is not that you need to precisely figure out what
point on the SEMS the project should be at then translate that into some prescriptive set of
practices and techniques you should be using. Rather our point is that we need to be aware that
there is a spectrum, and that not everything is going to be (or should be) at the edges of that
spectrum, indeed a large number of projects should probably fall somewhere within the middle;
and different projects should adopt a different level of software engineering practices and maturity
levels based on the needs of that project.

LOVELY PROFESSIONAL UNIVERSITY 99