Comments for Software Adventures http://www.ajantonov.com Just another WordPress site Tue, 14 Jun 2011 06:14:08 +0000 hourly 1 http://wordpress.org/?v=3.3.1 Comment on Thought Of The Day By Unknown Chinese Author by admin http://www.ajantonov.com/2011/05/05/thought-of-the-day-by-unknown-chinese-author/#comment-1098 admin Tue, 14 Jun 2011 06:14:08 +0000 http://www.ajantonov.com/?p=606#comment-1098 Recently, I found out for me what is TDD, and in some way it is related with the strategic approach which is used in the chess game from the biggest chess players as Kasparov. If you want to reduce the complexity, you just start from the target and go backward to you current position searching for the best decision. On this way you cut the complexity. Actually this is a strategic approach because you answer of answers like "what do you expect". In TDD there is also a rule that you should set your assert at the end of unit test and implement backward your decision which is the same! :D If I should say it briefly TDD is a perfect way to reduce the complexity. Recently, I found out for me what is TDD, and in some way it is related with the strategic approach which is used in the chess game from the biggest chess players as Kasparov. If you want to reduce the complexity, you just start from the target and go backward to you current position searching for the best decision. On this way you cut the complexity. Actually this is a strategic approach because you answer of answers like “what do you expect”. In TDD there is also a rule that you should set your assert at the end of unit test and implement backward your decision which is the same! :D If I should say it briefly TDD is a perfect way to reduce the complexity.

]]> Comment on Interesting Notes from “Agile Software Development, Principles, Patterns, and Practices” book by Stancho Stanchev http://www.ajantonov.com/2011/03/23/interesting-notes-from-agile-software-development-principles-patterns-and-practices-book/#comment-1079 Stancho Stanchev Tue, 24 May 2011 18:59:24 +0000 http://www.ajantonov.com/?p=548#comment-1079 classics... :) classics… :)

]]> Comment on Lean Principle “Never Fix Later!” by Stancho Stanchev http://www.ajantonov.com/2011/03/26/lean-principle-never-fix-later/#comment-1078 Stancho Stanchev Tue, 24 May 2011 18:57:43 +0000 http://www.ajantonov.com/?p=552#comment-1078 this depends too much by the context in which you work - if you work in context where this principle is accepted as law - you are right, but if you work in context where it will take too long to educate other people in this principle - especially if you have not administrative power to make this principle law - forget... :) this depends too much by the context in which you work – if you work in context where this principle is accepted as law – you are right, but if you work in context where it will take too long to educate other people in this principle – especially if you have not administrative power to make this principle law – forget… :)

]]> Comment on Proverb of The Day by Stancho Stanchev http://www.ajantonov.com/2011/04/04/proverb-of-the-day/#comment-1077 Stancho Stanchev Tue, 24 May 2011 18:52:28 +0000 http://www.ajantonov.com/?p=585#comment-1077 nice... :) nice… :)

]]> Comment on The Lean Thinking is The Life’s Thinking by Stancho Stanchev http://www.ajantonov.com/2011/04/26/the-lean-thinking-is-the-lifes-thinking/#comment-1076 Stancho Stanchev Tue, 24 May 2011 18:50:19 +0000 http://www.ajantonov.com/?p=601#comment-1076 The life and programming experience prove that this is really true - lean ans agile is state of the mind. Of course these can be trained and learned, but when someone understand the principles behind these words - he will start to apply these principles in other aspects of life too... :) The life and programming experience prove that this is really true – lean ans agile is state of the mind. Of course these can be trained and learned, but when someone understand the principles behind these words – he will start to apply these principles in other aspects of life too… :)

]]> Comment on Thought Of The Day By Unknown Chinese Author by Stancho Stanchev http://www.ajantonov.com/2011/05/05/thought-of-the-day-by-unknown-chinese-author/#comment-1075 Stancho Stanchev Tue, 24 May 2011 18:44:36 +0000 http://www.ajantonov.com/?p=606#comment-1075 Christopher Columbus does not followed this kind of thinking. Sometimes it is really better to start in some direction - like in iterative algorithms ... In some cases it is different to predict which direction is right. Unit testing is one of the methods which the programmers should use to see the right direction - at least "right direction from functional point of view"... :) Christopher Columbus does not followed this kind of thinking. Sometimes it is really better to start in some direction – like in iterative algorithms … In some cases it is different to predict which direction is right. Unit testing is one of the methods which the programmers should use to see the right direction – at least “right direction from functional point of view”… :)

]]> Comment on Rumbling : How to refactor existing code ? by admin http://www.ajantonov.com/2010/02/15/rumbling-how-to-refactor-existing-code/#comment-64 admin Fri, 05 Mar 2010 23:04:07 +0000 http://www.ajantonov.com/?p=133#comment-64 Ok, Stancho! I am agree with you but don't you think that the choice of time make us to build a house of straw ? I can't find the margin for my self ? Where is the margin between a house from straw and a house from bricks? What is the rule which we can use ? Ok, Stancho! I am agree with you but don’t you think that the choice of time make us to build a house of straw ? I can’t find the margin for my self ? Where is the margin between a house from straw and a house from bricks? What is the rule which we can use ?

]]> Comment on Rumbling : How to refactor existing code ? by Mike http://www.ajantonov.com/2010/02/15/rumbling-how-to-refactor-existing-code/#comment-63 Mike Wed, 24 Feb 2010 10:43:53 +0000 http://www.ajantonov.com/?p=133#comment-63 Stancho is correct: Smelly code base + Facades = "Bury the problem(s)" until there is time to fix things. Most often, time isn't allocated for this. A Facade then offers a cleaner interface plus more predictable behavior: fix the code that the Facade's features expose and you should have higher reliability over top of poorly written/architected code base. This does fall squarely in the "make it work; then make it work better" approach. This is a concept that more junior programmers don't understand so well. Either than want it perfect the first time (thus never releasing the work) or they get it working, call it "done" and never make it work better. More senior developers understand both parts of this two part rule and use it to advantage. (But beware the premature demo...) Until I write perfect software against perfect (written) requirements in a perfect environment, I'll continue to use this iterative principle of software development. Mike Stancho is correct:

