Execution – The Art of “Cut the Crap and Just Do It”

I recently reread the book called “Execution – The Art of Getting Things Done” and although its somewhat old, it has surprisingly good and practical advise about putting your focus more on getting things done and less on thinking about strategies.

Or where I read from somewhere recently “The goal is to work, not think about working” which was in reference to keeping a planning meeting fixed to a certain number of hours.

Of course, you do need strategy, but if you don’t actually make sure that what you planned get done, or alternately, notice that your strategy may not be working then it just won’t work.

Hey! Wait a minute! Don’t you do Theory all the Time

Yes, I am very guilty of it myself about just thinking of things and not doing them. I even wrote about it at the top of one of my posts.

So recently, I was looking at all my talk about business rules on my blog and I was thinking “if I take a regular database and I wanted to add some business logic/rules to it, how many rules would I need to add?”.

I took a database that was connected to some web site forms that basically collect information about users for campaigns and news letters. I could really only found one rule to add and that’s because I knew how the data will be used later.

Now I do agree that this is not really a web application that requires a lot of logic. This system is pretty much taking data from point A to point B.

However, I was thinking about past projects and even when it was relatively complicated web application and even then, I could only think, at the top of my head, 3 main rules that might have been used in the database instead of across 10s of PHP files. Everything else in those PHP file was again, taking data from point A and fashioning it in a nice viewable way to point B, which is on your screen.

My Question

So my question is, why is adding business rules to your database such a controversial issue?

Maybe it’s something to do with adopted practices that tell you to not put any logic in the database. Maybe people are afraid to commit to one database and might change it in the future. So keeping the logic separate is more convenient.

I myself have come to realize that a large part of the reasons I thought this was a good idea was when I was working on a MySQL/PHP system and wanted to save time coding PHP (or just couldn’t even found where the lines of code were located in the mess that was there) by making long and complicated SQL statements or by creating Views. This seemed easier to me and I found it more comfortable to control my work, monitor the data and (which was the best part for me) show me the speed in which the queries were generated - so that I can speed up the website.

Conclusion

So I think that if you really take a look at it, (and you are not making an Expert System or Decision Support System) you only really need a few (that’s just my crazy assumption) business rules which can relatively easily be implemented in the database. Why not just try it and see if it works for you.