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

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

So, now we have the picked the best ORM for our purposes, chances are, you want to test it. We all test our code all of the time with close to 100% coverage, right? Yea, that's what I thought. Throughout the years, I've found that most developers don't test their code thoroughly because a handful of reasons: The tests written are too brittle and break with every new feature. It's too tedious to try to and mock out every little thing Its just too difficult; things are abstracted out way too much nowadays and I cant get them to pass  You know, they're not entirely wrong; I've seen code written to perform CRUD on a table that could only be described as 'awful'. Firstly, the amount of code to do that simple operation was just absurd. Secondly, the repository pattern needs to go; it just doesn't make any sense to me to try to anticipate every possible request that's needed and create a member for it (read over-complicating things). Thi

Whether you are in a startup, an established company or just tinkering around, you've probably come across the same question: "How do I get data from my database?"  Theres always the "hand-rolled" option, but, once again, I will have to reach into my bag of Eddie-isms and pull out: If you want to make an apple pie you can always grab a shovel, a handful of seeds and a big warm pile of horse$@#$ and do it all yourself. Or, you could just go to the store and grab a bunch of apples and start from there. Well, now that that is out of the way, lets assume we don't want to waste our time reinventing the wheel and go with an ORM that gets us past the repetitive cruft of getting the data and mapping it manually. Lets follow the process I outlined in my previous blog ( The Magic Formula to choosing the right piece of software ) and see where the lines take us. OK, I'm a .NET guy, so that limits our scope to a few products. Lets list out the most popular:

Throughout my career software has come and gone and trends flare up and disappear like a shadow into the night and before you know it, there's a new shiny toy sitting on your desktop. That's really what makes our industry exciting and why more and more people are getting into it every day. With that though, there is always the question of which horse do I hitch up to? Do I latch on to the cool ReactJS framework or stick with Angular? Do I move to DapperORM, NHibernate, EFx, Telerik ORM etc etc etc. The options seems endless! and most of the time they are... which is great! but also kinda sucks; how do I pick one over the other?! How do I go to my boss and get them to invest thousands of hours and dollars into a new piece of technology. Well, I've been doing this a long time, and there really is no magic formula (gotcha!) I can recall a blog post by   Chris Aitchison   titled: You are NOT a Software Engineer!  that really resonated with me. The argument is that we ar