"Celebrate God all day, every day. I mean, revel in him!" - Philippians 4.4, The Message
For some reason I always forget this simple truth.
We were designed from the ground up by the Master Architect to be single-mindedly focused......obsessed....
With what? With the Master Himself.
That is one of our intended uses - it was the intent that was up on the heavenly white board before our first cells started dividing.
It is such a part of what we are that if we don't revel in the Master, we will find a counterfeit. We will revel in something - actually almost anything. And it is always empty.
Even as a believer in Christ - even as someone who has probably heard 100+ sermons on this exact topic - I find myself forgetting the simplicity and sense of alignment and peace that comes from obsessing over my Creator.
I mean think about it - if you look at the words obsessing over.....you might have the same gut reaction as me. That is, something along the lines of "obsessions are bad - it means you're unbalanced". But this is actually wrong thinking.
Obsession has a bad rap because the things that we tend to obsess over are inappropriate. In fact there is one and only one Thing we are made to obsess over - and that is the King of The Universe.
Scripture has a name for misplaced obsession - idolatry - it's a stained-glass word that means obsessing over something other than God. And as with many of the things we are instructed of by God, it is for our own good that we obey.
I challenge you to celebrate The Almighty - to obsess over The Holy One. Let everything else fall away - see if you find yourself feeling empty or feeling like you finally discovered how to really live.
Wednesday, January 12, 2011
Monday, January 10, 2011
Quantum Leap Techniques, part 1 - The Interface
Quantum Leap Techniques, part 1 - The Interface
This is the first in a series of posts I will call "quantum leap techniques" - simple counterintuitive things that you can do to step your coding game up to the next level.
When you are creating a system and laying out the way that you will organize its behavior and data, you will undoubtedly find yourself creating layers of objects. We can go over approaches to layering in certain contexts and the specific ways you may decompose a system at a later time.
For now we will cover one very specific aspect of layering - the interface between layers.
Every time one object interacts with another, there is a contract between them - the way that the two objects in the relationship "talk" to each other.
The Good
--
If the objects have a clearly thought out way of speaking with each other, it will be clearer what the responsibility of each object is. This in turn makes it easier for the next programmer who comes across this code to make a change. Because they will have a basic structure to follow, and less information that they will have to synthesize and keep in their short term memory.
The Bad
---
If the relationship between two objects is allowed to become muddy, responsibilities will be less clear as well. This makes it much more difficult for future maintainers to modify.
The Ugly
---
Taken to the extreme - there are no lines of responsibility. In this case the fact that the two objects are separate is totally irrelevant - since we have given up any benefits we might have otherwise gotten. In fact having separate objects at this point just makes things more confusing.
So what's the solution??
I'm glad you asked.....the ultimate solution is ongoing diligence, making sure to keep responsibility clear between objects.
More concretely though - to keep the lines between objects clear and well defined really requires focus on the interface between objects.
Yet more concretely - lines between certain objects need more attention than others. For example, a very clear and controlled line should be drawn between display/presentation and business logic. In places like this where you would like to draw a clear line, or just anywhere you would like to make sure focus is placed on separation a useful tool is to code to an interface (the actual language construct).
That is to say, the client object should access the its dependencies only through an interface, avoiding any dependency on the interface's implementation(s).
Why this helps is because the exercise of writing an interface focuses attention on the method signatures - that is it is more difficult to be distracted by implementation.
The result of this is more clarity around separation and placement of responsibilities.
Thursday, April 16, 2009
Science and Its Misapplication
Science is observation.
It is the systematic search for knowledge – a striving to understand the reality that we live in. It’s exciting and fun in the same way that it is exciting and fun for a young child to discover the environment that she is placed in – touching, feeling, and tasting everything. The skill with which we observe is at a much higher level, but the basic process and motivation are the same. We want to know what is going on around us.
Science is limited.
Because science is observation, the only knowledge that we can attain using it is knowledge that can be obtained through first hand observation and inference. Anything else is not science. If you hear your science professor tell you that the Earth is round and believe him, this is not science – even though she is a science professor. If your mother tells you that the stove top is hot and you believe her – this is not science.
Science is not enough.
It is sheer arrogance to think that through direct observation we can get a hold of enough knowledge to make good decisions about how to live. To re-use a previous example: if when you were a child and your mother told you the stove top was hot – the best approach is not the empirical one. Similarly, you don’t need to directly observe the effects of a severe car accident to believe those who tell you that it is important to wear a seat-belt when riding in or driving a car. Imagine how many problems we would have if before we made a life decision we had to systematically observe the exact same situation – it would be paralyzing – and ridiculous.
Science evolves.
All of these things should be fairly self-evident – I think most people would agree that science is about observation and that there is knowledge out there that isn’t observable. However, I think a lot of people miss that scientific understanding about a particular bit of knowledge evolves and is often times found to be downright wrong – to say that again with a more positive angle – scientifically obtained knowledge is constantly refining, drawing closer to the actual state of reality. Take gravity for instance – Newton was pretty sure he figured that one out – but it turns out there are situations where gravity doesn’t work like he thought. Or take tree rings – trees are typically expected to add a single ring for every year that they are living – however conditions have been observed where trees either add extra rings or don’t add any rings – contradicting previously held assumptions.
So to finish – it is important to remember that when thinking through life’s big issues: scientific observation is a phenomenal tool that we’ve developed however it is not the Inerrant Complete Answer to Everything™. Also, when thinking through a particular issue, if it is important to you to use science, it is not “more scientific” to believe someone whose profession is science as opposed to believing someone of another profession – both are faith.
It is the systematic search for knowledge – a striving to understand the reality that we live in. It’s exciting and fun in the same way that it is exciting and fun for a young child to discover the environment that she is placed in – touching, feeling, and tasting everything. The skill with which we observe is at a much higher level, but the basic process and motivation are the same. We want to know what is going on around us.
Science is limited.
Because science is observation, the only knowledge that we can attain using it is knowledge that can be obtained through first hand observation and inference. Anything else is not science. If you hear your science professor tell you that the Earth is round and believe him, this is not science – even though she is a science professor. If your mother tells you that the stove top is hot and you believe her – this is not science.
Science is not enough.
It is sheer arrogance to think that through direct observation we can get a hold of enough knowledge to make good decisions about how to live. To re-use a previous example: if when you were a child and your mother told you the stove top was hot – the best approach is not the empirical one. Similarly, you don’t need to directly observe the effects of a severe car accident to believe those who tell you that it is important to wear a seat-belt when riding in or driving a car. Imagine how many problems we would have if before we made a life decision we had to systematically observe the exact same situation – it would be paralyzing – and ridiculous.
Science evolves.
All of these things should be fairly self-evident – I think most people would agree that science is about observation and that there is knowledge out there that isn’t observable. However, I think a lot of people miss that scientific understanding about a particular bit of knowledge evolves and is often times found to be downright wrong – to say that again with a more positive angle – scientifically obtained knowledge is constantly refining, drawing closer to the actual state of reality. Take gravity for instance – Newton was pretty sure he figured that one out – but it turns out there are situations where gravity doesn’t work like he thought. Or take tree rings – trees are typically expected to add a single ring for every year that they are living – however conditions have been observed where trees either add extra rings or don’t add any rings – contradicting previously held assumptions.
So to finish – it is important to remember that when thinking through life’s big issues: scientific observation is a phenomenal tool that we’ve developed however it is not the Inerrant Complete Answer to Everything™. Also, when thinking through a particular issue, if it is important to you to use science, it is not “more scientific” to believe someone whose profession is science as opposed to believing someone of another profession – both are faith.
Tuesday, March 31, 2009
INT v. GUID - The Battle Rages On
So a friend of mine (and probably countless other geeks) continue to debate the data type that is best used for "surrogate" primary keys in database tables....a sarcastic comment on Facebook from yours truly sparked a bloody battle in the larger war.. ok I'm being dramatic - but it did kick off a good conversation... and brought out some of the underlying issues surrounding this oh-so-important debate....the discussion follows:
---
Brian Sneddon Looks like Twitter's record ids for storing tweets is around 1.4 billion. Hope they're using bigint already because the clock is ticking...
Kyle Rowland at 3:46pm March 30
guid
Brian Sneddon at 4:43pm March 30
If you use a guid you have no way to compare the time a record was created relative to other records unless you add a timestamp field. Then if you want to be able to search off it you need to index it. Can be quite a high cost versus just using something like a bigint.
Kyle Rowland at 4:46pm March 30
Right - but you're adding multiple purpose to the key - this is kind of a hack - at bare minimum it's unclear. Justifying it in terms of processing cost is like arguing that a GUI takes too much computing cost and we should therefore use only commandline prompts (yeah, i know i know...if only)... it's the same thing though, you're trading clarity for nominal processing cost.
Brian Sneddon at 4:56pm March 30
I can see your perspective, but I don't agree that it's a hack or unclear. I think having an autoincrementing primary key is a self-evident mechanism for both establishing comparative chronology as well as ensuring a unique reference to the row. I don't think there's anything wrong with taking self-evident and consistent behavior and making logical conclusions based on it. If I store bank balance information and want to use it not only to determine a customer's balance but to also make a business decision as to what tier I consider a customer to be in if the tier is consistently determined by the range of their account balance, I wouldn't see a problem in using that account banance for multiple purposes.
Kyle Rowland at 5:52pm March 30
There's nothing *wrong* with it per se - it's just better not to tie multiple meanings together like that. The bank balance thing is a perfect example - sure you could store it like that, but what if the business rule changes...in your world that rule is now embedded as an assumption of the code that is reading the data. If the rule changes you have to change whatever code was making assumptions about the rule. If you separated them out into two distinct fields (say a balance field and a tier field) - it would be very clear what was going on, and if your business rule changed it would require minimal changes to the client code. It's not a right or wrong thing - it's a readable, maintainable or not thing..
Brian Sneddon at 6:31pm March 30
To compare apples with apples in my example, the tier never changes. If it would change then it would make more sense to store it separately. In this example a tier is fundamentally tied to a specific balance range and is immutable. Not the best real world example, I admit. However using an autoincrementing primary key still allows you to both establish uniqueness as well as provide comparative chronology in both an efficient and straightforward manner. I think the argument that it's not clear could be taken ad absurdum to claim somewhat subjectively that we should abandon any complex datatypes simply because there might be some confusion as to how they should be used. There's a balance you strike here between efficiency and simplicity, and while any point on the spectrum isn't inherently wrong there will be disagreement about the necessity of leaning in either direction. I just doubt that anyone who works with database apps would actually be confused by it.
Brian Sneddon at 6:35pm March 30
Then to get into database implementations, when inserting into an index it is cheaper to insert into the end of the index as in typical tree implementations it requires much less maintenance of the tree in the process. With guid primary keys, which is of course what this stemmed from (no pun intended), you're constantly inserting into various points in the tree and can incur a lot of maintrnance cost in the process. I just don't see a whole lot of value to using guid vs a sufficiently large integer when you need a separate primary key.
Kyle Rowland at 8:16am March 31
Of course it's subjective - this is where software is an art. I'm not saying using an int primary key is evil - just that it slightly less clear (IMHO). In general, I like to avoid doubling up on meaning - this is just one design decision - but multiply it by 1000 and depending on the collection of individual choices one of two things emerges: an elegant, modular system that is a joy to maintain or that other thing. Both work, but I know which I'd prefer to work on. So to get back to the main point - there are really two arguments that you've proposed for using int for a primary key:
1) optimized database access
2) the convenient side effect of having chronology
They're both valid... however, until you show me some evidence that #1 even makes a difference in the real world, I don't believe it should be taken in to account - and I don't mean benchmarks, I mean in the context of a real, well written app. And really in total, I'd still prefer clarity over both of these...
Kyle Rowland at 8:18am March 31
Also re: The Mythical Immutable Requirement.... I don't believe it exists. In either case here or at all.
Brian Sneddon at 10:32am March 31
Check http://www.mysqlperformanceblog.com/2007/03/13/to-uuid-or-not-to-uuid/#comment-81922 for an explanation as to why UUID can hurt performance. I know you said you don't want a benchmark, but you know I don't have access to any real-world scenerios. ;) However based on the simplicity of the benchmark at the end (i.e. bulk loading into a table) you can see that as the amount of data you need to insert rises the performance impact becomes clearly visible. This impact might not be noticable in smaller apps, but would certainly manifest as it grew.
Brian Sneddon at 10:37am March 31
of course at the same time Brian Aker's tests using UUID don't show that same performance degredation. So I guess the results aren't so clear. The great debate will live on! :)
Kyle Rowland at 11:46am March 31
yes it will :)
---
Brian Sneddon Looks like Twitter's record ids for storing tweets is around 1.4 billion. Hope they're using bigint already because the clock is ticking...
Kyle Rowland at 3:46pm March 30
Brian Sneddon at 4:43pm March 30
If you use a guid you have no way to compare the time a record was created relative to other records unless you add a timestamp field. Then if you want to be able to search off it you need to index it. Can be quite a high cost versus just using something like a bigint.
Kyle Rowland at 4:46pm March 30
Right - but you're adding multiple purpose to the key - this is kind of a hack - at bare minimum it's unclear. Justifying it in terms of processing cost is like arguing that a GUI takes too much computing cost and we should therefore use only commandline prompts (yeah, i know i know...if only)... it's the same thing though, you're trading clarity for nominal processing cost.
Brian Sneddon at 4:56pm March 30
I can see your perspective, but I don't agree that it's a hack or unclear. I think having an autoincrementing primary key is a self-evident mechanism for both establishing comparative chronology as well as ensuring a unique reference to the row. I don't think there's anything wrong with taking self-evident and consistent behavior and making logical conclusions based on it. If I store bank balance information and want to use it not only to determine a customer's balance but to also make a business decision as to what tier I consider a customer to be in if the tier is consistently determined by the range of their account balance, I wouldn't see a problem in using that account banance for multiple purposes.
Kyle Rowland at 5:52pm March 30
There's nothing *wrong* with it per se - it's just better not to tie multiple meanings together like that. The bank balance thing is a perfect example - sure you could store it like that, but what if the business rule changes...in your world that rule is now embedded as an assumption of the code that is reading the data. If the rule changes you have to change whatever code was making assumptions about the rule. If you separated them out into two distinct fields (say a balance field and a tier field) - it would be very clear what was going on, and if your business rule changed it would require minimal changes to the client code. It's not a right or wrong thing - it's a readable, maintainable or not thing..
Brian Sneddon at 6:31pm March 30
To compare apples with apples in my example, the tier never changes. If it would change then it would make more sense to store it separately. In this example a tier is fundamentally tied to a specific balance range and is immutable. Not the best real world example, I admit. However using an autoincrementing primary key still allows you to both establish uniqueness as well as provide comparative chronology in both an efficient and straightforward manner. I think the argument that it's not clear could be taken ad absurdum to claim somewhat subjectively that we should abandon any complex datatypes simply because there might be some confusion as to how they should be used. There's a balance you strike here between efficiency and simplicity, and while any point on the spectrum isn't inherently wrong there will be disagreement about the necessity of leaning in either direction. I just doubt that anyone who works with database apps would actually be confused by it.
Brian Sneddon at 6:35pm March 30
Then to get into database implementations, when inserting into an index it is cheaper to insert into the end of the index as in typical tree implementations it requires much less maintenance of the tree in the process. With guid primary keys, which is of course what this stemmed from (no pun intended), you're constantly inserting into various points in the tree and can incur a lot of maintrnance cost in the process. I just don't see a whole lot of value to using guid vs a sufficiently large integer when you need a separate primary key.
Kyle Rowland at 8:16am March 31
Of course it's subjective - this is where software is an art. I'm not saying using an int primary key is evil - just that it slightly less clear (IMHO). In general, I like to avoid doubling up on meaning - this is just one design decision - but multiply it by 1000 and depending on the collection of individual choices one of two things emerges: an elegant, modular system that is a joy to maintain or that other thing. Both work, but I know which I'd prefer to work on. So to get back to the main point - there are really two arguments that you've proposed for using int for a primary key:
1) optimized database access
2) the convenient side effect of having chronology
They're both valid... however, until you show me some evidence that #1 even makes a difference in the real world, I don't believe it should be taken in to account - and I don't mean benchmarks, I mean in the context of a real, well written app. And really in total, I'd still prefer clarity over both of these...
Kyle Rowland at 8:18am March 31
Also re: The Mythical Immutable Requirement.... I don't believe it exists. In either case here or at all.
Brian Sneddon at 10:32am March 31
Check http://www.mysqlperformanceblog.com/2007/03/13/to-uuid-or-not-to-uuid/#comment-81922 for an explanation as to why UUID can hurt performance. I know you said you don't want a benchmark, but you know I don't have access to any real-world scenerios. ;) However based on the simplicity of the benchmark at the end (i.e. bulk loading into a table) you can see that as the amount of data you need to insert rises the performance impact becomes clearly visible. This impact might not be noticable in smaller apps, but would certainly manifest as it grew.
Brian Sneddon at 10:37am March 31
of course at the same time Brian Aker's tests using UUID don't show that same performance degredation. So I guess the results aren't so clear. The great debate will live on! :)
Kyle Rowland at 11:46am March 31
yes it will :)
Saturday, March 7, 2009
Waiting to Sail
I find myself sitting in my car waiting to board a boat to Kingston - just looking around.
it is one of those times where it just seems to sink in, the insanely beautiful elegance of Creation...
The elegance of everything that the Lord Jesus placed in motion and entrusted to us is matched only by its unbelievable scale.
Looking at the water and the chaotic symmetry with which it interacts with the wind, and how the water all seems to like to stay together....that some objects stay on top of it while others are underneath.... I'm not a ph.d. In physics or biology, but all the moving pieces that are in play and doing their thing according to the Master's plan is crazy..
And that's just the water...there's also the blue sky with it's perfectly manipulated reflections and refractions of the sun's light....
And of course there are the people that are walking around the dock.....with their uncountable number of cellular (biological not telephone) operations happening constantly.... That go nearly flawlessly at all times.......
The Creator's hand is so evident and so powerful in all this, I can't help but feel small. And grateful...and in Love with the Master... Jesus.
Sent from my Verizon Wireless BlackBerry
it is one of those times where it just seems to sink in, the insanely beautiful elegance of Creation...
The elegance of everything that the Lord Jesus placed in motion and entrusted to us is matched only by its unbelievable scale.
Looking at the water and the chaotic symmetry with which it interacts with the wind, and how the water all seems to like to stay together....that some objects stay on top of it while others are underneath.... I'm not a ph.d. In physics or biology, but all the moving pieces that are in play and doing their thing according to the Master's plan is crazy..
And that's just the water...there's also the blue sky with it's perfectly manipulated reflections and refractions of the sun's light....
And of course there are the people that are walking around the dock.....with their uncountable number of cellular (biological not telephone) operations happening constantly.... That go nearly flawlessly at all times.......
The Creator's hand is so evident and so powerful in all this, I can't help but feel small. And grateful...and in Love with the Master... Jesus.
Sent from my Verizon Wireless BlackBerry
Wednesday, November 26, 2008
The Pyramid of Software Priorities
Ok - so a pyramid is probably the most overused illustration for.....anything...but bear with me...
There are several basic priorities you need to consider when writing software (from a code perspective)... the lower priorities are foundational to the ones above them - if you don't have a priority in place, you have no business even thinking about the next level. Also, I would probably say that the higher up the pyramid you are, the more mature you are as a developer.
So what are they??
Bottom Level: "It Works" - sometimes this is all you need.
One Level Up: "It is Readable" - if your code is to be maintainable - it needs to be readable and quickly interpretable...by the next HUMAN to read it.
Two Levels Up: "It Does Not Inspire Hate" - if that next human not only is able to read your code, but doesn't hate it, you have thrown additional value into the pot -- good job.
Three Levels Up: "It Inspires" - if the next human is able to read, and actually has a positive emotional response to your code - I think you have reached the pinnacle of achievement in software development - you've added the most possible value to those that will follow you, and thus to the software product itself.
So - next time you're building something - consider things from the bottom up....and don't try to skip steps.. the more deliberate and intentional that you are about your coding, the higher up the pyramid you will find yourself.
There are several basic priorities you need to consider when writing software (from a code perspective)... the lower priorities are foundational to the ones above them - if you don't have a priority in place, you have no business even thinking about the next level. Also, I would probably say that the higher up the pyramid you are, the more mature you are as a developer.
So what are they??
Bottom Level: "It Works" - sometimes this is all you need.
One Level Up: "It is Readable" - if your code is to be maintainable - it needs to be readable and quickly interpretable...by the next HUMAN to read it.
Two Levels Up: "It Does Not Inspire Hate" - if that next human not only is able to read your code, but doesn't hate it, you have thrown additional value into the pot -- good job.
Three Levels Up: "It Inspires" - if the next human is able to read, and actually has a positive emotional response to your code - I think you have reached the pinnacle of achievement in software development - you've added the most possible value to those that will follow you, and thus to the software product itself.
So - next time you're building something - consider things from the bottom up....and don't try to skip steps.. the more deliberate and intentional that you are about your coding, the higher up the pyramid you will find yourself.
Monday, October 20, 2008
Cause for Code
So - you get caught up in the day to day, same old routine - things get boring and stale - and sometimes you wonder why it is you do what you do. Coding takes a lot of focus - and like anything else that you have to concentrate on - it can cause you to lose your perspective. So if you're in that place right now - let me remind you why you do what you do......(and it's probably not the millions of dollars, rock-star status, and adoring-obsessive fans).....
This is from "Good To Great" by Jim Collins:
No, those who turn good into great are motivated by a deep creative urge and an inner compulsion for sheer unadulterated excellence for its own sake. Those who build and perpetuate mediocrity, in contrast, are motivated more by the fear of being left behind.
We create - we build... we pull together a myriad of different pieces of technology (most of which are far short of being mature) and piece them into working systems that not only help people accomplish - but often times, inspire and direct that accomplishment.
But take a step back with me....take a deep breath. If you notice in the passage from Collins, he discusses two motivations - which, I believe are both very prevalent in software people - the deep creative urge for excellence, and also a certain level of fear. I think everyone has a measure of both of these drivers threaded through our lives and our work - but the extent to which you can let the drive for excellence defeat fear determines the level of your work, the level of your influence on others, and the level of your own personal enjoyment of your work....(yes, you should enjoy your work - but that's a discussion for another time).
So - hopefully you know about how neat it is to nail the details of a particular system in such a way that you can just look at it and tell that it is solid and well put together. Hopefully, you are hungry for more of that. Hopefully you have that deep creative urge for excellence for its own sake....
Even though you have the hunger for excellence, fear can come into an environment in many ways - and many of us are very familiar with this. It can come from miscommunication with co-workers, being mistreated by a co-worker, or even if you mistreat a co-worker. Though, when you think about things, you can usually trace it back to its origin.
So - what is there to be done? Take responsibility for the situation - make it your mission to remove fear and feed your own hunger for excellence. If there is something that is keeping you from feeling free and empowered to do your work, identify it and deal with it - if it means doing something scary, like confronting someone, or even moreso, finding different working arrangements. Make sure that YOU are putting yourself in an ENVIRONMENT that will allow you to have your hunger for excellence. This is your responsibility - don't pass it off on to someone else.
This is from "Good To Great" by Jim Collins:
No, those who turn good into great are motivated by a deep creative urge and an inner compulsion for sheer unadulterated excellence for its own sake. Those who build and perpetuate mediocrity, in contrast, are motivated more by the fear of being left behind.
We create - we build... we pull together a myriad of different pieces of technology (most of which are far short of being mature) and piece them into working systems that not only help people accomplish - but often times, inspire and direct that accomplishment.
But take a step back with me....take a deep breath. If you notice in the passage from Collins, he discusses two motivations - which, I believe are both very prevalent in software people - the deep creative urge for excellence, and also a certain level of fear. I think everyone has a measure of both of these drivers threaded through our lives and our work - but the extent to which you can let the drive for excellence defeat fear determines the level of your work, the level of your influence on others, and the level of your own personal enjoyment of your work....(yes, you should enjoy your work - but that's a discussion for another time).
So - hopefully you know about how neat it is to nail the details of a particular system in such a way that you can just look at it and tell that it is solid and well put together. Hopefully, you are hungry for more of that. Hopefully you have that deep creative urge for excellence for its own sake....
Even though you have the hunger for excellence, fear can come into an environment in many ways - and many of us are very familiar with this. It can come from miscommunication with co-workers, being mistreated by a co-worker, or even if you mistreat a co-worker. Though, when you think about things, you can usually trace it back to its origin.
So - what is there to be done? Take responsibility for the situation - make it your mission to remove fear and feed your own hunger for excellence. If there is something that is keeping you from feeling free and empowered to do your work, identify it and deal with it - if it means doing something scary, like confronting someone, or even moreso, finding different working arrangements. Make sure that YOU are putting yourself in an ENVIRONMENT that will allow you to have your hunger for excellence. This is your responsibility - don't pass it off on to someone else.
Friday, August 29, 2008
Software Development Myth #3: My Development Velocity Is Based Solely on Me
One of my managers in the past used to say that every developer has a factor that you multiply his or her development estimates by to get a "more accurate" estimate. Ok, I believe this - some developers tend to be opptimistic in their views of how quickly they can get things done - others tend to be more pessimistic.... I even had a co-worker who thought he gave "more accurate" than other estimates...(yeah, right).... so bottom line is there's a sliding scale that you probably fall on as a developer with regards to how optimistic or pessimistic your estimations are... (I won't try to dive into the psychological reasons for how you arrived there -- anyone else want to take that post? :))
But this manager was only concerned with the developers in his environment (not surprising)... however, there is another factor to enter into the equation - and it relates to the organization - and how a particular developer relates to that organization...... so to simplify - the factor that this manager shared about is not simply to be defined by the estimating practices of the particular developer... but also how the developer works in the larger context of the organization.....
For example - at one job - I thought I had honed my estimation skills - working in a particular environment with small, packaged deliverables, and management focused on keeping hard deadlines... yeah, I could narrow things down to almost every line of code I would have to write to make something happen - not taking into account much back and forth with the folks that were requesting it........definitely easier to estimate, and it definitely pulled me from the "pessimistic" side that I tend to be on........then I worked at another company - where there was a little more back and forth - a little less rigid with regards to requirements....so my estimates probably bounced a little more toward the pessimistic side, to compensate for that.... and in yet another organization - a massive organization with many, many parties to deal with and negotiate with - I found my estimating to be on the optimistic side....and it shifted to more pessimistic, to compensate for all the challenges bringing pieces together....
I'm sure anyone who's been in the industry for any amount of time has seen similar sort of pattern... but it's something to keep in mind if you have to make a move to another organization....time moves differently in different places..... :) And you don't usually know the arate at which it moves until you have existed in it for a little while..........
But this manager was only concerned with the developers in his environment (not surprising)... however, there is another factor to enter into the equation - and it relates to the organization - and how a particular developer relates to that organization...... so to simplify - the factor that this manager shared about is not simply to be defined by the estimating practices of the particular developer... but also how the developer works in the larger context of the organization.....
For example - at one job - I thought I had honed my estimation skills - working in a particular environment with small, packaged deliverables, and management focused on keeping hard deadlines... yeah, I could narrow things down to almost every line of code I would have to write to make something happen - not taking into account much back and forth with the folks that were requesting it........definitely easier to estimate, and it definitely pulled me from the "pessimistic" side that I tend to be on........then I worked at another company - where there was a little more back and forth - a little less rigid with regards to requirements....so my estimates probably bounced a little more toward the pessimistic side, to compensate for that.... and in yet another organization - a massive organization with many, many parties to deal with and negotiate with - I found my estimating to be on the optimistic side....and it shifted to more pessimistic, to compensate for all the challenges bringing pieces together....
I'm sure anyone who's been in the industry for any amount of time has seen similar sort of pattern... but it's something to keep in mind if you have to make a move to another organization....time moves differently in different places..... :) And you don't usually know the arate at which it moves until you have existed in it for a little while..........
Tuesday, August 19, 2008
The .NET Dilemma
So there exists a bit of a dilemma in the .NET world ... having come from the Java world recently, I think I can probably see it a little more clearly than others.... it is this:
you must use only microsoft tooling, even though it is ages behind the rest of the world
Let me give you one of a few real-world examples to kind of explain what I mean -- let's start with the "you must.." part...............I'm currently doing web apps with C#/ASP.NET - and I would have liked to use an MVC framework...HOWEVER, Microsoft's is not done yet - it's on preview 4 or something... so, the other option is to use Spring.NET or another third party MVC framework... the only thing is: I know Microsoft is working on a MVC framework - and when it's done - they'll make sure there are no competitors - that means there's already a ticking clock on the lifetime of Spring.NET and any other third party projects.... so that's the "you must" part - there's really no realistic choice other than to wait for Microsoft's stuff - or just to not worry about your application becoming *legacy* as soon as you write it.....
Ok - next part - ages behind the rest of the world -- that's right - Java (among others) has had MVC frameworks for a number of years now - they're a well understood thing - they're helpful - and darn it they make you more productive..... why is Microsoft JUST now developing something? Who knows - all I know is that it's way behind the times......
Anyway - that's the dilemma in a nutshell - the fact is - the .NET environment works just fine -- but if you want leading edge power and flexibility -- mmm.. I donno... :)
you must use only microsoft tooling, even though it is ages behind the rest of the world
Let me give you one of a few real-world examples to kind of explain what I mean -- let's start with the "you must.." part...............I'm currently doing web apps with C#/ASP.NET - and I would have liked to use an MVC framework...HOWEVER, Microsoft's is not done yet - it's on preview 4 or something... so, the other option is to use Spring.NET or another third party MVC framework... the only thing is: I know Microsoft is working on a MVC framework - and when it's done - they'll make sure there are no competitors - that means there's already a ticking clock on the lifetime of Spring.NET and any other third party projects.... so that's the "you must" part - there's really no realistic choice other than to wait for Microsoft's stuff - or just to not worry about your application becoming *legacy* as soon as you write it.....
Ok - next part - ages behind the rest of the world -- that's right - Java (among others) has had MVC frameworks for a number of years now - they're a well understood thing - they're helpful - and darn it they make you more productive..... why is Microsoft JUST now developing something? Who knows - all I know is that it's way behind the times......
Anyway - that's the dilemma in a nutshell - the fact is - the .NET environment works just fine -- but if you want leading edge power and flexibility -- mmm.. I donno... :)
Thursday, August 7, 2008
LINQ to SQL!! Key Conflicts
Ok all - just a cautionary tale... if you see anything similar to the following when working with LINQ to SQL, consider what I'm about to tell you...
"Cannot add an entity with a key that is already in use."
or any other message about conflicts or whatever.....
I've had this problem probably four times, and for some reason, the symptoms still fail to trigger my previous memories.....and btw, there seems to be no tooling around how to figure out what data LINQ is talking about when it makes claims about bad primary keys,etc...(if I'm wrong, please let me know..)
Anyway - I use SQL Server generated identities for rows... and if that is not annotated on the LINQ to SQL generated code, it will not use the generated key - it will assume the key you are giving it is accurate (be it a 0 or null or whatever....)
So just remember this...... it's annoying....and it's probably, overall now, cost me a week of dev time for this project.... BOOOO
:)
Till Next Time...
"Cannot add an entity with a key that is already in use."
or any other message about conflicts or whatever.....
I've had this problem probably four times, and for some reason, the symptoms still fail to trigger my previous memories.....and btw, there seems to be no tooling around how to figure out what data LINQ is talking about when it makes claims about bad primary keys,etc...(if I'm wrong, please let me know..)
Anyway - I use SQL Server generated identities for rows... and if that is not annotated on the LINQ to SQL generated code, it will not use the generated key - it will assume the key you are giving it is accurate (be it a 0 or null or whatever....)
So just remember this...... it's annoying....and it's probably, overall now, cost me a week of dev time for this project.... BOOOO
:)
Till Next Time...
Thursday, July 17, 2008
Behavior and Rest
So here's an interesting angle (from someone that seems pretty intelligent) concerning one of my main disappointments in the 'rest' approach to web services. That is, the rest approach only encapsulates five possible behaviors (corresponding to the five HTTP verbs). In my mind, any other behavior encapsulation doesn't fit in the rest model. This guy disagrees...and he does so fairly eloquently....
http://www.xent.com/pipermail/fork/2001-August/002923.html
Unfortunately, this doesn't cut it for me - because, you're still not encapsulating any new behavior - your factoring it out into its crud operations, and then doing the behavior in the client code. So - it appears to me that rest is just not really suited to situations where you're actually trying to encapsulate behavior (such as non-trivial business logic)... but it is VERY nice for quickly modeling things that can be thought of as a resource or as a piece of data, that you want to be able to view or modify in a sort of low-level kind of way....this resource-centric approach is probably the best part of rest and would probably fit in well with other modes of web service delivery - but because of this short-coming - probably not a suitable replacement........at least IMHO. :)
http://www.xent.com/pipermail/fork/2001-August/002923.html
Unfortunately, this doesn't cut it for me - because, you're still not encapsulating any new behavior - your factoring it out into its crud operations, and then doing the behavior in the client code. So - it appears to me that rest is just not really suited to situations where you're actually trying to encapsulate behavior (such as non-trivial business logic)... but it is VERY nice for quickly modeling things that can be thought of as a resource or as a piece of data, that you want to be able to view or modify in a sort of low-level kind of way....this resource-centric approach is probably the best part of rest and would probably fit in well with other modes of web service delivery - but because of this short-coming - probably not a suitable replacement........at least IMHO. :)
Tuesday, July 15, 2008
We're Not Resources
Why actually blog myself... when everyone else is saying everything.... here's a great post about how insulting and counter-productive it is to manage software engineers as if they were replaceable cogs....let's do like a commentor says, referring to people as "Resources" should be recognized as a bad word in polite, tasteful companies....
http://blog.markturansky.com/archives/95
http://blog.markturansky.com/archives/95
Monday, July 14, 2008
.NET Web App Cheat Sheet
Dude - all I have to say is 'Thank You'...
http://duartes.org/gustavo/articles/Asp.net-Runtime-Cheat-Sheet-HttpRequest-HttpRuntime.aspx
Tuesday, July 8, 2008
Code Monkey...
Cute song - definitely got to learn how to play it...
Here are the chords:
http://www.ultimate-guitar.com/tabs/j/jonathan_coulton/code_monkey_crd.htm
Here's a good music video for it:
http://www.youtube.com/watch?v=v4Wy7gRGgeA
Here are the chords:
http://www.ultimate-guitar.com/tabs/j/jonathan_coulton/code_monkey_crd.htm
Here's a good music video for it:
http://www.youtube.com/watch?v=v4Wy7gRGgeA
Thursday, July 3, 2008
Some .NET Hotness: Stack Traces
Check this link out...
http://neilkilbride.blogspot.com/2008/04/how-to-access-call-stack-c.html
Apparently it is possible to programmatically access the various portions of stack traces in C#/.NET -- this is neat, cause in the java world, last time I checked, you had to manually parse the stack trace generated by a Throwable in order to get any kind of an idea where you were in the call stack... so woo hoo -- give it up for MS - this is kinda hot!!
http://neilkilbride.blogspot.com/2008/04/how-to-access-call-stack-c.html
Apparently it is possible to programmatically access the various portions of stack traces in C#/.NET -- this is neat, cause in the java world, last time I checked, you had to manually parse the stack trace generated by a Throwable in order to get any kind of an idea where you were in the call stack... so woo hoo -- give it up for MS - this is kinda hot!!
Tuesday, July 1, 2008
Weekly Buzzword: Integration
Ah yes - integration - sounds greek, or latin, or something - sophisticated, no doubt. But what does it really mean?
Well, I would guess it means at least a couple of things.... going back to the theme about how software developers are rigid and talk, think, and dream in 1's and 0's - probably the simple answer would be - integration is just connecting to systems. It's like plugging a plug into a light socket - simple, straight forward - not a lot of room for interpretation.
Ok - let's go back to thinking like human beings again.....the above referenced analogy works.... insofar as you recognize that not only will you be plugging the two things in - you'll be inventing the light socket and the plug from scratch, with less than two napkins worth of drawings to help you along your quest...
So what does this mean in the real world? It means there are shades of grey, dummy. Integration isn't just connecting the two pieces it's fashioning the connectors - if you need to - or maybe reusing partially applicable connectors. At any rate - it's not black and white.
So we have a responsibility here - don't let non-technicals blow it off and say - oh yeah, we're just integrating.... make sure they (or you) think first. Inversely - don't let them say OH MY GOSH WE HAVE TO INTEGRATE - make sure they (or you) think first. After you think - then you have the right to casually blow it off or to get extremely apprehensive - whichever is appropriate.
In FACT - another action item could be taken from this week's buzzword: maybe we should design a few subclasses, revealing a little more information about the actual activity that is taking place in your "integration".
That is all.
Well, I would guess it means at least a couple of things.... going back to the theme about how software developers are rigid and talk, think, and dream in 1's and 0's - probably the simple answer would be - integration is just connecting to systems. It's like plugging a plug into a light socket - simple, straight forward - not a lot of room for interpretation.
Ok - let's go back to thinking like human beings again.....the above referenced analogy works.... insofar as you recognize that not only will you be plugging the two things in - you'll be inventing the light socket and the plug from scratch, with less than two napkins worth of drawings to help you along your quest...
So what does this mean in the real world? It means there are shades of grey, dummy. Integration isn't just connecting the two pieces it's fashioning the connectors - if you need to - or maybe reusing partially applicable connectors. At any rate - it's not black and white.
So we have a responsibility here - don't let non-technicals blow it off and say - oh yeah, we're just integrating.... make sure they (or you) think first. Inversely - don't let them say OH MY GOSH WE HAVE TO INTEGRATE - make sure they (or you) think first. After you think - then you have the right to casually blow it off or to get extremely apprehensive - whichever is appropriate.
In FACT - another action item could be taken from this week's buzzword: maybe we should design a few subclasses, revealing a little more information about the actual activity that is taking place in your "integration".
That is all.
Tuesday, June 24, 2008
Software Development Myth #2: "There are applications that don't need to be modular"
"My application doesn't need to be modular" means several things:
1) My application will never change, or will change so slowly that I will have plenty of time to make any and all changes.
Yeah right. Been coding long? Guess not.
Rapid change is accomodated by modularity - have it and you will be able to handle anything they throw at you.....neglect it, and you'll be neck deep in spaghetti with a red-faced manager screaming at you.
2) My application will never grow
Similar response as to number one - though this may not be quite as obvious to the noob - apps ALWAYS grow. Period. Unless the app just totally bites to begin with - system begets system. Whenever users actually get to use a system, it inspires them to want more system. Don't know how else to say it - but, if you build it, it will grow.
And if you build it monolithically - you're going to have to be reevaluating the entire app everytime you need to grow...not fun, and it definitely doesn't make you look like a rock star.
3) My application will never be maintained by anyone but me
Really? Nice. So you will NEVER leave this job. You will NEVER grow disinterested in maintaining the same code base year after year after year.... I don't know about you - but I'm usually bored immediately after it goes to production.....
The new maintainers will not be happy people if your code is a big monolithic mess.
4) My application will never be used for anything except what it was originally intended for
This one is funny - it's amazing how expectations change over the course of an application's lifetime. I wrote a system once that basically assumed (based on the existing business process) that only one person would be entering information at a time - and that the information would then be sent out and tracked to several hundred people. Unfortunately for the system - the organization grew by leaps and bounds - to the point that the business process started to parallelize - meaning more than one person would be entering information. Uh oh.
Because a user doesn't have your unique vision about the system, they will often use it in ways you never even thought of, let alone intended. If your application is not modular - you won't be able to accomodate this.
1) My application will never change, or will change so slowly that I will have plenty of time to make any and all changes.
Yeah right. Been coding long? Guess not.
Rapid change is accomodated by modularity - have it and you will be able to handle anything they throw at you.....neglect it, and you'll be neck deep in spaghetti with a red-faced manager screaming at you.
2) My application will never grow
Similar response as to number one - though this may not be quite as obvious to the noob - apps ALWAYS grow. Period. Unless the app just totally bites to begin with - system begets system. Whenever users actually get to use a system, it inspires them to want more system. Don't know how else to say it - but, if you build it, it will grow.
And if you build it monolithically - you're going to have to be reevaluating the entire app everytime you need to grow...not fun, and it definitely doesn't make you look like a rock star.
3) My application will never be maintained by anyone but me
Really? Nice. So you will NEVER leave this job. You will NEVER grow disinterested in maintaining the same code base year after year after year.... I don't know about you - but I'm usually bored immediately after it goes to production.....
The new maintainers will not be happy people if your code is a big monolithic mess.
4) My application will never be used for anything except what it was originally intended for
This one is funny - it's amazing how expectations change over the course of an application's lifetime. I wrote a system once that basically assumed (based on the existing business process) that only one person would be entering information at a time - and that the information would then be sent out and tracked to several hundred people. Unfortunately for the system - the organization grew by leaps and bounds - to the point that the business process started to parallelize - meaning more than one person would be entering information. Uh oh.
Because a user doesn't have your unique vision about the system, they will often use it in ways you never even thought of, let alone intended. If your application is not modular - you won't be able to accomodate this.
Software Development Myth #1: "The right tool for the job"
Us software development types are rigid - we think in black and white, 1's and 0's. This serves us well when we're dealing with a machine...however, we should realize that our machines are only the canvas on which we paint our masterpiece.
We face a plethora of design and platform decisions that really boil down to nothing more than what we feel will be a good fit - and you know what - THERE'S NOTHING WRONG WITH THAT. Soak that in for a sec - it's actually really liberating: We are craftsmen - artists even - we spend our career developing an instinct for designing elegant, well organized systems that efficiently automate life for people. Repeat after me: It is ok to trust my instincts when it comes to design decisions.
Take programming languages as an example - many people feel strongly that C# and .NET are the way to go for enterprise applications - many people feel strongly about Java and JavaEE. Some people (who should be committed) are really excited about RoR. Can we solve pretty much any enterprise automation problem with any of these platforms? Yes. Is there an absolutely Right or Wrong answer as to which should be selected? Not really. A lot of it boils down to the style of the programmers that will be working the system ... there may actually be some benefits and drawbacks to different languages/platforms - but when push comes to shove any of them will work for whatever thing you're trying to build.
So then - knowing that we're computer geeks and we have to have things in 1's and 0's - how do we decide what to choose? Given a new App, what do I do? RoR or PHP? Java or C++ CGI?
I propose you do what the jazz improvisor does when he steps up to take a solo - make it up as you go... do what you feel will make the most organized, elegant work of art out there (elegant is really just a synonym for organized which just means your code is more easily maintained, in case you need to make a business case for this or something) - does RoR get your juices going, does it make you feel like you're putting out a better product? Then use it....
So let's try again.....repeat after me: It is ok to trust my instincts when it comes to design decisions.
So the corollary here, for those of you that don't see it yet - is that, while you are enjoying this profound freedom - let's not selfishly hog it up - pass it on to your co-workers, or any other programmers you come in contact with........in other words - let's practice some people skillz (I know - we're programmers, so we were probably born without that particular gene - but let's work at it) - if you are pumped about programming in Java - don't force it down the throat of your co-worker who is a big Cobol.NET fan - try for common ground as much as possible.......and try to avoid the self-serving urge to claim that your way is the only right way - cause really... it's not.
We face a plethora of design and platform decisions that really boil down to nothing more than what we feel will be a good fit - and you know what - THERE'S NOTHING WRONG WITH THAT. Soak that in for a sec - it's actually really liberating: We are craftsmen - artists even - we spend our career developing an instinct for designing elegant, well organized systems that efficiently automate life for people. Repeat after me: It is ok to trust my instincts when it comes to design decisions.
Take programming languages as an example - many people feel strongly that C# and .NET are the way to go for enterprise applications - many people feel strongly about Java and JavaEE. Some people (who should be committed) are really excited about RoR. Can we solve pretty much any enterprise automation problem with any of these platforms? Yes. Is there an absolutely Right or Wrong answer as to which should be selected? Not really. A lot of it boils down to the style of the programmers that will be working the system ... there may actually be some benefits and drawbacks to different languages/platforms - but when push comes to shove any of them will work for whatever thing you're trying to build.
So then - knowing that we're computer geeks and we have to have things in 1's and 0's - how do we decide what to choose? Given a new App, what do I do? RoR or PHP? Java or C++ CGI?
I propose you do what the jazz improvisor does when he steps up to take a solo - make it up as you go... do what you feel will make the most organized, elegant work of art out there (elegant is really just a synonym for organized which just means your code is more easily maintained, in case you need to make a business case for this or something) - does RoR get your juices going, does it make you feel like you're putting out a better product? Then use it....
So let's try again.....repeat after me: It is ok to trust my instincts when it comes to design decisions.
So the corollary here, for those of you that don't see it yet - is that, while you are enjoying this profound freedom - let's not selfishly hog it up - pass it on to your co-workers, or any other programmers you come in contact with........in other words - let's practice some people skillz (I know - we're programmers, so we were probably born without that particular gene - but let's work at it) - if you are pumped about programming in Java - don't force it down the throat of your co-worker who is a big Cobol.NET fan - try for common ground as much as possible.......and try to avoid the self-serving urge to claim that your way is the only right way - cause really... it's not.
Friday, June 20, 2008
Art or Science
A fundamental disconnect in the world of software engineering is around the actual nature of the activity that most software developers engage in...
Many assume it is a science - that one can be taught specific rules and then one can program, flawlessly, any new system that is needed.....extending that to think that as soon as compy's are fast enough - they'll be able to develop the software themselves.
Others view it more as an art - that there is a creative, human thing necessary to solve the problems that software systems are targetting to solve.
There is some value to comparing software development to past activities.... Let's say it's a science - let's think about something like simple, simple physics... we observe that something is happening: when we let go of the apple, it drops to the ground.... we hypothesize that it obeys certain rules about acceleration and momentum; we test, etc... following the good ol' scientific method that we know and love... eventually coming to an approximation of what's really going on....
so, if development is science... it might go something like this: we look at the problem and we hypothesize what will fix it... we try it.. it works, we move to the next problem.......
Compared to Art:
with art, we have typically some kind of canvas - whether it is an actual canvas, a piece of paper, a piece of rock or the air around us... and we have a palette....colors, sounds, textures, etc.. and they can be applied to the canvas in any number of ways....the end result being to arouse emotional involvement, and communicate some feeling or idea on a deeply emotional level...
so, if development is art - the computer is the canvas, and the palette is the plethora of programming languages, platforms, tools and frameworks available today... which can be applied in any number of ways - the end result being to arouse emotional involvement, and to communicate some feeling or idea on a deeply emotional level....
So - is either one of these really on the mark.... no... but yes. One of the fundamental reasons science doesn't fit - is that there are a number of ways to do a single thing.......science is about getting as close to the single "right" answer as possible. But there is definitely science in the development process, in terms of testing things and being objective, and making sure that we solve the problem we set out to.............on the flip side - one of the fundamental reasons it's not strictly art is that simply communicating emotion is not the end of software development - though it is necessary - the real end is to enable action on the part of the user (not just inspire to action - even though that is an important thing).
So - I assert(); that system development is a unique hybrid never before seen on the face of the planet... and not yet having come into its own in terms of being commonly understood in society for its unique blend of art and science....
Many assume it is a science - that one can be taught specific rules and then one can program, flawlessly, any new system that is needed.....extending that to think that as soon as compy's are fast enough - they'll be able to develop the software themselves.
Others view it more as an art - that there is a creative, human thing necessary to solve the problems that software systems are targetting to solve.
There is some value to comparing software development to past activities.... Let's say it's a science - let's think about something like simple, simple physics... we observe that something is happening: when we let go of the apple, it drops to the ground.... we hypothesize that it obeys certain rules about acceleration and momentum; we test, etc... following the good ol' scientific method that we know and love... eventually coming to an approximation of what's really going on....
so, if development is science... it might go something like this: we look at the problem and we hypothesize what will fix it... we try it.. it works, we move to the next problem.......
Compared to Art:
with art, we have typically some kind of canvas - whether it is an actual canvas, a piece of paper, a piece of rock or the air around us... and we have a palette....colors, sounds, textures, etc.. and they can be applied to the canvas in any number of ways....the end result being to arouse emotional involvement, and communicate some feeling or idea on a deeply emotional level...
so, if development is art - the computer is the canvas, and the palette is the plethora of programming languages, platforms, tools and frameworks available today... which can be applied in any number of ways - the end result being to arouse emotional involvement, and to communicate some feeling or idea on a deeply emotional level....
So - is either one of these really on the mark.... no... but yes. One of the fundamental reasons science doesn't fit - is that there are a number of ways to do a single thing.......science is about getting as close to the single "right" answer as possible. But there is definitely science in the development process, in terms of testing things and being objective, and making sure that we solve the problem we set out to.............on the flip side - one of the fundamental reasons it's not strictly art is that simply communicating emotion is not the end of software development - though it is necessary - the real end is to enable action on the part of the user (not just inspire to action - even though that is an important thing).
So - I assert(); that system development is a unique hybrid never before seen on the face of the planet... and not yet having come into its own in terms of being commonly understood in society for its unique blend of art and science....
Subscribe to:
Posts (Atom)