General discussion

Locked

A Blog by a mere developer.

By Tony Hopkinson ·
Tags: Off Topic
blog root

This conversation is currently closed to new comments.

34 total posts (Page 1 of 4)   01 | 02 | 03 | 04   Next
| Thread display: Collapse - | Expand +

All Comments

Collapse -

Is quality a casualty of doing business ?

by Tony Hopkinson In reply to A Blog by a mere develope ...

<strong>Writing Quality Software Applications<br /><br /></strong>
<p>If you are in the business of writing software, either commercially or for open source. What constitutes quality ?</p>
<ul>
<li>Ease of use ?
<li>Applicability of the functionality ?
<li>Integration, Interoperability or compatibility ?
<li>Stability or robustness ?
<li>Security ?
<li>Speed and resource economy ?</li></ul>
<p>The split in the list was deliberate, as a developer, designer, programmer, solution provider or whatever, the lower three I can have an impact on by writing quality code. The first three are aspects of the requirement. Can I have an impact on them, well I can do what was asked properly and hope the market research boys got it right. I can point out inconsistencies, impracticalities, even impossibilities, but they should change the requirements before they change the design and implementation.</p><br />
<p>The point I'm going to try and get across is that quality applications are much easier to achieve and far less expensive in the long run if they are made with quality code. That's obvious you say, well you must be a quality developer. Evidence suggests it's far from obvious to some.</p>
<p>What is the first casualty in the development process when things start getting tight? Quality, poor fellow is always the first one over the top and gets scythed down by short term business imperatives or over clever technical types, every battle. Talking of war, heard the quote, "No battle plan survives contact with the enemy", well no software survives contact with a user. They will use it in ways you never planned on, in situations you never considered, at times you'd think were insane. The one constant in life, software and the universe is change.</p><br />
<p>Hence the critical factor missing off the above list -:, <strong>Quality sofware can be adapted</strong>.<br />It must be, it's never finished, a release is simply a hopefully working subset of a range of functionality that might be required, by someone, sometime.</p><br />
<p>Interfaces can be enhanced, even added. Resources can be pooled, expensive routines can be optimised, security can be added, stability improved, features enhanced or added, integration broadened or made deeper. When are at least some of these, not desirable features of an application ? When can't they be marketed, when can they not be profited from ?</p>
<p>So, the business point made, though not necessarily proven, what is the key component of a quality application that a devloper can impact, Quality code. Not an upgraded OS, not better hardware, not killing competition so you don't have to bother, not constraining functionality so it doesn't matter, not even quality developers. These are all short term measures, every one of them is guaranteed not to last, because change is a given and they are all enviromental.</p>
<ul>
<li>OS's are software, subject to exactly the same problems as applications, though to a much greater degree.
<li>Hardware always becomes obsolete.
<li>Corner the market, you just give someone a more lucrative target to aim at.
<li>Throw quality in the bin and you give them an easier target as well.
<li>Throw functionality in the bin, you won't hit the target, become obsolete before you put the lid back on the rubbish receptacle.
<li>Quality developers, well they get moved into management, their skillsets become obsolete, they leave to work for someone who told them quality IS important, they leave and then charge you an arm and a leg for their services, they retire, they switch to flipping burgers because they are only glorified clerks after all.</li></ul><br />Quality code though, lasts. It can survive anything short of a nuclear explosion, even that if your offsite back up is very remote. If it's the real driver, it can even survive low quality developers, even better, make them into higher quality developers.<br />
<p>How many times has this happened. We'd like to add feature X to software Y. X is a natural extension to Y, it's very similar from the outside, should be simple. The response, well we could give you a bit of X sometimes, if you don't mind having Z, in a month, or you are looking at a total rewrite and next year.</p><br />
<p>Now this could be for several reasons, but in my experience, most of the time it's because the code base is of a low quality, more commonly known as, crap.<br />How did it get to be crap ? Well it either started as crap, or cpl Quality got shot down too many times in a row. More generally the latter.<br />After all the 'easiest' way to deal with a code base that is hard (expensive) to change is to bodge, patch, snowball, spaghetti and poorly interface to other crap. It's probably a total co-incidence but all these 'ah' procedures actually result in an even lower quality code that's even harder to change.<br />Guess we must be doing something wrong huh ?</p><br />
<p>This is not a diatribe against those stupid business types who don't understand technology. Of course they don't, that's what we are there for. Some might, some could, some do, but it's not their job, it's ours. They aren't stupid, they just aren't technical. Well OK some do appear to be stupid, but I've met as many stupid techs as I have business types.</p><br />
<p>Now some of our problems are down to communication failures, either we didn't explain, didn't explain correctly or just as bad didn't make sure we had been understood. Sometimes business types will simply stumble over technical hurdles in order to hit the finishing tape. Like when something has already been promised, what was promised was changed by someone important, an unfortunate error in the costing, a massive change in the business environment and the oft quoted "What do you know you are a mere tech".</p><br />
<p>There are a whole raft of other reasons for a low quality code base though, ones that over a product or even a version lifetime our non-technical colleagues would judge themselves benefitted by. These things are generally so basic, it makes you want to cry at their absence. The only reason we don't, is because we are so badly dehydrated.</p>
<p>How do you write code that you can change with relative ease? </p>
<p>You write code that you can read with relative ease.</p>
<p>You write code that "does what it says on the tin".</p>Annotation, naming conventions, function length, prettification styles, calling conventions, coding standards, documentation, continuity, all things that help you read what is already there.<br />
<p>If you can't read a piece of code , you can't understand it. <br />If you can't understand it, you dare not change it. <br />If you daren't change it and you can't afford to rewrite it, then you bodge, patch, snowball, spaghetti, screw up or otherwise fail. </p>
<p>A higher quality, less expensive bodge is not what we are meant to be about!</p>If you see a piece of readable code that suits your needs, does only what it says and you understand how it works, you are going to re-use it. 99% of business coding is plagiarism after all. Why would you write something that you'll have to prove works, when you already have something that is proven to work?.<br />
<p>If you have to add an other routine to do something similar, you aren't going to invent a new way of doing it, you'll cut and paste, have a wee twiddle and be more confident about what you've done. <br />Not only is the end result of a higher quality, it's quicker to produce !. It's cheaper, it gives you more time on the harder bits. It's easier to test, it's less likely to have a coding bug, it's more stable, it's more rewarding.</p>
<p><strong>Why aren't we bloody doing it then ?</strong></p>
<p>Oh yes I include myself, for one reason or another I've put my name to as many bodges as you buggers.</p>We are not talking rocket science here, not fuzzy neural network self programming AIs. We are talking invoice total, print, save, export to csv. Basic building blocks for an application, if you build a house with crap bricks, you get a crap house. A house is a very complex piece of engineering built out of extremely simple (<em>at some perspective</em&gt bits of engineering. Programming is not dropping a button on a form in an IDE, it's not agile, it's not UML, it's not C#, Pascal or any other language. It's taking a complex requirement and breaking it up into easy to understand bits !<br />
<p><strong>How can it be easy to understand, if you can't bloody read it ?</strong></p>
<p>My favourite example</p><pre>int function IsNotBanded(int ProductID);
{
prodStruct prod; // Product to be tallied

If (GetProduct(ProductID))<br /> {<br /> If (Prod.NotBanded != 'N' ) // test the tally flag
return TRUE
else
return FALSE;
}
}

