NYCPHP Meetup

[David Krings]

Elliotte Harold wrote:
> David Krings wrote:
>> mikesz at qualityadvantages.com wrote:
>>> too (security and quality never got any space on the project priority
>>> list obviously).
>>
>>  From my experience that is true for 90% of all software projects. 
>> Only documentation ranks lower. 
> 
> In my experience, quality arises from good development practices like 
> test-first programming, pair programming, proper object oriented design, 
>  internalization of coding conventions, DRY, and a host of other small 
> factors. It's not something you assign a time block to and put in later.
> 
I didn't mean it in a way of how much time gets allocated. I think it is 
reasonable to allocate as much time for testing as there is allocated for 
writing code, better even more since the testers have to check more than just 
the code, but also end-user documentation, sales literature, process 
descriptions, specs, docs for support, auxilliary applications, installation, 
and and and


> Programmers who write quality code do not write code slower than 
> programmers who don't. If anything they produce more lines of code per 
> day, and their code does more. Possibly, if you have an inexperienced 
> team just coming up to speed with good development practices, then 
> there's some training time to learn and internalize good coding 
> practices. Nonetheless, even if you have to spend two thirds of your 
> project schedule sharpening a dull ax, you will cut the tree down faster 
> than if you just start hacking away.

Nicely put. Quality code is one of the biggest savings potentials for a 
software company. If you are a carpenter and only have crappy tools and crappy 
material the hut you build will collapse sooner than later. The same mechanism 
apply to software. Nevertheless, I wittnessed many times what I call 
"developer arrogance" where writing quality code was not seen as a necessity, 
since "support can deal with it".

> Quality is not something you can accept less of to complete a task 
> faster. If you omit quality from your code, the project will take more 
> time to complete.

I disagree, you can take shortcuts, such as not documenting code and omitting 
anything other than the "how it is supposed to be used" path. One might argue 
that this would not constitute project completion, but when time and money are 
scarce for a software project the QA and doc team get cut and 'cheaper' 
developrs get hired to do the job. Typical behaviour in companies where 
shareholder value (short term gain) is valued more than product quality (long 
term gain).

Too bad that the coding team that crafted the broken code cannot read our 
discussion. I also think that at he origin of this thread the fact was well 
established that the code in question does not adhere to any higher quality 
standards. Which even makes my proposal more plausible: rip it out and do it 
the right way. Otherwise more fixing will be needed and the code won't get 
that much better.

David