The open source project "Entity" has allowed a person to do this since September of 1999.
Entity is written primarily by Ian Main. In 1999 and 2000, we used it as the framework for the management console of one of our products.
Entity doesn't have a current website today, but the code is still under development and available from at least a few CVS servers. The link below has code from 1999.
http://anoncvs.gnome.gr.jp/viewcvs.cgi/entity/
Hopefully this is of some use to folks.
Regards,
scottwimer
Hmm... I haven't really thought about it from the standpoint of what I'd like to do. I'm just thinking about the outsourcing discussion.
The challenge of breaking big problems into smaller ones is that it requires scaling factors in design. And that means getting things like data structures and APIs and flow figured out earlier rather than later. That tends to be the hardest part of the whole process for me.
All that said, what I actually do is the big-problems-into-smaller-problems approach. I just recognize that while that makes some problems easier, I'm really just shuffling the bottleneck when it comes to working on really large problems. Fortunately, I haven't had to take on any super big problems, yet.
I don't see software development moving from a craftsmen oriented model to a production oriented model anytime soon.
My thinking for this is tied to the fact that most of the software development process is spent designing the software. Sometimes the design happens up front, and sometimes it happens in the middle of writing the code. Most of the time, design is spread throughout the whole process.
The problem with software as I see it right now is that the designing process gets muddled with the implementation process. There are industries where this is not the case -- commercial manufacturing springs to mind for me. But, those industries are ancient when compared with the amount of time we have spent working on software. Software development is still so young that we don't understand it well enough to define process rules and guidelines that can be generally agreed upon.
Eventually, the software development process will become mature. That'll probably take several billion more lines of code, and a couple of decades, but eventually, the design process will become something that is well understood with regular "rules" to follow.
When that happens, I think writing software will probably be a lot less fun, but designing it will probably be more interesting.
True, auto duplication is expensive. However, the point I was driving at is that trying to scale any process that depends on individual craftsmen is very, very difficult.
I think this is why I've found that in general the optimal development team size is 2-3 people. All that does though is push the scaling problem into the process management realm. Since, you now have lots of 2-3 member teams that you have to figure out how to distribute the overall project across.
Hence, getting good project managers is even more important when dealing with software development.
I think you have identified the key difference in perspectives. You can either have things built by craftsmen or things that are built according to some process.
The thing is, craftsmen don't scale very well. That is because, well, it takes a lot of time to become really good at all the different aspects of building whatever it is they are building. Craftsmen are a scarce commodity, regarless the trade. On the other hand, processes where each person does a part can scale. Further, you can get consistent output from such processes. And, since the output can be consistent, you can improve it incrementally, measuring the impact of each process or training change you implement. (Yes, I know that sometimes the output is consistently bad, but that is the explict fault fo the people/person in charge of the process, not the people in it.)
Can you imaging the price for automobiles built by "craftsmen"? Actually, you don't have to, just pick some number greater than 400,000 USD and you have it.
Craftsmen don't scale, they're a poor route to take for processes that need to scale.
All that said, I'm not yet convinced that software development has reached the point of maturity where we understand it enough to be able to move from a craftsmen oriented system to a process oriented system and still produce decent software.
Hard drive space is under a buck a gig. And, some moron is talking about the benefits of saving a few kbytes, or maybe even several megs across the whole system by replacing config files in a universal standard with a completely non-portable implementation. Brilliant!
Blech. Dumb. Dumb. Dumb.
Embedding content in Flash
on
Opencroquet
·
· Score: 1
It seems to be impossible, or at least very difficult, to embed content in Flash.
That is the conclusion I have reluctantly reached after careful observation of thousands of pages using Flash. I suspect that this isn't what Macromedia had in mind, but it seems to be the unfortunate case.
As such, I can only conclude that there is something wrong with Flash -- surely all the people who develop pages that use it aren't alergic to generating actual content.:)
scottwimer
Re:it is VERY trollish
on
The Faded Sun
·
· Score: 1
Your comment assumes that nobody who ships Linux on x86 will discover that there is lots of cash to be made in the support and maintenance. That seems like a rather silly assumption.
Cyber-risk insurance is a neat idea. There is one major problem with treating it like other sorts of risk that insurance companies write policies for -- the constant and easy loss aggregation potential.
Loss aggregation is the insurance industry's term for the ability of of a single incident to cause multiple claims across their policy book. The Sept 11 attacks are one example of the type of loss aggregation problem that really frightens them.
Cyber-risk policies present similar situations. As long as computer security is driven by the absence or presence of vulnerabilities, individual exploits can result in thousands of claims.
I spent some time discussing this in my session on preventative security for vulnerable software at LinuxWorld last week. As I said then, the insurance companies will be our strongest ally in the security space, but only if we can make computer security a solvable problem.
Don't be fooled into thinking that security problems will go away if only we can get patches for vulnerabilities applied just as soon as they are available. The recent Saphire/Slammer mess should be sufficient to indicate that businesses aren't ever going to be consistently up-to-date with the latest patches. Thinking otherwise is just silly. Security this way is the functional equivalent of taking care of a 3 month old child: feed, burp, change diaper, repeat. Worse, it's a 3 month old that never grows up.
We have a version of CylantSecure for workstations on the drawing boards currently. Right now though, our focus is on making CylantSecure a market and technical success in the server market.
That said, we have people using CylantSecure on their workstations. These folks tend to be system admins generally. Mostly, this approach just requires more policies be created since workstations tend to run more applications and a greater variety of applications than servers do.
We've been running CylantSecure on our external systems for the past couple of years. We've been eating our own dog food, so to speak. All I can say is, "mmm, tasty!":) Since early 2000 various different companies and goverenmental organizations have evaluated and experimented with CylantSecure, so far we've consistently gotten positive feedback.
To make evaluating CylantSecure easier, it has a built in 30 day fully-featured evaluation period.
The ecomomical answer isn't to invest tons of money in developing faster CPUs, it's to throw available CPU cycles at the problem -- stealing cycles from other systems.
If you use a un*x varient, check out distcc http://distcc.samba.org It should make your day much more productive.
Slashdot Mirror
Use stainless steel, or some other rust-proof and/or corrosion proof metal.
The open source project "Entity" has allowed a person to do this since September of 1999. Entity is written primarily by Ian Main. In 1999 and 2000, we used it as the framework for the management console of one of our products. Entity doesn't have a current website today, but the code is still under development and available from at least a few CVS servers. The link below has code from 1999. http://anoncvs.gnome.gr.jp/viewcvs.cgi/entity/ Hopefully this is of some use to folks. Regards, scottwimer
Hmm... I haven't really thought about it from the standpoint of what I'd like to do. I'm just thinking about the outsourcing discussion.
The challenge of breaking big problems into smaller ones is that it requires scaling factors in design. And that means getting things like data structures and APIs and flow figured out earlier rather than later. That tends to be the hardest part of the whole process for me.
All that said, what I actually do is the big-problems-into-smaller-problems approach. I just recognize that while that makes some problems easier, I'm really just shuffling the bottleneck when it comes to working on really large problems. Fortunately, I haven't had to take on any super big problems, yet.
scottwimerI don't see software development moving from a craftsmen oriented model to a production oriented model anytime soon.
My thinking for this is tied to the fact that most of the software development process is spent designing the software. Sometimes the design happens up front, and sometimes it happens in the middle of writing the code. Most of the time, design is spread throughout the whole process.
The problem with software as I see it right now is that the designing process gets muddled with the implementation process. There are industries where this is not the case -- commercial manufacturing springs to mind for me. But, those industries are ancient when compared with the amount of time we have spent working on software. Software development is still so young that we don't understand it well enough to define process rules and guidelines that can be generally agreed upon.
Eventually, the software development process will become mature. That'll probably take several billion more lines of code, and a couple of decades, but eventually, the design process will become something that is well understood with regular "rules" to follow.
When that happens, I think writing software will probably be a lot less fun, but designing it will probably be more interesting.
scottwimerTrue, auto duplication is expensive. However, the point I was driving at is that trying to scale any process that depends on individual craftsmen is very, very difficult.
I think this is why I've found that in general the optimal development team size is 2-3 people. All that does though is push the scaling problem into the process management realm. Since, you now have lots of 2-3 member teams that you have to figure out how to distribute the overall project across.
Hence, getting good project managers is even more important when dealing with software development.
scottwimerI think you have identified the key difference in perspectives. You can either have things built by craftsmen or things that are built according to some process.
The thing is, craftsmen don't scale very well. That is because, well, it takes a lot of time to become really good at all the different aspects of building whatever it is they are building. Craftsmen are a scarce commodity, regarless the trade. On the other hand, processes where each person does a part can scale. Further, you can get consistent output from such processes. And, since the output can be consistent, you can improve it incrementally, measuring the impact of each process or training change you implement. (Yes, I know that sometimes the output is consistently bad, but that is the explict fault fo the people/person in charge of the process, not the people in it.)
Can you imaging the price for automobiles built by "craftsmen"? Actually, you don't have to, just pick some number greater than 400,000 USD and you have it.
Craftsmen don't scale, they're a poor route to take for processes that need to scale.
All that said, I'm not yet convinced that software development has reached the point of maturity where we understand it enough to be able to move from a craftsmen oriented system to a process oriented system and still produce decent software.
scottwimerThis is just dumb.
Hard drive space is under a buck a gig. And, some moron is talking about the benefits of saving a few kbytes, or maybe even several megs across the whole system by replacing config files in a universal standard with a completely non-portable implementation. Brilliant!
Blech. Dumb. Dumb. Dumb.
It seems to be impossible, or at least very difficult, to embed content in Flash.
:)
That is the conclusion I have reluctantly reached after careful observation of thousands of pages using Flash. I suspect that this isn't what Macromedia had in mind, but it seems to be the unfortunate case.
As such, I can only conclude that there is something wrong with Flash -- surely all the people who develop pages that use it aren't alergic to generating actual content.
scottwimer
Your comment assumes that nobody who ships Linux on x86 will discover that there is lots of cash to be made in the support and maintenance. That seems like a rather silly assumption.
Cyber-risk insurance is a neat idea. There is one major problem with treating it like other sorts of risk that insurance companies write policies for -- the constant and easy loss aggregation potential.
Loss aggregation is the insurance industry's term for the ability of of a single incident to cause multiple claims across their policy book. The Sept 11 attacks are one example of the type of loss aggregation problem that really frightens them.
Cyber-risk policies present similar situations. As long as computer security is driven by the absence or presence of vulnerabilities, individual exploits can result in thousands of claims.
I spent some time discussing this in my session on preventative security for vulnerable software at LinuxWorld last week. As I said then, the insurance companies will be our strongest ally in the security space, but only if we can make computer security a solvable problem.
Don't be fooled into thinking that security problems will go away if only we can get patches for vulnerabilities applied just as soon as they are available. The recent Saphire/Slammer mess should be sufficient to indicate that businesses aren't ever going to be consistently up-to-date with the latest patches. Thinking otherwise is just silly. Security this way is the functional equivalent of taking care of a 3 month old child: feed, burp, change diaper, repeat. Worse, it's a 3 month old that never grows up.
Anyway, back to work.
We have a version of CylantSecure for workstations on the drawing boards currently. Right now though, our focus is on making CylantSecure a market and technical success in the server market.
That said, we have people using CylantSecure on their workstations. These folks tend to be system admins generally. Mostly, this approach just requires more policies be created since workstations tend to run more applications and a greater variety of applications than servers do.
scottwimer
Disclaimer: I am the CTO Cylant.
:) Since early 2000 various different companies and goverenmental organizations have evaluated and experimented with CylantSecure, so far we've consistently gotten positive feedback.
We've been running CylantSecure on our external systems for the past couple of years. We've been eating our own dog food, so to speak. All I can say is, "mmm, tasty!"
To make evaluating CylantSecure easier, it has a built in 30 day fully-featured evaluation period.
scottwimer
The ecomomical answer isn't to invest tons of money in developing faster CPUs, it's to throw available CPU cycles at the problem -- stealing cycles from other systems.
If you use a un*x varient, check out distcc
http://distcc.samba.org
It should make your day much more productive.