..... If !IsNotBanded

....Argghhhh !!!</pre><br />
<p>If you are confused by the references to tally, well it's because some lackwit cut and pasted this routine from a similar one, IsTallied ! </p>
<p>Also Getproduct can only succeed, because otherwise calling the function would be daft wouldn't it. </p>
<p>This will seem strange but in the next version, someone misinterpreted this code resulting in several productions delays running in to ?1000s in lost profit. <br /><br />The input screen where the flag was set was as follows</p>
<p>Banded - X (Y/N)<br /><br />Can't imagine how the confusion arose, I mean everyone would do it like this would n't they ?<br /><br />No it wasn't me, I did the spectacular bodge that fixed the fault, we were losing our production bonus! It was still there six years later when we rewrote, not after though.<br /><br /><strong>Glossary of terms<br /></strong></p>
<ul>
<li>Bodge - a permanently temporary fix to a bug.
<li>Code base - the source for all your applications, be it VBScript or C
<li>Crap - excrement
<li>Low Quality - cheap *** crap
<li>Patch - a temporarily permanent fix to a bug
<li>Quality - A once rare animal, now extinct. Though there have been unsubstantiated claims of it's continued existance by various software producers. These are immediately recognisable, they have smarmy grins, bulging wallets and their hands outstretched for more.
<li>Total rewrite - the far too expensive alternative to the existing crap.
<li>Snowball - Roll a ball of bad code in some good code resulting in a larger ball of bad code.
<li>Screw up - a failure to notice that this once crap code is called by another piece of crap code, that relied on how crap it was.
<li>Spaghetti - get some bad code to call some more bad code resulting in the right answer this once and at least two wrong answers next time. </li></ul>

