managing ideas
August 13, 2007 11:41 AM Subscribe
How do I harness ideas into productive implementations?
I have *a lot* of ideas, and tend to work out problems to the very end, and have very detailed thoughts regarding them.
For example when I need to do a task, like dishes, I more or less map out what order will be most effective (limit wasted space, washing time, cleaning water time, stacking order in the strainer to some extent, etc). This tendancy works GREAT for small tasks (think consultant: install Symantec Antivirus the most efficient way on 500 workstations). However I have been given larger and larger management roles, as well as problems I want to tackle myself that this is really killing my productivity, and finally my project entirely.
An example would be some thin clients I setup (running ThinStation, a Linux based workstation image). I found that I can VNC to them remotely, but I don't know each machine's name. So I think, lets make an excel spreadsheet of each machine/mac/ip (and feed this into microsoft's DHCP server).
This progresses into, maybe I should do it in Access, or MSSql with an Access frontend. Maybe a web front end. I might as well do PHP/MySQL, and write all the scripts to manage the DHCP allocations automatically.
But then I might as well build on inventory management, so I know where each piece of hardware is logically. Then since I am doing that, and I need monitoring anyways, I could feed this information into Nagios (or some other software) to intelligently monitor all these systems. Since I have multiple sites, and multiple DHCP servers I need to figure out how to manage the creation of DHCP allocations. I should just write my own DHCP server (I've started one before for personal projects) that can work better together.
It just goes on and on from there. I can't limit my scope to the immediate challenge, and move from there, so I will get overwhelmed where to start. It doesn't make sense to have a static inventory in Excel if I am ever going to use it to create DHCP inserts (I currently do this for our IP phones, and it doesn't work well when I start shuffling them around).
So how do I take this grandiose idea, and productively work towards it? It is more managable in situations like this, where *I* know all the goals, but what about when its a company wide project that I don't know all the factors?
I feel like I have hundreds of great idea's a day, but they blow up, and quickly become impossible. Working with groups I have a hard time sticking to my small contribution, and find myself trying to manage the entire group, find the perfect way to do everything... it frustrates me to no end when I see things going astray.
(examples that might kill my ambition....)
How do I build an operating system without building a perfect Kernel/Hypervisor?
How do I build a small web-app and pick the right development tools (do I use CakePHP? do I use modules from Pear?)
I have *a lot* of ideas, and tend to work out problems to the very end, and have very detailed thoughts regarding them.
For example when I need to do a task, like dishes, I more or less map out what order will be most effective (limit wasted space, washing time, cleaning water time, stacking order in the strainer to some extent, etc). This tendancy works GREAT for small tasks (think consultant: install Symantec Antivirus the most efficient way on 500 workstations). However I have been given larger and larger management roles, as well as problems I want to tackle myself that this is really killing my productivity, and finally my project entirely.
An example would be some thin clients I setup (running ThinStation, a Linux based workstation image). I found that I can VNC to them remotely, but I don't know each machine's name. So I think, lets make an excel spreadsheet of each machine/mac/ip (and feed this into microsoft's DHCP server).
This progresses into, maybe I should do it in Access, or MSSql with an Access frontend. Maybe a web front end. I might as well do PHP/MySQL, and write all the scripts to manage the DHCP allocations automatically.
But then I might as well build on inventory management, so I know where each piece of hardware is logically. Then since I am doing that, and I need monitoring anyways, I could feed this information into Nagios (or some other software) to intelligently monitor all these systems. Since I have multiple sites, and multiple DHCP servers I need to figure out how to manage the creation of DHCP allocations. I should just write my own DHCP server (I've started one before for personal projects) that can work better together.
It just goes on and on from there. I can't limit my scope to the immediate challenge, and move from there, so I will get overwhelmed where to start. It doesn't make sense to have a static inventory in Excel if I am ever going to use it to create DHCP inserts (I currently do this for our IP phones, and it doesn't work well when I start shuffling them around).
So how do I take this grandiose idea, and productively work towards it? It is more managable in situations like this, where *I* know all the goals, but what about when its a company wide project that I don't know all the factors?
I feel like I have hundreds of great idea's a day, but they blow up, and quickly become impossible. Working with groups I have a hard time sticking to my small contribution, and find myself trying to manage the entire group, find the perfect way to do everything... it frustrates me to no end when I see things going astray.
(examples that might kill my ambition....)
How do I build an operating system without building a perfect Kernel/Hypervisor?
How do I build a small web-app and pick the right development tools (do I use CakePHP? do I use modules from Pear?)
Yes, as Tomorrowful says. I think it was Martin Fowler in Refactoring who said (paraphrasing) "Do the simplest thing that could possibly work." Grow from there as needed, with necessity being the driver.
Look, you don't have time to do everything you think of doing. You don't have the authority to fix every problem that you see. You will cause yourself harm and frustration if you try.
posted by trinity8-director at 12:28 PM on August 13, 2007
Look, you don't have time to do everything you think of doing. You don't have the authority to fix every problem that you see. You will cause yourself harm and frustration if you try.
posted by trinity8-director at 12:28 PM on August 13, 2007
http://catb.org/jargon/html/C/creeping-featurism.html
posted by rhizome at 12:48 PM on August 13, 2007
posted by rhizome at 12:48 PM on August 13, 2007
Mostly your problem comes down to learning to accept that the good is not the enemy of the perfect.
Three of the principles I bring to bear in any system design:
Simplicity is a sign you're doing something right
If you can express it on the back of a napkin, if a simple diagram on a whiteboard, is enough to "get it", then your design is probably a good one. If you can't describe something without bringing loads of other information to bear, or "assuming" many changes in other, existing systems... then you've made something inherently unstable, because it has tendrils and dependencies on other areas beyond the realm of what your human brain can ever comprehend.
Build a village, not a mansion
This is key. Define the general areas of a solution, not the small working parts, and envision those as big building blocks. The other building blocks don't need to know, or care, how the inner workings of the blocks are structured; they only need to know how to get information or action in and out of the other blocks.
This way, you don't get hamstrung on whether or not any one part is a mess of duct tape and baling wire on the inside; so long as its interfaces are understood and concrete, you can innovate and improve "under the hood" on an as-needed basis. You won't find yourself stuck constantly thinking of how you could improve upon the engine of each part.
Define things once, and only once
Your original post highlights why this is a problem: you've already talked about how you would have to manage tracking say the IPs in some database, table, etc. The problem, and it's a huge one I see in poorly run systems everywhere, is that you're defining the information in two different places- you've created, through sloppiness, the need to manually maintain data integrity. Somewhere, somehow, define the mappings of data, and let those be the single source that in some way controls everything.
Uh... what's your problem statement
The better we ask our questions, the better our answers will be. I'm not clear even what problem you started out trying to solve. I'm not sure you are either, which can't be helping your scope creep problem.
You want to VNC to your clients. To do this, you need either a name or an IP. I don't understand how you "don't know the name". Why are you trying to VNC to something, if you can't even think of the logical identifier of what you're trying to reach? As it is right now, your original problem statement is "There are lots of people with phone numbers. Sometimes, I pick up the phone, and I don't know who I want to talk to."
Define your original problem statement, and then ask "Is this information already present? If so, then I shouldn't re-author the data elsewhere (csv, spreadsheet, excel, website, etc). You should simply ask "How can I most easily retrieve the information from where it already is?"
It's kind of like a cargo cult: a part of you is so sure that "success" looks a certain way, you think you have to build web interfaces and cool looking tools, because you assume that's what it should look like. Instead, just focus on what the problem you're trying to solve now is, and don't let yourself get distracted by the remembered forms of what you've seen before.
posted by hincandenza at 5:11 PM on August 13, 2007 [2 favorites]
Three of the principles I bring to bear in any system design:
- Simplicity is a sign you're doing something right
- Build a village, not a mansion
- Define things once, and only once
Simplicity is a sign you're doing something right
If you can express it on the back of a napkin, if a simple diagram on a whiteboard, is enough to "get it", then your design is probably a good one. If you can't describe something without bringing loads of other information to bear, or "assuming" many changes in other, existing systems... then you've made something inherently unstable, because it has tendrils and dependencies on other areas beyond the realm of what your human brain can ever comprehend.
Build a village, not a mansion
This is key. Define the general areas of a solution, not the small working parts, and envision those as big building blocks. The other building blocks don't need to know, or care, how the inner workings of the blocks are structured; they only need to know how to get information or action in and out of the other blocks.
This way, you don't get hamstrung on whether or not any one part is a mess of duct tape and baling wire on the inside; so long as its interfaces are understood and concrete, you can innovate and improve "under the hood" on an as-needed basis. You won't find yourself stuck constantly thinking of how you could improve upon the engine of each part.
Define things once, and only once
Your original post highlights why this is a problem: you've already talked about how you would have to manage tracking say the IPs in some database, table, etc. The problem, and it's a huge one I see in poorly run systems everywhere, is that you're defining the information in two different places- you've created, through sloppiness, the need to manually maintain data integrity. Somewhere, somehow, define the mappings of data, and let those be the single source that in some way controls everything.
Uh... what's your problem statement
The better we ask our questions, the better our answers will be. I'm not clear even what problem you started out trying to solve. I'm not sure you are either, which can't be helping your scope creep problem.
It just goes on and on from there. I can't limit my scope to the immediate challenge, and move from there, so I will get overwhelmed where to start.How about "start there"? You have some problem. Define it, and ONLY that immediate problem. Then you can spend a little time thinking what the real problem is, and focus on the quickest solution to that. The one thing missing from the previous answers is that some of the ugliest, most hard to maintain systems, are those which started as something simple with small iterations and patchwork fixes, all of which were at the time very simple solutions to the problem.
You want to VNC to your clients. To do this, you need either a name or an IP. I don't understand how you "don't know the name". Why are you trying to VNC to something, if you can't even think of the logical identifier of what you're trying to reach? As it is right now, your original problem statement is "There are lots of people with phone numbers. Sometimes, I pick up the phone, and I don't know who I want to talk to."
Define your original problem statement, and then ask "Is this information already present? If so, then I shouldn't re-author the data elsewhere (csv, spreadsheet, excel, website, etc). You should simply ask "How can I most easily retrieve the information from where it already is?"
It's kind of like a cargo cult: a part of you is so sure that "success" looks a certain way, you think you have to build web interfaces and cool looking tools, because you assume that's what it should look like. Instead, just focus on what the problem you're trying to solve now is, and don't let yourself get distracted by the remembered forms of what you've seen before.
posted by hincandenza at 5:11 PM on August 13, 2007 [2 favorites]
This thread is closed to new comments.
If and when those problems arise, fix them and them only, modifying pieces of previous solutions only if needed.
If you find yourself trying to expand the scope, just tell yourself "No. That comes later." Cure the pain you have, not the pain you *think* you'll have.
posted by Tomorrowful at 11:45 AM on August 13, 2007