11–20 of 36 posts
What I’m about to say will be blindingly obvious to the Enterprise crowd...The rules must be considered as carefully as the entities. Enterprise developers have known this for years: that’s why you see rules engines, table-driven designs, and visual workflow editors in many Enterprise applications. What a refreshing statement at a time when we're bombarded with so many annoying "SQL is Dead" posts. Try designing an e…
What I’m about to say will be blindingly obvious to the Enterprise crowd...The rules must be considered as carefully as the entities. Enterprise developers have known this for years: that’s why you see rules engines, table-driven designs, and visual workflow editors in many Enterprise applications. What a refreshing statement at a time when we're bombarded with so many annoying "SQL is Dead" posts. Try designing an e…
Of course many of the concrete methods enterprise developers use come from these 'academicians' so don't be too quick to judge them. We all stand on their shoulders... it's fine to give em a good kick every so often but remember who is holding us up.
As a trained mathematician, I wish I could agree with you and cite all the wonderful applications of classical thinking that I've used to solve real enterprise problems, but alas, I can't. It was only after I abandoned the constant search for "elegant" solutions to real world problems that I was able to embrace good old fashioned "blocking and tackling" to solve the problem at hand.
I've lost track of how many times I was challenged to "use the simplex method" to attack multiple simulaneous mutually exclusive constraints when the most effective approach ended up being, "Put all the data into a relational database and keep spitting it out different ways until our people figure it out." The scientist in me wishes it wasn't true, but the pragmatist knows better.
Sorry to dump on the academic world so much, but I suppose I wouldn't if I could cite more success stories.
The Monopoly example just struck a nerve; a classic example of the difference between theory and practice.
What I’m about to say will be blindingly obvious to the Enterprise crowd...The rules must be considered as carefully as the entities. Enterprise developers have known this for years: that’s why you see rules engines, table-driven designs, and visual workflow editors in many Enterprise applications. What a refreshing statement at a time when we're bombarded with so many annoying "SQL is Dead" posts. Try designing an e…
Not as refreshing, when you realize this article was written in 2006.
Earlier quoted context omitted.
Not as refreshing, when you realize this article was written in 2006.
What's changed? Perhaps the technology a little, but as for the real world problems, not nearly as much. Give the frameworks for thinking a little more credit than that.
Earlier quoted context omitted.
Of course many of the concrete methods enterprise developers use come from these 'academicians' so don't be too quick to judge them. We all stand on their shoulders... it's fine to give em a good kick every so often but remember who is holding us up.
I agree that we all stand on the shoulders of giants, just not the same ones you cite. As a trained mathematician, I wish I could agree with you and cite all the wonderful applications of classical thinking that I've used to solve real enterprise problems, but alas, I can't. It was only after I abandoned the constant search for "elegant" solutions to real world problems that I was able to embrace good old fashioned "…
Earlier quoted context omitted.
I agree that we all stand on the shoulders of giants, just not the same ones you cite. As a trained mathematician, I wish I could agree with you and cite all the wonderful applications of classical thinking that I've used to solve real enterprise problems, but alas, I can't. It was only after I abandoned the constant search for "elegant" solutions to real world problems that I was able to embrace good old fashioned "…
The relational database model is actually a very good example of mathematical rigor, and comes out of the world of research.
What if your candidate isn't familiar with Monopoly because, say, they didn't grow up in the west?
Earlier quoted context omitted.
Of course many of the concrete methods enterprise developers use come from these 'academicians' so don't be too quick to judge them. We all stand on their shoulders... it's fine to give em a good kick every so often but remember who is holding us up.
I agree that we all stand on the shoulders of giants, just not the same ones you cite. As a trained mathematician, I wish I could agree with you and cite all the wonderful applications of classical thinking that I've used to solve real enterprise problems, but alas, I can't. It was only after I abandoned the constant search for "elegant" solutions to real world problems that I was able to embrace good old fashioned "…
On the other hand, the way in which you think of mathematical entities can be very important and useful, particularly in thinking of things in terms of constraints and preconditions and the resulting guarantees the code can make. Again, not in a flat-out "code proof" sense, but as a way of approaching the code. This has allowed me to write some surprisingly capable code in a multi-team setting by carefully considering the minimal requirements I can impose on the other teams to get a desired result, then making sure I enforce those requirements carefully (since I am in a language where I can't do it with a type system), and then on those basic promises build another layer of the system that is the thing I am actually working on. If I came at this with a hacky hacky chop chop approach it would fail... just as the previous effort did, ahem.
Also, in programming as in math, a thing is what it does, profoundly. This can take a long time to come to grips with. A typical programming entity "is" quite a bit more than your typical math entity, though, for better and for worse.
Preconditions, postconditions, and constraints also make great testing fodder, by which I mean, they make great practical testing fodder. Writing code in practice is a lot easier if you have some assurance that those things are actually true.
I don't necessarily even sit down and sketch this all out, again, because being too rigid causes your rigid assumptions to break, but this stuff is always in the back of my head, and it will get you quite far once you master it....
... and I say that in general. edw519 I wouldn't care to second guess how you're doing things at this point. :)
What if your candidate isn't familiar with Monopoly because, say, they didn't grow up in the west?
That's the pattern to all this, rules and exceptions and how easy it is to change those rules (because they change constantly).
So do you put all that into your SalesPerson object or is there a better way to abstract the logic of commissions?