Collapse -

Is quality a casualty of doing business ?

<p>Tony -</p>
<p>Good post. I love that code example. The very first mistake the writer made was calling it "IsNotBanded". "IsBanded" is a much simpler method to be dealing with; I try my best to never write negatives into my Booleans, because code that is filled with double negatives is impossible to maintain. !IsNotBanded indeed...</p>
<p>To quote the film <em>Under Seige</em>: "... coming up with last minute solutions to impossible problems that someone else created." This is a great description of most of the projects that I get to work on. Architecting a solution? Who has time for that when you're given a 2 day deadline? Interoperability, testing, exception handling, validation, optimization? Sorry, the customer forgot to ask us to do the project until 5 days into a 7 day deadline. Managers also seem to treat coders as multicore CPUs. They think that we can just run our little development process, and the moment something blocks progress, instantly switch to another project and back to the original as soon as that thread wakes up again. It does not work like that. When I am in the middle of working, there are huge costs for context switching. If I have to wait three days to get the specifications for data validation from the business analysts, it is not like I can just pick up where I left off without having to review where I was...</p>
<p>Quality code is far too often sacrificed on the altar of deadlines. This is an age old, unresolvable problem. When coders drive the development cycle, it won't get finished soon enough to help the business. When business drives the cycle, the deadlines are impossible to meet. such is life. :)</p>
<p>J.Ja</p>

Collapse -

Is quality a casualty of doing business ?

by Tony Hopkinson In reply to Is quality a casualty of ...

That was the point that I wanted to gloss over, I couldn't leave it out we all know it's true. But a lot of the time we aren't helping ourselves. Ok you've got to implement a poor design, doesn't mean you have to implement it poorly though does it ?<br /><br />Thanks for the comment anyway, I thought I was talking to myself again for a minute.<br />LOL<br /><br />Next one, is going to my idea of readable code, which of course isn't going to be anybody elses.<br /><br /><br />

Collapse -

Is quality a casualty of doing business ?

<p>From what I can tell, you & I may not write readable code the same way, but both you & I would be able to read each other's code very well. In my most recent blogs, there is a lot of code going up.</p>
<p>I tend to be extremely verbose with function/method and variable/property names (bytes for source code are cheap, debugging time is not), but I am a big stickler for code that anyone who understands the basics of programming should be able to follow.</p>
<p>J.Ja</p>

Collapse -

Is quality a casualty of doing business ?

by Hubert1497 In reply to Is quality a casualty of ...

