I'm in the process of developing a suite of content management systems targeted specifically at Software Development Teams.
I'm using Mozilla as my platform. The QBAL applications will be accessible thru both a GUI (Mozilla/XUL) and command line. My background has been in Unix development environments in Silicon Valley since 1984... From that I hope to bring forth experiences in the form of tools to improve that day-to-day work experience for development team members
Currently I've defined 27 QBAL applications as part of the suite. Clients will be able to select the QBAL applications that best fit their needs.
I've been involved over the years in implementing both processes and infrastructure to support engineering teams
Following are some items that may be of help to you
* I like to think of a software development environment as a 4 lane highway in the desert, where its easy to change lanes and easy to get off the highway if need be, and easy to get back on the highway. The opposite of this is a tight-rope, that is hard to get on, hard to stay, inflexible.
In my experiences, most development environments I've worked in are a tight-rope, as they don't really provide an environment that help the developers productivity and quality.
* I like to start out by identifying what process, practice, tool will make the project leads day-to-day work better. Working with the project lead to enlist team members to accept the change and then implement on their behalf
* Start out be creating a well known repository to store all artifacts related to the change: documents, email, presentations, etc... it can even be a directory structure at first
* Once some credibility and confidence is obtained look for bigger wins in terms of improvement.
* Try to avoid creating the tight-rope. For example, some folks may want to write a spec in text format, others in a word processor, or html. Let it be a 4 lane highway. So you focus more on getting buyin for spec writing, then what tool or format it is in. Later on will be opportuntiy to refine.
* You can strive for breadth, depth or both in terms of what process, practice, tool you want to change or implement. Let the owners of the project help you (project leads) determine how far or how deep to go.
* Create a process change roadmap based on the product roadmap and so you can be sure as to not impact the development teams during critical stages of the release cycle. So is your product roadmap over the next 12 months is to release multiple version of the product, along with patch releases, the process roadmap should span all of the efforts.
I'm inclined to think Mono and associated technologies are more about a business agenda and less about developing a productive development environment. The side-affect of developing a.NET clone, appears to me... is that it will spur the growth of Linux based systems in the commerical markets. Another side-affect is that this effort could spur on the Java technologies to appear more quickly.
I've been keeping an eye on subversion, as the goals are noteworthy. Fundamentally Bitkeeper and now 'arch' model is very powerful. I used Sun's Teamware (Bitkeeper is an enhance Teamware) in organizations with over 100 developers, and remote development and it required almost zero administrative overhead. The core of Sun's Teamware, Bitkeeper, HP's old KCS, Sun's Smerge/Smoosh, and 'arch' is simply the branch/merge capabilities. Once this problem is solved, then the rest of the services can be built around it. This is where most SCM systems fall flat on their face... They lock you into a centralized server model, user interface that is clumsy, terminology that is cumbersome, policies that don't meet the consumers needs, etc...
I view 'arch' as having a great model with a very simple implementation. Because of the simplicty, 'arch' developers will be able to respond very quickly with bug fixes and new functionality, and others can build around 'arch' to support their own policies, and process flows
Having just gone thru the regexps arch docs it looks like Tom has done an excellent job.
The concepts Tom discusses are right on target. It appears there is plenty of flexibility to implement policy based on project requirements.
At first glance (have not installed yet) 'arch' has many of the same concepts as does BitKeeper and Sun's Teamware.
I'd like to see software like this dual licensed i.e Qt/BitKeeper style licenses.
Regards,
Kramer
Architects of Technology vs. Architects of Product
on
Linus Does Not Scale
·
· Score: 2, Interesting
Linus and team are architects of technology, the distributions are architects of product. This same scenario goes on in the large Unix system development houses too.
Often there is conflict between the two in terms of goals/objectives, key values, processes, tools, practices, timelines, etc...
Understanding the key values of each team is critical in developing the correct practices, tools, and processes for the teams.
The challenge, I think, for the Open Source Community is to develop tools that will respond to different team values and practices, which results in providing support for the individuals to achieve their objective.
I've been directly and indirectly involved in two CMM efforts in Silicon Valley
Both failed. One achieved CMM Level 2 in 14 months and then reverted backwards. I've
met with people from other companies that started down this path and then backed away.
In both cases, software estimation techniques proposed produced inaccuracies and required
to much rigidty in perspective, resulting in frustrated engineering, management and program
management team members... i.e it did not stick...
Secondly, the efforts required by individual contributors did not enhance day-to-day
work experiences. i.e no return-on-investment for the individual contributor
The people I've encountered that are CMM experts base much of their training on theory
instead of day-to-day experiences that do occur in this industry and in this valley.
CMM like Demings work in Japan, requires a homegenous culture to succeed. There are
few places where this exist in Silicon Valley (some goverment contractors).
Where does CMM certification payoff... when you are doing business with a company like a
Motorola... But there are other ways to demonstrate control of your development processes
IMO... In this valley, trying to turn software development teams into an manufacturing assembly
line is a waste of time. Put time and effort into empowering each and every individual by providing
the environment they need to be creative, accurate, and efficient.
I understand the point you are attempting to present, but your argument assumes someone that is self taught does not have access to the same information that a college program has.
Knowing and Doing are two completely different things.
Here are two links that may present different insight into the industry:
http://www.dreamsongs.com/WorseIsBetter.html
http://www.joelonsoftware.com
You will be incredibly suprised once you have been in the computer industry for a few years, how badly designed, written, and tested, alot of software is. This is due to the nature of the business. Many prototypes because of business opportunities are shipped, code is purchased as a baseline to new product and the team will not have time to clean it up, bugs and eagerly waiting customers will result in many short cuts being taken. Team members effectiveness will be impacted by timelines, politics, personal issues... etc...
I thought I'd share some experiences encountered over the past 20 years of working in Silicon Valley at companies like HP and Sun Microsystems.
I did not pursue a college education, and in some cases it directly affected opportunities, other times it had nothing to do with getting the opportunity.
It did though take me some time to move up the pay grades as an engineer.
If I could do it all over again...
I'd have started going to college right out of high school (even if it was only part-time) and would have worked towards two degrees. One in a hard-core CS environment and the other in a Liberal Arts program (philosophy, communications).
My motiviation would not be so much as to obtain specific work, or position myself to obtain opportunities within the corporate environment, but to provide myself with a foundation that assist me in being highly effective in whatever I choose to accomplish.
Over years I've observed many people changing careers. I watched young students come out of school, accomplish many of their goals as engineers. Eventually they would begin to look around for other opportunities, such as: management, marketing, sales. And from there another steep learning curve had begun. This is where the non-technical skills really became neccessary to be effective.
Some of the most accomplished people I've had the opportunity to work with have mapped out 5 year goals that included developing themselves to be prepared for tackle those goals.
Many people I've worked with over the past 20 years in the computer industry have gone on to be very sucessful without a CS degree, but a degree in another field, in some cases I've observed people without any formal education also become very successful.
I'm sure some types of employers for specific types of work would like to insist
on educational, certification and experience requirements.
But I don't see how the US market can tolerate the bottleneck things like this
will create. There is already a shortage of skilled computer people (technicians,
engineers, tech writers, sales, marketing, administrators, managers, etc...). The
industry cannot wait for people to obtain all the knowledge and skills that
certification may require.
So I think ultimately the market will determine where the value is.
What is interesting is, here we have a community of people that probably studies
and continually develops new skills as much or more than any industry, and people
are looking to solve quality problems via certification, in a market thats moves
very fast with a shortage of skilled people...
You may want to consider taking the approach of determining the needs of the
consumers of the source tree and then ensuring that the end-result is
repeatable, managable and empowers the consumers to maintain and extend
the solution. (i.e if the consumers are primarily Linux developers/users, then
autoconf tools are the standard).
The choice of technology used implement the build system,
in my opionion, should revolve around the consumers preferences, as this will
ensure that they can most easily make use of the solution.
If time and budget allow, using alternative technologies can achieve the desired
end-result, but will require training the consumers to achieve an empowered
system (i.e a system that does not require specialized knowledge to use, maintain
or extend)
My target build sytem consumers have been commerical companies. I use GnuMake and have
not had to use autotools yet... as all build dependencies are managed and known up-front, so
discovery is not part of the overall process or approach.
One area I find most commerically implemented build systems lacking is, to narrow of focus.
The life cycle of a source tree spans numerous organizations (dev, re, test, qa, perf, cust support,
tech marketing) yet barely meets development and release engineering needs. If building
a system for a commerical environment, talking with all consumers will help in defining requirements
for a complete system.
My issue is with RMS/FSF and the GNU license not being in-line with each other. The GNU license
is not anti-business, RMS/FSF is anti-business (i.e software and source code are free)
I have been really impressed with the software, education, and solutions this community has delivered over the last decade!!! Over the years I've used quite a bit of GNU licensed software.
Recently I really began to think about what it means to both license software under GNU and use GNU software
I really started to struggle with the RMS agenda and my own values, as I am not anti-business. In
my expierences I've not encountered any software engineers that are anti-business... we make
our living building software solutions. If a person wants to contribute their own software to a community then great, if not, they should have the opportunity to charge for that software and thats great too!
I don't see the RMS agenda of all-software being free, succeeding, as we can see that businesses are leveraging off of GNU software. IBM is a great example of a company leveraging the GNU software. IBM sells iron that runs Linux... $$, and then sells the support... $$, and then sells proprietary software that runs on Linux... $$
What I think would be more productive for contributors to the Linux community is to establish a
non-profit organization, where contributions can be made for the work being done, and to work
with the business community to partner in developing future solutions.
Many of the GNU and Unix world is focused on competing with Microsoft? So what is occuring,
Linux is eating away at Unix market share, and Microsoft is still growing. Some years from know
Linux will begin to eat into Microsoft Desktop/Server market... then what?
Go after Oracle,
IBM,... what is the Vision, who does it benefit? Is GNU all about overthrowing business? Is
developing GNU software a means to disrupt and/or eliminate business?
I think it is time for the community to rethink their experiences over the last 10 years and ask
themselves what they are really trying to accomplish. Competition is great, i.e Linux vs
Microsoft, and doing that in both a non-business and business approach is great. I think its
time to clartify the grey areas of current agendas, ie. anti-business, educational, business,
hobbiest. GNU is currently all of these, but the FSF is not! I think now is the time for the community and their license to reflect their values.
It's the MIMIC factor!!! This has been going on for decades!!!
Problem: Unix System Architects are Architects of Technology. Architects of Product
do not exist in the Unix System Houses (i.e Sun, HP, Dec, AT&T, etc...)
Product in these large Unix houses come together thru the involvement of many people in
many different parts of the companies. Anyone wishing to understand the entire process
would be hard pressed to do so.... because of the breadth of people and organizations involved, and limited accurate documentation
Fundamentally the layout of filesystem, contents, installation and patching is one big reactionary,
mostly chaotic process that occurs late in the life cycle.
I've worked as a System Administrator, Buildmeister, Release Engineer, Configuration Management Engineer, Program Manager in the Unix world starting in 1984. I worked in and with Kernel Development, Network Development, System Installation, and assorted Unix Application teams during this time frame.
Where files will reside, how they will be installed, and patched are almost always the last things considered in the development process. The decision process is mostly MIMIC'd. The people involved are generally just trying get the thing ready for QA and Release.
Downstream organizations that attempt to resolve product issues, face extremely difficult challenges when attempting to influence upstream development teams.
Working in a large unix system house, one can mostly determine which group owns the
technology... but try and identify who owns the product... it will be a group of committees and
teams...
Because these issues are not properly designed up front, the result is downsteam reactiveness.
The end result is new efforts MIMIC the past efforts in this area, all the current Linux distributions
are examples of the MIMIC factor.
Solution: Work with your System Architects to influence change in this area.
There are many ways to do this, without going directly into system admin.
1. consider going the test engineer route. possibly as a black box test engineer, qa/test is a great career path as there is a real shortage of sr. people.
2. consider tech writing, leveraging from your teaching background
3. consider technical teaching, as this also leverages your background. large compaines will spin you up technically.
4. consider developing technical courses, again large companies have opportunities in these areas.
Just get your foot in the door, one way or the other and continue to work towards what interest you.
I started out on the MIS side and moved into system administration in 84' and in 85 into lab administration, and did that for 9 months. The experience paid of greatly in future positions. There are many types of system administration jobs, in larger companies: unix mail administrators, unix network administrations, database, develop lab, qa/test lab, end-user administrators, technical marketing, there are folks that go on the road to setup systems for trade-shows... quite a bit to choose from
My Sr. year of high school(1975/76) I worked at the HP Calculator Division in Cupertino... Best
job I ever had...
I delivered coffee and donuts twice a day and served deli sandwiches on the lunch line.
A couple of buddies liberated a keg from one of
the beer bashes, when it was empty, the keg was
put to use as a tv stand.
One of the maintenance guys (Bob) accused us of taking
the keg... we denied it for 18 years. At our 30th
birthday bash (flirty, dirty and thirty), we finally admitted it to Bob... yeh... you had been
right all along...
I was very interested at first glance, I downloaded
the Rebol Core, got on a few lists, and observed
the dialog for a couple of months, and unsubscribed. Its still very early, I'd like to have seen some applications of size and complexity but what I mostly saw reminded me of the early Java applet phase. I wish I could remember a recent url where reviews of Rebol are
discussed... it reminded me of a 30 minute info-merical... I've heard those George Forman grills are pretty good... Don't know about that juice guy though... the eyebrows freak me out
Slashdot Mirror
www.qbal.com best viewed in Mozilla, Netscape6+, or IE5+
Regards,
Kramer
I'm in the process of developing a suite of content management systems targeted specifically at Software Development Teams.
I'm using Mozilla as my platform. The QBAL applications will be accessible thru both a GUI
(Mozilla/XUL) and command line. My background has been in Unix development environments in Silicon Valley since 1984... From that I hope to bring forth experiences in the form of tools to improve that day-to-day work experience for development team members
Currently I've defined 27 QBAL applications as part of the suite. Clients will be able to select the QBAL applications that best fit their needs.
Regards,
Kramer
I've been involved over the years in implementing both processes and infrastructure to support engineering teams
Following are some items that may be of help to you
* I like to think of a software development environment as a 4 lane highway in the desert,
where its easy to change lanes and easy to get
off the highway if need be, and easy to get back
on the highway. The opposite of this is a tight-rope, that is hard to get on, hard to stay,
inflexible.
In my experiences, most development environments I've worked in are a tight-rope, as they don't
really provide an environment that help the developers productivity and quality.
* I like to start out by identifying what process, practice, tool will make the project
leads day-to-day work better. Working with the
project lead to enlist team members to accept
the change and then implement on their behalf
* Start out be creating a well known repository
to store all artifacts related to the change:
documents, email, presentations, etc... it can
even be a directory structure at first
* Once some credibility and confidence is obtained
look for bigger wins in terms of improvement.
* Try to avoid creating the tight-rope. For example, some folks may want to write a spec in
text format, others in a word processor, or html.
Let it be a 4 lane highway. So you focus more on
getting buyin for spec writing, then what tool
or format it is in. Later on will be opportuntiy
to refine.
* You can strive for breadth, depth or both in terms of what process, practice, tool you want
to change or implement. Let the owners of the project help you (project leads) determine how
far or how deep to go.
* Create a process change roadmap based on the product roadmap and so you can be sure as to not impact the development teams during critical stages of the release cycle. So is your product roadmap over the next 12 months is to release multiple version of the product, along with patch releases, the process roadmap should span all of
the efforts.
Best of Luck!
Kramer
www.qbal.com
I think you have a good point here. Gnome + Mono + Star Office + Java makes alot of sense for Sun.
Sun has been struggling with the desktop for many years:
- Sunview
- NeWs (network extensible window system, postscript)
- OpenLook
- CDE
- Now Gnome
This could be a winning ticket for them and the Open Source community
I'm inclined to think Mono and associated technologies are more about a business agenda and less about developing a productive development environment. The side-affect of developing a .NET clone, appears to me... is that it will spur the growth of Linux based systems in the commerical markets. Another side-affect is that this effort could spur on the Java technologies to appear more quickly.
Regards,
Kramer
i just took at look at the code. it appears to be well written. i look forward to hearing why Tom choose to sh/awk/sed/... though...
Kramer
I've been keeping an eye on subversion, as the goals are noteworthy. Fundamentally Bitkeeper and now 'arch' model is very powerful. I used Sun's Teamware (Bitkeeper is an enhance Teamware) in organizations with over 100 developers, and remote development and it required almost zero administrative overhead. The core of Sun's Teamware, Bitkeeper, HP's old KCS, Sun's Smerge/Smoosh, and 'arch' is simply the branch/merge capabilities. Once this problem is solved, then the rest of the services can be built around it. This is where most SCM systems fall flat on their face... They lock you into a centralized server model, user interface that is clumsy, terminology that is cumbersome, policies that don't meet the consumers needs, etc...
I view 'arch' as having a great model with a very simple implementation. Because of the simplicty, 'arch' developers will be able to respond very quickly with bug fixes and new functionality, and others can build around 'arch' to support their own policies, and process flows
Regards,
Kramer
Having just gone thru the regexps arch docs it looks like Tom has done an excellent job.
The concepts Tom discusses are right on target. It appears there is plenty of flexibility to implement policy based on project requirements.
At first glance (have not installed yet) 'arch' has many of the same concepts as does BitKeeper and Sun's Teamware.
I'd like to see software like this dual licensed i.e Qt/BitKeeper style licenses.
Regards,
Kramer
Linus and team are architects of technology, the distributions are architects of product. This same scenario goes on in the large Unix system development houses too.
Often there is conflict between the two in terms of goals/objectives, key values, processes, tools, practices, timelines, etc...
Understanding the key values of each team is critical in developing the correct practices, tools, and processes for the teams.
The challenge, I think, for the Open Source Community is to develop tools that will respond to different team values and practices, which results in providing support for the individuals to achieve their objective.
Regards,
Kramer
RMS toughts are good... his Agenda is self serving... IHO
.doc to PDF conversion...
>
Asking folks to send documents in PostScript, PDF, or HTML formats
is all that is needed...
Perhaps a service for a mail provider is to supply is
Kramer
I've been directly and indirectly involved in two CMM efforts in Silicon Valley
Both failed. One achieved CMM Level 2 in 14 months and then reverted backwards. I've
met with people from other companies that started down this path and then backed away.
In both cases, software estimation techniques proposed produced inaccuracies and required
to much rigidty in perspective, resulting in frustrated engineering, management and program
management team members... i.e it did not stick...
Secondly, the efforts required by individual contributors did not enhance day-to-day
work experiences. i.e no return-on-investment for the individual contributor
The people I've encountered that are CMM experts base much of their training on theory
instead of day-to-day experiences that do occur in this industry and in this valley.
CMM like Demings work in Japan, requires a homegenous culture to succeed. There are
few places where this exist in Silicon Valley (some goverment contractors).
Where does CMM certification payoff... when you are doing business with a company like a
Motorola... But there are other ways to demonstrate control of your development processes
IMO... In this valley, trying to turn software development teams into an manufacturing assembly
line is a waste of time. Put time and effort into empowering each and every individual by providing
the environment they need to be creative, accurate, and efficient.
Regards,
Kramer
that was funny as hell! and so is the rest
of the stuff on this site!!!
I understand the point you are attempting to present, but your argument assumes someone that is self taught does not have access to the same information that a college program has.
Knowing and Doing are two completely different things.
Here are two links that may present different insight into the industry:
http://www.dreamsongs.com/WorseIsBetter.html
http://www.joelonsoftware.com
You will be incredibly suprised once you have been in the computer industry for a few years, how badly designed, written, and tested, alot of software is. This is due to the nature of the business. Many prototypes because of business opportunities are shipped, code is purchased as a baseline to new product and the team will not have time to clean it up, bugs and eagerly waiting customers will result in many short cuts being taken. Team members effectiveness will be impacted by timelines, politics, personal issues... etc...
Regards,
qbalus
I thought I'd share some experiences encountered over the past 20 years of working in Silicon Valley at companies like HP and Sun Microsystems.
I did not pursue a college education, and in some cases it directly affected opportunities, other times it had nothing to do with getting the opportunity.
It did though take me some time to move up the pay grades as an engineer.
If I could do it all over again...
I'd have started going to college right out of high school (even if it was only part-time) and would have worked towards two degrees. One in a hard-core CS environment and the other in a Liberal Arts program (philosophy, communications).
My motiviation would not be so much as to obtain specific work, or position myself to obtain opportunities within the corporate environment, but to provide myself with a foundation that assist me in being highly effective in whatever I choose to accomplish.
Over years I've observed many people changing careers. I watched young students come out of school, accomplish many of their goals as engineers. Eventually they would begin to look around for other opportunities, such as: management, marketing, sales. And from there another steep learning curve had begun. This is where the non-technical skills really became neccessary to be effective.
Some of the most accomplished people I've had the opportunity to work with have mapped out 5 year goals that included developing themselves to be prepared for tackle those goals.
Many people I've worked with over the past 20 years in the computer industry have gone on to be very sucessful without a CS degree, but a degree in another field, in some cases I've observed people without any formal education also become very successful.
Cowabunga,
qbalus
Check out this site. Lots of great advice
0 02 47.html
http://www.joelonsoftware.com/navLinks/fog00000
Here is an interesting link that leads to others links
http://www.dreamsongs.com/WorseIsBetter.html
I'm sure some types of employers for specific types of work would like to insist on educational, certification and experience requirements.
But I don't see how the US market can tolerate the bottleneck things like this will create. There is already a shortage of skilled computer people (technicians, engineers, tech writers, sales, marketing, administrators, managers, etc...). The industry cannot wait for people to obtain all the knowledge and skills that certification may require.
So I think ultimately the market will determine where the value is.
What is interesting is, here we have a community of people that probably studies and continually develops new skills as much or more than any industry, and people are looking to solve quality problems via certification, in a market thats moves very fast with a shortage of skilled people...
food for thought:
define generic relationships using pattern matching
$(OBJ_DEST_DIR)%.o: $(OBJ_DEST_DIR)%.d
$(CC_RULE)
$(OBJ_DEST_DIR)%.d: %.c
$(CC_DEP_RULE)
You may want to consider taking the approach of determining the needs of the
consumers of the source tree and then ensuring that the end-result is
repeatable, managable and empowers the consumers to maintain and extend
the solution. (i.e if the consumers are primarily Linux developers/users, then
autoconf tools are the standard).
The choice of technology used implement the build system,
in my opionion, should revolve around the consumers preferences, as this will
ensure that they can most easily make use of the solution.
If time and budget allow, using alternative technologies can achieve the desired
end-result, but will require training the consumers to achieve an empowered
system (i.e a system that does not require specialized knowledge to use, maintain
or extend)
My target build sytem consumers have been commerical companies. I use GnuMake and have
not had to use autotools yet... as all build dependencies are managed and known up-front, so
discovery is not part of the overall process or approach.
One area I find most commerically implemented build systems lacking is, to narrow of focus.
The life cycle of a source tree spans numerous organizations (dev, re, test, qa, perf, cust support,
tech marketing) yet barely meets development and release engineering needs. If building
a system for a commerical environment, talking with all consumers will help in defining requirements
for a complete system.
My issue is with RMS/FSF and the GNU license not being in-line with each other. The GNU license is not anti-business, RMS/FSF is anti-business (i.e software and source code are free)
Regards, Kramer
I have been really impressed with the software, education, and solutions this community has delivered over the last decade!!! Over the years I've used quite a bit of GNU licensed software. Recently I really began to think about what it means to both license software under GNU and use GNU software
... what is the Vision, who does it benefit? Is GNU all about overthrowing business? Is
developing GNU software a means to disrupt and/or eliminate business?
I really started to struggle with the RMS agenda and my own values, as I am not anti-business. In my expierences I've not encountered any software engineers that are anti-business... we make our living building software solutions. If a person wants to contribute their own software to a community then great, if not, they should have the opportunity to charge for that software and thats great too!
I don't see the RMS agenda of all-software being free, succeeding, as we can see that businesses are leveraging off of GNU software. IBM is a great example of a company leveraging the GNU software. IBM sells iron that runs Linux... $$, and then sells the support... $$, and then sells proprietary software that runs on Linux... $$
What I think would be more productive for contributors to the Linux community is to establish a non-profit organization, where contributions can be made for the work being done, and to work with the business community to partner in developing future solutions.
Many of the GNU and Unix world is focused on competing with Microsoft? So what is occuring, Linux is eating away at Unix market share, and Microsoft is still growing. Some years from know Linux will begin to eat into Microsoft Desktop/Server market... then what?
Go after Oracle, IBM,
I think it is time for the community to rethink their experiences over the last 10 years and ask themselves what they are really trying to accomplish. Competition is great, i.e Linux vs Microsoft, and doing that in both a non-business and business approach is great. I think its time to clartify the grey areas of current agendas, ie. anti-business, educational, business, hobbiest. GNU is currently all of these, but the FSF is not! I think now is the time for the community and their license to reflect their values.
Regards, Kramer
It's the MIMIC factor!!! This has been going on for decades!!!
Problem: Unix System Architects are Architects of Technology. Architects of Product do not exist in the Unix System Houses (i.e Sun, HP, Dec, AT&T, etc...)
Product in these large Unix houses come together thru the involvement of many people in many different parts of the companies. Anyone wishing to understand the entire process would be hard pressed to do so.... because of the breadth of people and organizations involved, and limited accurate documentation
Fundamentally the layout of filesystem, contents, installation and patching is one big reactionary, mostly chaotic process that occurs late in the life cycle. I've worked as a System Administrator, Buildmeister, Release Engineer, Configuration Management Engineer, Program Manager in the Unix world starting in 1984. I worked in and with Kernel Development, Network Development, System Installation, and assorted Unix Application teams during this time frame.
Where files will reside, how they will be installed, and patched are almost always the last things considered in the development process. The decision process is mostly MIMIC'd. The people involved are generally just trying get the thing ready for QA and Release.
Downstream organizations that attempt to resolve product issues, face extremely difficult challenges when attempting to influence upstream development teams.
Working in a large unix system house, one can mostly determine which group owns the technology... but try and identify who owns the product... it will be a group of committees and teams...
Because these issues are not properly designed up front, the result is downsteam reactiveness. The end result is new efforts MIMIC the past efforts in this area, all the current Linux distributions are examples of the MIMIC factor.
Solution: Work with your System Architects to influence change in this area.
Regards, Kramer
There are many ways to do this, without going directly into system admin.
1. consider going the test engineer route. possibly as a black box test engineer, qa/test is a great career path as there is a real shortage of sr. people.
2. consider tech writing, leveraging from your teaching background
3. consider technical teaching, as this also leverages your background. large compaines will spin you up technically.
4. consider developing technical courses, again large companies have opportunities in these areas.
5. consider release engineering/configuration management
6. consider help desk positions
Just get your foot in the door, one way or the other and continue to work towards what interest you.
I started out on the MIS side and moved into system administration in 84' and in 85 into lab administration, and did that for 9 months. The experience paid of greatly in future positions. There are many types of system administration jobs, in larger companies: unix mail administrators, unix network administrations, database, develop lab, qa/test lab, end-user administrators, technical marketing, there are folks that go on the road to setup systems for trade-shows... quite a bit to choose from
Best of luck!
qbalus
My Sr. year of high school(1975/76) I worked at the HP Calculator Division in Cupertino... Best job I ever had...
I delivered coffee and donuts twice a day and served deli sandwiches on the lunch line.
A couple of buddies liberated a keg from one of the beer bashes, when it was empty, the keg was put to use as a tv stand.
One of the maintenance guys (Bob) accused us of taking the keg... we denied it for 18 years. At our 30th birthday bash (flirty, dirty and thirty), we finally admitted it to Bob... yeh... you had been right all along...
I was very interested at first glance, I downloaded the Rebol Core, got on a few lists, and observed the dialog for a couple of months, and unsubscribed. Its still very early, I'd like to have seen some applications of size and complexity but what I mostly saw reminded me of the early Java applet phase. I wish I could remember a recent url where reviews of Rebol are discussed... it reminded me of a 30 minute info-merical... I've heard those George Forman grills are pretty good... Don't know about that juice guy though... the eyebrows freak me out
qbalus