It does pose the question, how should these type of 'heated' discussion be handled. People who are passionate about their work, easily takes offence if their design approached are shot down. They then quickly get despondent and disruptive in the project/company, being sometimes very difficult to work with. People who do things buy the book...well will keep throwing the book at you. In turn they will start throwing the book to your/their superiors and so on until they feel they have acquired the desired attention. These situation has a habit of turning in your classic political games within project/company structures.
Methodologies followings these days also seem to more like religion than ever before. Agile, Domain Driven, Test Driven, RUP and so on. What i do find ironic about this, is that most of these development methodologies started out by intelligent professionals that felt existing methodologies did not work for them, so they came up with their own that fit their way of software development. The next logical step...sell it of as the best thing since slice bread. Now where these guys took their intellect and did something that worked the best for them, so why don't everyone one do it. Instead every software developer will meet a person whom swears by his chosen methodology and refuses to change or adapt it. Why the strict following? Is it because to deem yourself an "expert", promoting yourself about your peers? Or is it the blind devotion in a manner of doing things, with the expectation that everything will work no matter what solution your implementing.
At the end of the day is usually comes to two outcomes, everything works and everyone is happy...or the solution does not work, and the finger pointing and book throwing starts. What no one seems to realise, is there is no silver bullet way of building software solutions in the Java space. The only thing that a sane Java professional can do is to select frameworks and components in their solutions that give the most benefit for the current requirements. More importantly realise that as requirements change, that certain frameworks and components might fall out of favor and is simple not the best option for the updated requirements. Personally for me a good architect must always design for change, expect the unexpected and design solutions that can adapt with changing requirements and environments. Not to code into a framework, but keep a level of abstraction so that frameworks can be replaced with the least amount of effort and time.
[ add comment ] | permalink |
( 3 / 324 )
Calendar