A college instructor of mine used to teach (preach?) that NOT logic was just that - Not Logic. Toss in that the NOT might require you to also reverse certain AND's & OR's and you've got a real nightmare on your hands. With the exception of straightforward tests such as != 0, or NOT .EOF, NOT logic can generally be restructured to be more readable (and maintainable).


"Back in the day" software used to have a lifespan of 10-15 years and it was estimated that at least 50% of your IT budget would be in supporting (not designing / developing) the software. Nowadays software has a lifespan of 2 years so many times the attitude is: "Why spend the time to write it eloquently? It'll be obsolete 2 months after it's implemented." If you're Management, or taught yourself to code in your bedroom at age 12 and never sought any subsequent formal training, I suppose it's understandable how you could arrive at that conclusion. But if you're a "professional" (in the true sense of the word), you can probably design & develop quality code just as quickly as someone throwing crap together. Or at least recognize when you've developed crap.


And being an old fart my definition of spaghetti is slightly different than yours. "Spaghetti Code" referred to code with so many GOTO's that if flowcharted out the resulting connecting lines would resemble a bowl of spaghetti. But, the output of this type of code would generally result in your definition, so yours also fits well.


As for the unrealistic deadlines Justin mentioned, I think the media (movies, TV) is partly to blame. We watch some kid write a world-saving program in 30-60 minutes (minus commercials) and the uninformed / uneducated come away brainwashed, believing that's all the time it should take. But I guess watching a show about Analysis, Design, Testing, and Documentation would be pretty boring.


Finally, I'll leave you with a quote from Robert Pirsig's book: 'Zen and the Art of Motorcycle Maintenance': "Man does not define Quality. A man's choice of 'quality' defines the man."

Collapse -

Is quality a casualty of doing business ?

by SnoopDoug In reply to Is quality a casualty of ...

First we must define the term "quality". Good luck. Philosophy has struggled with the term "good" since Plato mused over it ~400BC.<br /><br />From a customer's standpoint quality means applicability, robustness, fit and finish.<br /><br />From a manager's perspective quality means feature set, timely delivery, marketability.<br /><br />From a developer's view quality means readable/maintainable code, appropriately named variables and methods, straightforward algorithms, no magic numbers.<br /><br />So how can we agree on quality?<br /><br />I think the problem lies in the malleability of software. Just because we can change the code base so easily and rapidly does not mean we should. Who ever heard of a bridge project that decided to switch from concrete to steel half way across the river? Or from pier blocks to suspension? Yet we hear all the time of folks who expect to "just plug in SQL server instead of Oracle" like it's flipping a light switch (leaving aside the argument that any connection to an external system should be an interface, you still have to implement the class).<br /><br />We are our own worst enemy. I've sat in meetings where senior staff demanded we work night and day until some new functionality got implemented. I don't recall them demanding the sales staff pound the pavement until $10 million in sales hit the books, do you? Why pick on development this way? Because we deliver without complaint.<br /><br />Boo-hoo, the big, bad management made me work all weekend. Show some backbone. Tell them NO. Or do the classic passive-aggressive technique of acceding to their demands, then write the hacky/crappy code we all love to maintain.<br /><br />Reminds me of my hardware days: cheaper, faster, smaller--pick any two. In software it's features, delivery date, quality.<br /><br />doug

Collapse -

Is quality a casualty of doing business ?

by bobmccarty In reply to Is quality a casualty of ...

