روزی روزگاری مهندس نرم‏افزار خوبی بود که …

کتاب Object-Oriented Reengineering Patterns از Serge Demeyer, Stéphane Ducasse and Oscar Nierstrasz در نوع خود کتاب جالبی است. در مقدمه این کتاب داستان خیالی را تعریف شده و پس از آن دیدگاه نویسندگان آن در مورد مهندسی نرم‏افزار بیان شده است. آوردن مقدمه کتاب از آن جهت مفید دانستم که در آن به چند مورد خیلی مهم اشاره شده است که در حالی که اشاره به ماهیت مهندسی نرم‏افزار و تفاوت ماهوی آن با سایر گرایشهای مهندسی دارد، در عین حال بیانگر موضوع بسیار مهمی است: راه حلهای ما هنوز جواب مسئله‏ای که با آن روبرو هستیم، نیست(کمی آهسته، کسی نشنود). این مسئله چیزی نیست جز تغییر و پیچیدگی.

A Fairy Tale

Once upon a time there was a Good Software Engineer whose Customers knew exactly what they wanted. The Good Software Engineer worked very hard to design the Perfect System that would solve all the Customers’ problems now and for decades. When the Perfect System was designed, implemented and finally deployed, the Customers were very happy indeed. The Maintainer of the System had very little to do to keep the Perfect System up and running, and the Customers and the Maintainer lived happily ever after.

Why isn’t real life more like this fairy tale?

Could it be because there are no Good Software Engineers? Could it be because the Users don’t really know what they want? Or is it because the Perfect System doesn’t exist?

Maybe there is a bit of truth in all of these observations, but the real reasons probably have more to do with certain fundamental laws of software evolution identified several years ago by Manny Lehman and Les Belady. The two most striking of these laws are [Lehm85a]:

• The Law of Continuing Change: The Law of Continuing Change — A program that is used in a real-world environment must change, or become progressively less useful in that environment.
• The Law of Increasing Complexity: As a program evolves, it becomes more complex, and extra resources are needed to preserve and simplify its structure.

In other words, we are kidding ourselves if we think that we can know all the requirements and build the perfect system. The best we can hope for is to build a useful system that will survive long enough for it to be asked to do something new.