• (disco)

    Seems to me tgis person just wanted to KISS everything.

  • (disco)

    That helper class does not help. Help!

  • (disco)

    He removed salted hashes from the database and stores passwords in clear text

    Does anyone here have the unfortunate task of working in a company where the above is not a firing offense?

  • (disco) in reply to LB_

    I don't know, we had another brillant screwup today involving a sysadmin who basically DROP TABLE *'d an infosec-related database. And he hasn't gotten in any sort of trouble over it, despite its importance.

  • (disco)

    " The Damogran Frond Crested Lead Developer had heard of the notion of survival of the company but wanted no part of it."

     The     Lead Developer    is a spy!
  • (disco) in reply to LB_
    LB_:
    He removed salted hashes from the database and stores passwords in clear text
    Does anyone here have the unfortunate task of working in a company where the above is not a firing offense?

    Working in PCI-relevant software here; we're all too aware of liability issues to pull something as stupid as that.

  • (disco)

    Well two of the items might have justification.

    Updating the Build Number is pretty standard (there should never be two assemblies with different content and the same name/version), committing back to SVN is questionable (but not necessarily horrible), and I don't see how this would cause merge issues [but I am still drinking my morning coffee]

    XML-DOC comments are quite helpful in preparing good reference documentation [aka SandCastle].

  • (disco) in reply to TheCPUWizard
    TheCPUWizard:
    XML-DOC comments are quite helpful in preparing good reference documentation

    No amount of technology like that can actually force a developer to produce good reference documentation. Some people simply don't…

  • (disco) in reply to dkf
    dkf:
    No amount of technology like that can actually force a developer to produce good reference documentation. Some people simply don't…

    Agreed with the "force" part, but technology can help encourage, by eliminating some of the overhead.

  • (disco) in reply to dkf

    This is true. Like any sort of skeleton generator, prefilled documentation is one of those things that can be useful, but have to actually be used in order for it to be more than just additional verbage. If you don't put meat on the skeleton, then it just clutters up the page, and can make things worse rather than better.

  • (disco) in reply to Mason_Wheeler

    "... as stupid as that..." <-- are you referring to cleartext passwords or to firing the guy who did it?

  • (disco) in reply to dkf

    'good reference documentation' - now there's a term I've not heard in a great many years....a great many years.

    http://vignette4.wikia.nocookie.net/starwars/images/4/4e/ObiWanHS-SWE.jpg

  • (disco) in reply to RFoxmich

    There is technology that can achieve it though.

    http://g04.s.alicdn.com/kf/HTB1lWddJpXXXXcpXFXXq6xXFXXXA/38-INCHES-58CM-CATTLE-PROD-WITH-SHAFT.jpg

  • (disco)

    Until approx. two years ago, the lead dev. (who "left" about that time after 12 years working on this one codebase) pushed the following best practices:

    stream of consciousness programming one big monolithic stream of logic - modularity is for sissies

    spread out decision making all over the place make it hard for a reader to discern the flow of logic use lots of different variables for the same purpose in making decisions assign them different values all over the place special values null means one thing empty means another assigning them other special strings means yet another

    never refactor, never surrender even if a method name has nothing to do with the current logic within, don't change the name of the method or the vars (oh, and BTW, be sure not to change any comments or docs either, never give the maintainer clues to follow).

    always add blocks of logic, never make a new method or class - the longer the method the better

don't remove code, comment it out - this makes the code harder to read.

    DO Repeat Yourself - but copy/paste is for sissies; copy, paste, then tweak a little. The more places you have the same logic the better, but it should be at sufficiently different enough that it is harder to refactor - discourage someone from refactoring the code into one place. Make them work for it.

    global vars - lots of them, changed and used lots of different places - the farther apart the better. Even better is if you use them for different purposes - i.e., overloading their meaning.

    A State of Madness Vars store state. If you really want to confuse someone, have 3 or four vars in the same class with the same name but different scope. Even better, have classes within classes that have this same var name as the outer class, and methods that have a local scope var as the class var. Add on top of that no enforcement of var name practices; i.e., sometimes you have m_varName as a class var, many times you don't. Sometimes a method scope var is named m_varName (possibly because a dev changed it from class scope to method scope and didn't change the name), but all of the time you have this mix of var names.

    	Now, take all those vars that have the same name, and have them all tracking the same state. You are almost guaranteed that at some point in time one of them is going to be out of synch with the others. Certainly you will confuse any future coder.
	
	Finally, it is often a bad practice to store state like this in a class var. You generally should keep it as local as possible. I.E., if you need to track some state, then keep it within each method. Why? For one thing it is just easier to follow/know who is changing that state, especially if the state can be changed via a public method call. E.G., you have:
	
		public class MyClass
		{
			public boolean skipFile;
				
			public void processFilesForImport()
			{
				skipFile = true;
			}
			
			public void processFilesForExport()
			{
				skipFile = false;
			}
		}
		
	Now, what happens when you have each of those methods called by a different thread? Chaos - right?
	
	To make it even worse, notice that the 'skipFile' var is public so you don't even have to call the method to change it, you can change it directly from outside the file.
	
	Now add on top of that the "State of Madness" where you have a number of different vars throughout this class, all named the same, all tracking the same state!
	
	Enough to drive a dev insane!

    type safety is for sissies pass around strings use hashmaps of key value pairs - value objects are too easy flatten out the model - spread it out, harder to understand that way mix and match

    if something can be done simpler, don't do it that way. Very simple example:

    Good (more complex):

if (somecondition)
	callsomemethod(param, param, param, true, param)
else
	callsomemethod(param, param, param, false, param)

Bad (i.e., easier to understand and maintain):

bool value = somecondition
callsomemethod(param, param, param, value, param)

Very Bad (simpler yet):

callsomemethod(param, param, param, somecondition, param)

    version control checkin as many noise files as possible, including old versions as new files with versions in the file names put different versions in different folders

    To pass a list build a comma delimited list and pass that as a string.

    These are just some of the "best practices" I had to follow while the previous lead was here. Now I have 15+ years of crufty legacy code to unravel and extend while still adding features and meeting release dates. It will probably take another 15+ years to make this code halfway decent at this rate. The good thing is I retire in 5 years.

  • (disco)

    The "leading developer" and the DBA in "Filing Data" must be brothers :-D

  • (disco) in reply to ScholRLEA
    ScholRLEA:
    Like any sort of skeleton generator, prefilled documentation is one of those things that can be useful, but have to actually be used in order for it to be more than just additional verbage.

    Some of the newer "semantically aware" tools are getting pretty powerful. One good use-case is when one adopts a "package based" mentality, and the information is presented at time of use.

  • (disco) in reply to Tsaukpaetra
    Tsaukpaetra:
    KISS

    That.

  • (disco) in reply to Developer_Dude
    Developer_Dude:
    To pass a list build a comma delimited list and pass that as a string.

    Unfortunately, no way around doing this in SSRS with a Stored Procedure as the data source. It's gotta be done that way.

    Filed under: Is there REALLY no better way to do this? Come on, man!

Leave a comment on “Leading Development”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article