<p>All so true.  I've experienced the same frustrations.  </p>
<p>I would also say that it's not just the business types or the former developers turned managers who are the enemies of quality.  Most developers don't understand or at least do not value the concepts you mention.  Very <em>experienced</em> developers can deliver code, eventually, that is devoid of the type of quality you discuss and still meets the stated requirements.  So, there is little peer support in addition to no management support.  </p>
<p>I think the path out (not really a path, just a compass direction to take though the jungle) is to convince management by demonstrating to management <strong>the fact </strong>that quality will not just help the next release (that's a non-starter) but that quality will greatly increase the chances of meeting <strong>this</strong> release's goals, very much including schedule goals.  It's a difficult trek even with a good compass.  </p>

Collapse -

Is quality a casualty of doing business ?

by Tony Hopkinson In reply to Is quality a casualty of ...

<p>Thanks for all your comments.</p>
<p>I'm an old fart as well, my definition of spaghetti got modified after seeing the same result with no GOTOs. May be we should call it ravioli,  a sort of blocky pasta.</p>
<p>There are a lot of pressures of devlopers nowadays, we do have the power to reduce some of it though and we don't.</p>
<p>As I hoped to get across most of it is basic stuff, styles will differ and they can be a readability problem, but a prettifier will sort that out. There's no excuse for lazy mistakes though, they take just as long to make as it doing right in the first place, and that's without having to go back to the code, which of course you nearly always do. </p>
<p>Management aren't going to listen to reasons why we couldn't be bothered to use a long variable name and then misinterpreted it later. To be quite honest nor am I.</p>
<p>Not even long and short.</p>
<p>Are AdjPrft and AdjProfit the same thing, if so why have they got different names, if not  why have the got similar names. Wading though other peoples code, under pressure, not too sure of the environment because you are new, you don't need crap like that.</p>
<p>Real example, one was an adjustment to the profit, the other was the profit after adjustments. Two very different fellas.</p>
<p> </p>

Collapse -

Is quality a casualty of doing business ?

by Wayne M. In reply to Is quality a casualty of ...

<p>Hi Tony,</p>
<p>I think we are very much in agreement here, though I would like to throw out some additional ideas for consideration.</p>
<p>1) Software quality is actually a composite of software qualities.  Each software quality has a variable measure and will never be completely met.  One must take care when addressing software quality as a whole and not focus on one individual quality to the exclusion of the others.  (Okay, that is a very confusing statement.  Just think software "qualities" and I think it will be clear).</p>
<p>2) Refactoring is a necessary process to improving code readability and minimizing maintence cost and effort.  The IsNotBanded() example above seems to be a candidate for refactoring.  I doubt we will ever understand why the wirter chose this particular name and implementation.  What we can do is make sure our development processes do not prevent correction and ensure that they actively encourage it.</p>
<p>3) Too many current software development processes assume that developers will do a (very) poor job and try to externally force quality on to them.  This approach creates the feeling that software quantity can be maintained, but software quality may be sacrificed to time pressures.  If, however, we take the approach that software quality is inherent in the processes used by the developers, then software quality becomes fixed (or slowly improving) and software quantity may be sacrificed to time pressures.</p>
<p>Software quality is an important topic for discussion.  Thanks for bringing it up, Tony!</p>
<p> </p>

Collapse -

Is quality a casualty of doing business ?

by Tony Hopkinson In reply to Is quality a casualty of ...

Point 3 is the topic of my next blog<br /><br /><br />I came out of manufacturing. There quality and and quality control are split. One should be inherrent to the process the other,  some form of measure to see if it still is.<br /><br />Refactoring should also be part of the quality process. However like sensible standards et al. it is very difficult if not impossible to introduce to a large and already messed up code base. At the point you are really shifting to an incremental rewrite. Those are damn expensive, if you've got a lot of interdependancies fraught with risk as well. As soon as you get there, a full no holds barred start again rewrite starts to look more cost effective. So you end up sticking the current codebase in maintenance mode and doing it over. Not a new idea, whats annoying me is over twenty years I keep ending up coming to a new place and shouting rewrite at the top of my voice until someone says I think he's right you know. <br /><br />I got what you meant all designs are a compromise, we just need to stop permanently compromising the design.<br /><br /><br /><br />

Back to After Hours Forum
34 total posts (Page 1 of 4)   01 | 02 | 03 | 04   Next

Related Discussions

Related Forums