Agile Life

흔히 이젠 잊었어 그래서 아무렇지도 않아 말한다. 전에는 평생 잊지 못할 사건이었고 인생의 모든 걸 결정하는 분기점이었던 사실들이 시간이나 상황이 지나면서 무덤덤해졌을 때 하는 얘기이다. 하지만 웬지 일부러 괜찮다고 말을 하는 것은 아직 잊지 못하고 있다는 자각증세이다. 아마 정말 잊었다면 그런 말 조차도 나오지 못할 정도로 기억의 저 뒤안편에서 수북한 먼지 속에 이미 그 모습을 잃어가고 있을테니까.

혹은 이렇게 묻혀있던 정말 잊었던 사실들이 어떤 계기로 불거져 나왔을 때, 이걸 다시 파묻으려는 주술이 바로 '이젠 잊었어, 아무렇지도 않아' 일 것 같다. 지금 누리고 있는 이 익숙해진 사실과 서로 충돌하는사실들이 다시 떠오를때 우리는 이 주술을 읊조리게 된다. 그 충돌이 심하여 아픔이 되기 때문에 애써 잊어진 사실들을 다시 묻으려는 것이다.

어쩌면 옛날의 진실들이 잊혀질 수 있는 건 그러고 싶은 나의 의식에 의해서가 아니라 지금 현재 진실이 더 다급하고 중요해지면서 서서히 그 설 자리를 스스로 잃어가는 것이 아닌가 싶다. 따지고 보면 내가 잊고 싶다고 해서 잊어질 수 있는 것들은 없어보인다. 우리의 마음이 그리고 정신이 그렇게 움직이지 않기 때문이다.

This article is incomplete; it will be constantly in editing mode.

The seasoned developers know that it is not easy to conduct OOP. The process of domain model analysis is non-disciplined; it mainly relies on the intuition or the experience from the past--the pattern language. The OOD is great tool for implementing the 'Solution', not for simulating the real world. The pitfall of the OO developers is that they cry for the classes with that they can initiate their development, but there are no easy way to get them without vigorus up-front efforts to model the static class digaram. This practice is usually expensive. And the bad news is the output from this practice will be very volatile and it requires the high cost to change them later in the development phase. This fear of future change causes even more delay on this domain model analysis.

The reason why OOP becomes hard is because developers think that their class must somehow simulate the real world, and it is neither achievable goal nor worth it. We must shift our mindset from the simualation of reality to the application of the 'Solution'. The 'Solution' is the virtual entity and the ultimate outcome of given programming job. Once whatever the 'Solution' is defined, OO designers put the OOP tool into an action only to implement the 'Solution'. This 'Solution' first approach resembles the very purpose of the Use Case Dicipline; it will show the concrete class objects that is needed immediately. 

This way developers will quickly get any classes that they can use in the very contained scope of functionalities. They are more likely the mechanical piece of the 'Solution', not the conceptual entity of the domain. The changes are minimal and manageable within the limit. But we still need domain entity for the better depiction of our 'Solution'. Can the business entity be so simple, yet adapt to the changes? This question leads us to the next subject--Agile Domain Modeling.

• Architect is Solution Engineer, not Software Engineer.
• What is exactly the 'Solution'?

I cannot recall where I did get this image.  
---------------

Software Engineer로서 개발 방법론에 대해 끊임없이 고민할 때 행복하다고 생각해야 한다. 자기 일에 고민할 문제가 있음을 인식한다는 것은 자기가 그 일을 즐기고 있다는 증거이다. 이제껏 해오던대로 타성에 젖지 않고 깨어있는 자신을 자랑스러워 해야한다.