casper

Unregistered less info
99 reputation
2
bio website
location
age
visits member for 2 years, 3 months
seen Feb 8 '12 at 10:29

Feb
8
comment How to keep a big and complex software product maintainable over the years?
@Kevin: Well if you are able to understand open/closed in the abstract "for the future" sense that you do here, then sure: All code should really be made in this way, even internal code. I have made it a habit to always follow the design guidelines for frameworks, even when I make an application. This however is not the definition of open/closed, as it reads in answers on this post, nor as it is defined on wiki: [the open/closed principle states "software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification"]
Jan
12
comment Is CodeFirst intended for large scale applications?
We added an extension library for our, very large, project that allows us to annotate indexes on the code-first entities - works great and was relatively easy to make.
Jan
12
answered Is CodeFirst intended for large scale applications?
Jan
12
answered Is Entity Framework ready for production?
Jan
12
answered Is Entity Framework Code First a bit meaningless/useless in production and what is a good EF strategy for production?
Jan
12
answered Is Microsoft's Entity Framework a proprietary variant of NHibernate?
Jan
12
comment Is it ok to call external services or database inside the entity
At least make sure that you late bind the service urls, meaning that you do not save them in the db. Also make sure that you save some sort of indication of version and definition of the service you want to call in the db. This will help you in the long run, as the coupling will at least be described.
Jan
12
comment How to keep a big and complex software product maintainable over the years?
Its a good idea to have one person being the root responsible for architecture. However you have a "team-smell" if that responsibility is used often: The team should naturally come to common conlusions, instead of relying on one person to provide the answers. Why? The total knowledge of the project is always shared, pinning it on one person will lead to bigger problems in the end: Only his view is satisfied, effectively cutting the wings of the rest of the team. Instead hire the best people and let them work it out together.
Jan
12
comment How to keep a big and complex software product maintainable over the years?
"Disagree with #10 - that helps with code quality if done correctly" This is absolutely false in my working experience: Code locked away cannot be refactored, meaning it will be staying in its current state until unlocked. This state can be verified to be working at some stage, but at a later stage this verification is a false positive: All code should be left open for refactoring up until the stage before final system test.
Jan
12
comment How to keep a big and complex software product maintainable over the years?
"Disagree with #3. Testing should not be seen as a punishment for the untrained." - It shouldnt and is not what I wrote, let me explain: Testing is a good way of letting people who you do not, yet, trust to commit changes to get into he code. The best testers I have found are the ones aspiring to become contributors of code and are proving their competency by looking through code, running the programme and shows the ability to correlate their findings in the runtime with the source code. It is not a punishment - its training.
Jan
12
comment How to keep a big and complex software product maintainable over the years?
"Now, what would you do if you had to maintain and enhance a nightmarish 12 year old VB6 app" - Rewrite full time or Reapply for new job.
Jan
11
awarded  Nice Answer
Jan
10
awarded  Teacher
Jan
10
answered How to keep a big and complex software product maintainable over the years?