[dba-Tech] The dark side of programming craftmanship

 Hi Jim --

<<<
"Quality, Speed, Price: Pick any two"
>>>
Yes, I know, but that's not a complete statement: as you know Quality, Speed and Price form a "decision triangle" and a developer's and their customers task is to find a point within this triangle - the most suitable balancing point for a given context.

<<<
Thank you, I will read through you links as so as possible.
>>>
Read it as "Quality, Speed, Price: Pick any two" is an "old song".

Thank you.

-- Shamil

Вторник, 29 января 2013, 13:51 -08:00 от "Jim Lawrence" <accessd at shaw.ca>:
>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
>
>
>_______________________________________________
>dba-Tech mailing list
>dba-Tech at databaseadvisors.com
>http://databaseadvisors.com/mailman/listinfo/dba-tech
>Website:  http://www.databaseadvisors.com