You've chosen a wonderful topic... I won't point to specific URLs, but you will find a lot of information around software design/development best practices. You will quickly realize that this discipline is part science and part art (arguably, the latter is more important).
You are correct - OO, XP are not stand alone answers, but such methodologies do provide very good pillars to lean on.
And while there are well implemented COBOL applications, I would argue that OO does matter - 20 years of history tells us that an OO approach tends to yield more stable and maintainable systems when applied properly (and that's key!).
I believe the answers you seek are multi faceted - rooted in technology, approach, teamwork, management... discipline - what we do is often called a 'discipline'. There's a double meaning there.
I'll call out a few specifics:
1 - design/implement at the right levels of abstraction. Push complexity down to it's proper level. If 80% of a code base looks like pseudo code, a good job was done.
2 - Separation of concerns can't be over stated. Modularity is great, but only if each module minds its own business.
3 - Pick a language / technology whose expressiveness / facilities match the problem at hand... life will go a lot smoother.
4 - Only a project that takes refactoring seriously, and builds in the overhead for refactoring cycles will succeed in the long term, and yield an elegantly designed & implemented solution. Management that poo-poo-s such measures as wasteful play time is doomed to fail - in a business sense and in the context of your thesis.
5 - The team must work with a common mindset and apply principals intended to yield a system that has the qualities your thesis wishes to quantify.
I would strongly suggest - along with your other research - to take a breeze through "The Pragmatic Programmer" by Hunt & Thomas.
It's a must read.
Good luck with your project.
Would love to offer feedback as you proceed - feel free to ask - louis.iacona@verizon.net
-- Louis Iacona
Slashdot Mirror
You've chosen a wonderful topic ... I won't point to specific URLs, but you will find a lot of information around software design/development best practices. You will quickly realize that this discipline is part science and part art (arguably, the latter is more important).
You are correct - OO, XP are not stand alone answers, but such methodologies do provide very good pillars to lean on.
And while there are well implemented COBOL applications, I would argue that OO does matter - 20 years of history tells us that an OO approach tends to yield more stable and maintainable systems when applied properly (and that's key!).
I believe the answers you seek are multi faceted - rooted in technology, approach, teamwork, management ... discipline - what we do is often called a 'discipline'. There's a double meaning there.
I'll call out a few specifics:
1 - design/implement at the right levels of abstraction. Push complexity down to it's proper level. If 80% of a code base looks like pseudo code, a good job was done.
2 - Separation of concerns can't be over stated. Modularity is great, but only if each module minds its own business.
3 - Pick a language / technology whose expressiveness / facilities match the problem at hand ... life will go a lot smoother.
4 - Only a project that takes refactoring seriously, and builds in the overhead for refactoring cycles will succeed in the long term, and yield an elegantly designed & implemented solution. Management that poo-poo-s such measures as wasteful play time is doomed to fail - in a business sense and in the context of your thesis.
5 - The team must work with a common mindset and apply principals intended to yield a system that has the qualities your thesis wishes to quantify.
I would strongly suggest - along with your other research - to take a breeze through "The Pragmatic Programmer" by Hunt & Thomas.
It's a must read.
Good luck with your project.
Would love to offer feedback as you proceed - feel free to ask - louis.iacona@verizon.net
-- Louis Iacona