Unmaintainable code behind to the non-technical

Question

How would you explain to a non-technical person why writing code (business-logic) behind the onclick event is a bad practice and leads to unmaintainable code?

Edited: I have to explain management why some refactoring is needed, also why some code is not passing code review. To some people in management this only means more funding. I came up with this example because at some point of a discussion somebody said: ..put the code behind the button and forget all that model-view-controller hype, you will finish your task faster.

Answer 1

The reason I don't usually put the code behind the onclick event is because I'm often duplicating the code, and want all of those type of onclick events to call the same routine.

Answer 2

At least in those terms, you're not going to have any success explaining this to a non-technical person. It's too technical of a point.

If you generalize a little bit and perhaps try to explain something like sepeartion of concerns (not in those terms), you might have a little bit more luck

Answer 3

Why does a non-technical person need to know this? Since 'code style' really is a technical matter, you won't be able to explain it without explaining some of the technicalities behind it.

Probably the simplest explanation I can think of (but this does not cover all the reasons that it is bad-practice, just what I believe is the most common reason):

When writing software you strive to make it as maintainable as possible, this means being able to quickly adjust the application to changing user/client/management requirements. The code behind an onClick event will change whenever the GUI requirements change, the business logic code will change whenever the business requirements change. By making one independent of the other, there will be less work to do when either of these things change. Furthermore, when updating the business logic, you will not need to worry about how it ties into the GUI, and when updating the GUI you will not need to worry about how the business logic actually works.

The other main reason is re-usability. The GUI with all the buttons is really just a 'view' of the underlying data/an interface to that data. You may have several ways of accessing/changing the same information, and it would be redundant to replicate the business logic. This would also add complexity if the business logic changes, since you would have to change it in multiple places.

Answer 4

Because you would not connect the doorbell directly to the release buzzer.

Answer 5

With pictures and stories :)

Not to be too glib, but build a scenario on a white board where there is a simple piece of business functionality (change a user password). Illustrate graphically what it looks like. Now expand it so that 2 forms need to change the users password (admin and user) Double code! Explain DRY. Change the password complexity rules and now we need a double fix. Refactor the boxes to move the code to a common area in the same project.

Now expand it again where another app needs to do the same thing. Now a class library is better. Talk honestly about the increase in complexity vs the maintainability and resuse.

Rinse and repeat until it sinks in.

Answer 6

This is really speaking to separating business layer (how things are processed) and presentation layer (how things are displayed).

The rate of change and the reasons for changing the two are generally very different. You want to be flexible enough to change them, in response to changing business needs as easily as possible, in a manner that reduces risk (of regressions).

Answer 7

This is how I would explain it:

The difference between writing code behind onlclick events and writing applications that are tiered or layered is like the difference between a medieval town and a modern city.

In a medieval town, everyone plows it's field, everyone sews his clothes, builds his house and educates his children to the best of his abilities, no one is really specialized to do a task well they have to do all the tasks necessary for survival. This is what writing code behind onclick events is like, the code has to to everything, handle UI interactions, do business validations, handle database access, and this repeats for every event.

In a modern city there are farmers that practice agriculture at a larger scale and specialize in it, there are tailors that can sew better clothing for everyone because of greater experience and specialization, there are builders, there are teachers that teach children in schools and can do a better job at it because they have more time to do it. This is what writing a tiered application looks like, the UI tier is responsible for handling user requests and updating the user interface only and therefore is more easy to change replace or extend by having no extra code burden, the business tier is responsible for business logic and all the logic is centralized, reusable, the business logic code is more compact and clean, the data access tier handles database interaction and specializes in doing it possibly interacting with more than one type of database.

Writing code behind onclick events is a rudimentary style of programming that is not the most efficient style and doesn't yield the best possible results in the long run, although the results are more than often acceptable (the application works), it can work allot better, be easier to maintain and extend and be more consistent (regarding ui, interactions, error reporting, workflow, etc) by using a proper tiered design that employs good coding practices.

Answer 8

I have to ask like anyone else - why?

What matters to a nontechnical person is that the desired behavior is happening when the button is clicked. From their point of view, you are coding into the click event.

But if it really is an issue, focus on what the nontechnical people care about - BUGS. They don't care about making code elegant or having nice design patterns, etc. It's all about whether or not things work.

Say something like this:

Any business rules that have to be programmed into the system may need to be reused in many different places, like a report, a button, a search, etc. I might even need to use that same logic in a web page as well as the software package. You might think it's only going to be needed here right now, but experience has proven that most of the time business rules have to be used in more than one place and it is best to assume it will always be reused.

If I put the business rules behind the button directly, reuse of that logic can be difficult if not impossible. Then I have to put the same logic in the system more than once, which introduces more opportunities for mistakes. I could fix the logic in one place and it would still be broken somewhere else.

Instead, I take the business rules and put them in a central location so no matter where I need them I can reuse them. Then, a bug fix in one place is a bug fixed in all places, and the software will have fewer problems.

An analogy would be links on a webpage. Instead of copying all the text from a webpage into another webpage, we just make a link. Then we always have the most up-to-date information.

Just remember - nontechy people are pragmatic - it's all about what they can immediately see and use.

Answer 9

Tell your managers about technical debt (and also here)

I think you should convince your managers of the general principle, that refactoring or paying down the technical debt, is necessary once in a while. Just like a cook has to clean its kitchen once in a while in order to make good food, you have to clean up your code once in a while before you can implement new features.

If your managers don't agree with this general principle, then you're in big trouble. If they do agree, then I think they should not micromanage you but trust your technical expertise on what kind of refactoring has highest priority.

Answer 10

Economics

3/4 of the total life-cycle costs of a typical software application are maintenance. By skimping on the 1/4 part up front you load the 3/4.

Skimp of the development enough and the 3/4 becomes 19/20. Do it properly and your $100,000 project costs $400,000 over its lifetime. Skip on TLC up front and you save $20,000 now but your project costs $2 million over its life time.

If the CFO is in the meeting you could drop a comment along the lines of:

'But don't worry, the extra $1.5m will come out of someone else's budget so it won't affect your bonus.'

The other hidden cost of leaving a mess lying around is the bit rot will massively slow down changes on the application and increase the risk of undetected bugs that nobody notices until they're right in the middle of a month-end close.

Answer 11

ConcernedOfTunbridgeW explains it well in terms of what management wants to hear. Main point is that if it has problems right now, it probably is because of redundancy of code logic. The refactoring you want to do will eliminate that. It will cost a little more in the long run, but it will save money in maintenance long-term.