Comments for Software Adventures http://www.ajantonov.com Developers do not do this at home! Tue, 01 Jun 2010 07:48:07 +0300 http://wordpress.org/?v=2.8.4 hourly 1 Comment on Thought of the day by David Parnas by Stancho http://www.ajantonov.com/?p=223&cpage=1#comment-262 Stancho Tue, 01 Jun 2010 07:48:07 +0000 http://www.ajantonov.com/?p=223#comment-262 ... but "cut and paste" is kind of refactoring... ;) … but “cut and paste” is kind of refactoring… ;)

]]> Comment on The Guerilla Tactics In The Software Development. by inerty http://www.ajantonov.com/?p=162&cpage=1#comment-251 inerty Wed, 28 Apr 2010 21:15:45 +0000 http://www.ajantonov.com/?p=162#comment-251 promotion sounds good yeah promotion sounds good

yeah

]]> Comment on The Guerilla Tactics In The Software Development. by inerty http://www.ajantonov.com/?p=162&cpage=1#comment-250 inerty Wed, 28 Apr 2010 21:02:56 +0000 http://www.ajantonov.com/?p=162#comment-250 I'm thinking of new "Almost a whole day taking extremely heavy task" called run the f**kin' IDE I’m thinking of new “Almost a whole day taking extremely heavy task” called run the f**kin’ IDE

]]> Comment on The Guerilla Tactics In The Software Development. by admin http://www.ajantonov.com/?p=162&cpage=1#comment-249 admin Tue, 27 Apr 2010 13:30:58 +0000 http://www.ajantonov.com/?p=162#comment-249 It's better to throw a hand grenade instead a dust ! :D :D :D It’s better to throw a hand grenade instead a dust ! :D :D :D

]]> Comment on The Guerilla Tactics In The Software Development. by admin http://www.ajantonov.com/?p=162&cpage=1#comment-248 admin Tue, 27 Apr 2010 13:30:06 +0000 http://www.ajantonov.com/?p=162#comment-248 :D :D

]]> Comment on The Guerilla Tactics In The Software Development. by martinez http://www.ajantonov.com/?p=162&cpage=1#comment-247 martinez Tue, 27 Apr 2010 13:29:02 +0000 http://www.ajantonov.com/?p=162#comment-247 "Do you think it’s reasonable to loose almost a day for talking with all possible managers and do stupid actions like this with organization of the Trac, when you don’t have enough time to prepare the mockups?" - One of the simple rules of the people doing NOTHING - Always appear busy ... That is not guerila practice - that's just a dust in the management eyes. so the guy decare - I do not want to do that - I have many more ideas and I'm interested in something different. So ... If your management is desorganised, and unresponsible, also doesnt have any idea what the teams really do ... than ... you do not need anymore analysis - you need a promotion, or a new company ... “Do you think it’s reasonable to loose almost a day for talking with all possible managers and do stupid actions like this with organization of the Trac, when you don’t have enough time to prepare the mockups?” – One of the simple rules of the people doing NOTHING – Always appear busy … That is not guerila practice – that’s just a dust in the management eyes. so the guy decare – I do not want to do that – I have many more ideas and I’m interested in something different. So … If your management is desorganised, and unresponsible, also doesnt have any idea what the teams really do … than … you do not need anymore analysis – you need a promotion, or a new company …

]]> Comment on The Guerilla Tactics In The Software Development. by Darky http://www.ajantonov.com/?p=162&cpage=1#comment-246 Darky Tue, 27 Apr 2010 11:42:48 +0000 http://www.ajantonov.com/?p=162#comment-246 The "ask the world" tactics is my favorite - just like the Heineken's ad "... and now we wait !" http://www.youtube.com/watch?v=x_iPvUWyzhE The “ask the world” tactics is my favorite – just like the Heineken’s ad “… and now we wait !” http://www.youtube.com/watch?v=x_iPvUWyzhE

]]> Comment on Rumbling : How to refactor existing code ? by admin http://www.ajantonov.com/?p=133&cpage=1#comment-230 admin Fri, 05 Mar 2010 23:06:46 +0000 http://www.ajantonov.com/?p=133#comment-230 Mike, how could you define "premature demo" ? ;-) Mike, how could you define “premature demo” ? ;-)

]]> Comment on Rumbling : How to refactor existing code ? by admin http://www.ajantonov.com/?p=133&cpage=1#comment-229 admin Fri, 05 Mar 2010 23:04:07 +0000 http://www.ajantonov.com/?p=133#comment-229 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/?p=133&cpage=1#comment-227 Mike Wed, 24 Feb 2010 10:43:53 +0000 http://www.ajantonov.com/?p=133#comment-227 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

]]>