Smelly code base + Facades = “Bury the problem(s)” until there is time to fix things.

Most often, time isn’t allocated for this. A Facade then offers a cleaner interface plus more predictable behavior: fix the code that the Facade’s features expose and you should have higher reliability over top of poorly written/architected code base.

This does fall squarely in the “make it work; then make it work better” approach. This is a concept that more junior programmers don’t understand so well. Either than want it perfect the first time (thus never releasing the work) or they get it working, call it “done” and never make it work better. More senior developers understand both parts of this two part rule and use it to advantage. (But beware the premature demo…)

Until I write perfect software against perfect (written) requirements in a perfect environment, I’ll continue to use this iterative principle of software development.

Mike

]]> Comment on Rumbling : How to refactor existing code ? by Stancho http://www.ajantonov.com/2010/02/15/rumbling-how-to-refactor-existing-code/#comment-62 Stancho Tue, 23 Feb 2010 14:09:33 +0000 http://www.ajantonov.com/?p=133#comment-62 Don't speculate ! "Time, quality, cost - choose two" paradigm drives the software development in these days. The cost and time are most important for people that pays for software development, so "cost and time" are chosen not by the developer, but the developer must deal with them and usually can not break them ! As this paradigm is wrong for software quality in most cases it is followed by other methods for achieving good software quality: - from the manager's point of view it is good to use "agile" software development methods and make the software system accessible ( and usable ) from the customer long before the system development is finished in it's whole - this is little "not very honest to the customer" principle during the development process, but with good organization of this process at the end both sides will be happy. - from the developer's point of view - "Release It !" is very important principle. "Make it work" and after that "Make it work better" and after that "Make it work intelligent way" and after that... If for the customer time and cost are so important the development will finish just with "Make it work" phase. After the customer has a usable working system it can decide to spend more time and money the system to became better. Software development is engineering process, so it is a process of compromises - the good developer knows ( predicts ) which compromises should be made. Regards, Stancho Don’t speculate !

“Time, quality, cost – choose two” paradigm drives the software development in these days. The cost and time are most important for people that pays for software development, so “cost and time” are chosen not by the developer, but the developer must deal with them and usually can not break them ! As this paradigm is wrong for software quality in most cases it is followed by other methods for achieving good software quality:

- from the manager’s point of view it is good to use “agile” software development methods and make the software system accessible ( and usable ) from the customer long before the system development is finished in it’s whole – this is little “not very honest to the customer” principle during the development process, but with good organization of this process at the end both sides will be happy.

- from the developer’s point of view – “Release It !” is very important principle. “Make it work” and after that “Make it work better” and after that “Make it work intelligent way” and after that…
If for the customer time and cost are so important the development will finish just with “Make it work” phase. After the customer has a usable working system it can decide to spend more time and money the system to became better.

Software development is engineering process, so it is a process of compromises – the good developer knows ( predicts ) which compromises should be made.

Regards,
Stancho

]]> Comment on Rumbling : How to refactor existing code ? by admin http://www.ajantonov.com/2010/02/15/rumbling-how-to-refactor-existing-code/#comment-61 admin Sat, 20 Feb 2010 16:30:48 +0000 http://www.ajantonov.com/?p=133#comment-61 Hi Stancho :D! You are right. But don't you think that we postpone the problem on this way ? Where is the border when we have to refactor the problem and when to bury the problem ? If I follow the Toyota Way practices I will stop and fix the problem. No matter whether it will take me a lot of time! These question make me think and make a research on the problem and write a new post. ;-) Hi Stancho :D ! You are right. But don’t you think that we postpone the problem on this way ? Where is the border when we have to refactor the problem and when to bury the problem ? If I follow the Toyota Way practices I will stop and fix the problem. No matter whether it will take me a lot of time! These question make me think and make a research on the problem and write a new post. ;-)

]]>