Just seen the first lot of GDevCon videos and boy oh boy do they look professional. We (GDevCon Team) view professional videos as an important reward for presenting and pay quite a lot for Louis to do them for us.
Go check them out here, they will be available shortly.
Anyways something has been bothering me and it's another software engineering trope that I'd like to pick at....
You MUST provide a full set of requirements and changes later on are terrible, expensive and will cause over-runs!
I think this is an old-fashioned and unrealistic view, it also tells us something about the fragility of an architecture/framework or design.
In the real world you will not be provided with a full set of requirements, and any requirements you do get will very likely change. The best you can hope for is an overview and the most you can do is try and understand the problem your customer wants to solve.
If you accept my argument then you probably will agree that a good architecture addresses (even embraces) this reality. I'm not going to advocate a particular framework, architecture or design here, but I will give you a catchy phrase to help you evaluate them.
Fear of Change is a Code Smell!
Ideally change can be something you can configure, or something you can add. Also it will affect a small and limited area of your code. Small changes should only take a small amount of time and have a small amount of impact. The existing codebase should not unduly affect the work required to make the change.
Here Endeth the sermon
If you like my articles you may want to spend a day in the company of Fabiola De la Cueva, Joerg Hampel and I, we will be reprising our DSH Workshop at NIDays Europe, check it out here http://dsh-workshops.com/. Where else can you hear from 3 different companies experiences (>60 years in the industry), 2 published authors, 3 LabVIEW CLAs and Champions. It's a bargain!