Today a new trainee was assigned to me. He just completed his in-firm training in another company and applied for a job.
In order to find out what he knows, I thought it would be a good idea to go through the code of some tools.
We began with a tool that prints invoices. It has two Forms and no architecture at all. Although the code was a mess, he could easily tell how it worked.
After that, we looked at a tool that queried some data, applied some validation to it and if necessary corrected it. This tool used the command pattern for validation / correction and loaded those commands via reflection (about 50 in total). It was way harder for him to tell what was going on. He asked why anyone would do things this complicated and suggested to use a switch block instead.
The third tool was a little more complicated, the UI used the passive view pattern, persistence was dealt with by NHibernate, StructureMap wired it all up and a test suite covered most parts. I wrote it some time ago but could still easily navigate through it as it was well structured but he was totally overwhelmed and unable to say anything other than “it is too complicated”.
Using these good practices has advantages but these advantages are not free.
There are way more developers like my trainee that never heard about good practices and the like than those who heard about these practices let alone applying them. These developers usually just want to get the job done and mostly they do so, on time.
If you work in a very small IT department that only deals with in house stuff, should you use patterns, unit testing and other good practices or should you just do it “the good old way”?
If you do it “the good old way” maintenance costs increase, time to bug fix / feature are less predictable yet everyone should be able work with it.
If you use good practices, maintaining your applications either can’t be done by every “developer from the street” or requires high upfront learning effort. On the other side, after this initial learning phase is over, the maintenance costs should decrease and time to bug fix / feature should be more predictable.
Is applying good practices always good? | Coding Efficiency…
Thank you for submitting this cool story – Trackback from DotNetShoutout…
If good practice doesn’t gain any advantage this isn’t good practice
. It is anti-pattern (http://en.wikipedia.org/wiki/Anti-pattern)
I think you always should do things better. Every(?) developer at his first met with computer was looking for ‘any key’. So it’s nothing wrong with that. But trainee doesn’t have an experience so he thinks that if something ‘just works’ makes job done. But after half a year, an application must be improve – he looks at this code, and copy-and-paste a lot of code. And after another half a year he does it again OR he rewrites whole application. In the first case, he should though about his vocation, but in the second, he can see what mistake he does in the past. And do things better. So always try to be the best. And at the end, listen to Uncle Bob
http://www.hanselminutes.com/default.aspx?showID=189
@RredCat
The problem is, those who don’t know the used patterns won’t see any benefits, just added complexity.
@matma
This trainee has already completed his in-firm training, thereby already worked 3 years for another company (in germany, the in-firm training takes 3 years).
The real problem is, he doesn’t give anything about good software design and is in that regard like the majority.
About the rewrite: It’s very rare that a rewrite leads to better design, usually it just delays the time until a new rewrite is “required”.
Patterns over-using is also bad idea.In some point your consultant was may be right (you told us almost nothing about these apps and I don’t know design decisions you have made) – if your application is small, it does one easy little thing then you can keep it simple. I have seen over-patterned applications where application with two forms has about 50 classes just because “it is the correct way”.
I think patterns should be used carefully. As soon as you try to rape your code to follow some patterns (something seems like some known pattern but it really isn’t, see my example here http://weblogs.asp.net/gunnarpeipman/archive/2009/07/17/entity-framework-4-0-on-the-way-to-composite-pattern.aspx) then sooner or later troubles start because code that is written just to follow the pattern needs also testing and maintenance.
Don’t get me wrong, I think that patterns are very useful. But I also think that they are like electricity – it helps smart ones and kills fool ones.
@Gunnar
Absolutely right.
Pattern overuse is actually worse than not using any patterns at all.
About your point with 50 classes and just two forms, well that’s almost the case with the second application, each of these commands is a class. Though, if you’d rip out the command pattern and do it with a switch block, it wouldn’t only be ugly but really error prone.
If you code towards the top 20%, then your code will need to be maintained by the top 20% (and all that that entails, both good and bad).
Interesting dilemma!
Certainly use of good practices is to be applauded. Use of standard patterns, where not overused as already mentioned, should be considered a good thing. However, it does throw up the problem of developers who are unaware of the patterns. Not only does this mean that such a developer will not understand the software easily, it runs the risk that he/she will cause damage to the structure of the code when maintaining it by “just adding a quick patch”.
It comes down to training and mentoring and ensuring that new devs are fully up to speed with your development house’s practices before letting them loose on the code. With ever-increasing workloads this can be a problem however.