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...

As I was looking out of the window of my flight, I looked on to see the house and neighborhoods below and couldn't help but admire the beauty of the organization intertwined within the chaos and randomness of the surrounding environment. I couldn't help but draw parallels to my own world, as a software architect for almost the last decade, as to how similar that world is to mine. I have always struggled trying to clearly explain the difference in rules between a software architect and a software developer. Even more difficult has been trying to explain the difference between the different types of architects themselves. Barcelona Spain. Bing Maps A lot of people tend to think that an architect is something one becomes after they are the top level developer they can be, the next step up so to speak. That might be because the salary structure in our industry rarely values nor can properly price developers to begin with. That's a whole other blog post in i...