Eddie Wassef's ed·i·fi·ca·tion

"The business logic is too complicated to simplify the code."   Could there be anything more frustrating to hear? Why do so many of us truly believe that? Sure, some code gets to that point, but its not because its solving the  Vaught conjecture , but because some basic code organization tricks weren't followed. So what's the deal? I follow these few steps to help me simplify my code. Step 1- PLAN! If I had eight hours to chop down a tree, I'd spend six hours sharpening my ax. Basically, write a flow diagram... pretend like you're explaining the flow to a child; they will keep asking: "Then what happens? Then what happens..." over and over until you give them the pieces to solve the puzzle. This should be your process boxes in your flow.  Now, each of those boxes need to be a method your main public method will call them in the same way your diagram presents them. Step 2 - Organize your parameters! I'm not going to go into...

This isn't the first article you’ve read about Technical Debt, nor will it be the last. Technical Debt is here, whether you like it or not, and that’s OK, but if you don’t pay it off it will just keep ballooning bigger and bigger until you are under water. The reason it's called debt is not just a catchy play on words, but because for a software product, it acts exactly like financial debt; at the beginning, it's manageable and taking on small amounts of it is not only an attractive thing to do, it can be the right thing to do to get where you need to go. Now, if you pay it back quickly, the debt hasn't accrued much interest and is relatively easy to pay off, but the longer you let it sit, the more interest it will accrue and the more expensive and difficult it will be to pay off.   Let's take this metaphor further and consider a couple of examples: High interest rate Technical Debt: Let's say that we have a data-access component that acts as the te...