Jim Lawrence
accessd at shaw.ca
Tue Jan 29 15:51:43 CST 2013
Hi Shamil: Thank you, I will read through you links as so as possible. Before reading though I wish to make an observation. A lot of work quality is based on three things and those three things are for the most part client driven. Those extenuating factors are amount of payment, speed of completion and quality of work. Except with larger clients, the amount to be paid and the speed of completion are the most important factors; many forget that without sufficient time and the associated money, quality, can not be maintained. How many times clients have complained about the costs but have been blissfully unawares of how really crappy their business applications are. They are the victims of a process is called, "Paint the Pig". It may look pretty but under the pretty surface the application is really ugly and to fix anything, the program almost needs to be completely redone. As said many times before, in business, it all factors down to a simple rule: "Quality, Speed, Price: Pick any two", as no client can have all three. Jim -----Original Message----- From: dba-tech-bounces at databaseadvisors.com [mailto:dba-tech-bounces at databaseadvisors.com] On Behalf Of Salakhetdinov Shamil Sent: Tuesday, January 29, 2013 8:55 AM To: Discussion of Hardware and Software issues Subject: Re: [dba-Tech] The dark side of programming craftmanship Hi Jim -- The article is good, thank you. For me a "software craftsmen" are the ones who are able to incur and handle/balance the technical debt the most effective way whatever size of software application (system) they are working on and whatever working context/environment they are operating in: "alone wolf", small soft-dev shop, middle- or large soft-dev. company. "Technical debt" term was first introduced by Ward Cunningham in 1992(!) - http://c2.com/doc/oopsla92.html - but it has got mainstream approval AFAIS only in the middle of 00-ies thanks to Martin Fowler ( http://martinfowler.com/bliki/TechnicalDebt.html ) and others works coming from broad experience of everyday software development practice. Technical debt can be *introduced unintentionally* or *incurred intentionally* ( http://blogs.construx.com/blogs/stevemcc/archive/2007/11/01/technical-debt-2 .aspx ) - I'm mentioning here *intentionally incurred technical debt*. To effectively handle technical debt modern software development has got practical methodologies, the most important in my opinion are eXtreme Programming practices (Kent Beck, http://en.wikipedia.org/wiki/Extreme_programming_practices ) from which - relatively small development iterations planning based on business value; - test-driven development and - coding standards are the main three practices, and tools as e.g. Resharper ( http://www.jetbrains.com/resharper/ ). In any event - "a mess is not a technical debt" - https://sites.google.com/site/unclebobconsultingllc/a-mess-is-not-a-technica l-debt . (Although what is "the real mess" - opinions vary significantly.) Thank you. -- Shamil Понедельник, 28 января 2013, 19:52 -08:00 от "Jim Lawrence" <accessd at shaw.ca>: >As a programmer, my work quality (not functionality) falls into all sort of >categories. > >Sometimes, it is a rush to crank out code that I will be loathe to admit to >and other times in long term contracts, the code is a "thing of beauty". All >quick hacks and mashups and eloquently designed code has put food on table. > >Here is an interesting article on that subject (PS there is also a beautiful >Japanese parable that puts our coding into perspective.): > >http://www.javaworld.com/community/?q=node/8649 > >Jim > >_______________________________________________ >dba-Tech mailing list >dba-Tech at databaseadvisors.com >http://databaseadvisors.com/mailman/listinfo/dba-tech >Website: http://www.databaseadvisors.com _______________________________________________ dba-Tech mailing list dba-Tech at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/dba-tech Website: http://www.databaseadvisors.com