They'll sell you the shit, but damn it, they're not taking it back at any price
The jeweller doesn't have to - often the piece appreciates. I know someone whose engagement ring cost in the region of GBP 2500 in 1985; it's now worth about GBP 8000 (sold, I guess, second-hand). Of course, it's her engagement ring - she's not going to sell it.
The downside of this is that she lost the central stone out of the ring a fortnight ago (there are three stones, one large and two small). Fortunately, the insurance will replace it with one of an equivalent colour, quality, etc. The thing that amazes me is that this isn't even the first time the stone has dropped out! (In other words, the stone she just lost is not the one that was originally on the ring either!).
Personally, I bought the two-disk set and won't be buying the November release - I'm planning to buy the three films on DVD as they come out, and then to buy the great big three-movie boxed set once all three films are available on DVD.
ROOT is another option for visualisation (along with Octave and GNUPLOT). Interestingly, the ROOT system also includes a C++ interpreter (yes, interpreter!).
I maintain the GNU SCCS clone, CSSC. I therefore have several comments to make:-
Nobody should ever be using SCCS these days
I wouldn't join in with an attempt to clone BitKeeper because
Larry is very good - I wouldn't bet that it can be done better
I wouldn't want to take away Larry's revenue stream
Something that's been on my TODO list for a long time now is to take a serious look at Arch by Tom Lord.
If you do go and invent a new version control system, please don't forget to create a VCS module for it (there are already modules for CVS, RevXML, RCS and Perforce).
I use CVS to manage the source repository for CSSC, but I have my eye on Subversion.
ObCVSWhinges: On the whole CVS is good - in fact, in the most part it's good enough (ever heard the expression "The best is the enemy of the good"? Well, the good is the enemy of the best, too!).
My pains with it are
It gradually gets slower as you add more files and revisions
Inadequate hooks for plugging it into your bug tracker, work management system, database, toaster etc. The *info scripts exist but aren't really enough.
There are obscure gotchas that mean I can't unreservedly reccomend it for use by just anybody (i.e. people without training/skills). These issues include problems with binary files being edited on several branches at once.
Oh yes, one last thing - use CSSC if you have to but don't use SCCS/CSSC if you can get yourself into a position where you don't have to. There are good reasons why the acronym "CSSC" expands to "Compatibly Stupid Source Control"!
A more common term for what you refer to as a "Technical PM" is "System Architect". This sounds nice to technical ears and is (rightly) percieved as a senior technical position. We also have Functional Architects on some projects, whose skills favour the business process analysis side of things.
The other benefit of this is that the other guy doesn't get called a "Non-technical PM", which you have to admit isn't a very good job title.
In the (quite large, 12k staff) company I work for, the pinnacles of career (at least for most people's career paths) are
Programme Manager - these are the guys the Project Managers work for
System Architect - career progression here is measured in terms of the criticality or size of the project you run/work on
Principal Consultant - your job here is to be your organisation's main expert on some specific thing (deep skills rather than the wider skillset which is more usual for a system architect)
We do have some career positions above those, but they're mainly line-of-business and divisional management, Managing Directors of various business units, and so on. We have a dozen or so members of technical staff who are more senior than the System Architects for large programmes and the principal consultantts, but they don't really have specific job titles (as you might expect at that level, people know them by their name and reputation alone).
We have a group Technical Director (used to be the deputy Technical Director of the BBC), but he doesn't sit on the executive comittee - that may be something it would be best to change.
There's much more to successful project management than there appears, particularly when the PM is also managing the relationship with an external client.
It's the PM's job to make the client happy and (usually) deliver a profit. In a software context, this normally means delivering some software that works (see the Properly Testing Your Code thread).
As a technical person, skills that you will need to gain in order to be a successful PM will include
Understanding the business context and business drivers
Managing client relationships (even for internal clients)
Estimating and planning skills
Tracking progress against plan - and taking appropriate action (pay attention to this one!)
An understanding of what timescales are realistic. For example, is it realistic to estimate design:code:test in the ratio 3:2:1? (answer: no).
Understand that you need to make it possible for the client to change their mind half-way through
Delegation skills (you can't do it all yourself, you know!) and motivational skills (i.e. understand the kinds of things you can / can't ask of people).
Risk analysis/mitigation
Personal organisation and time management
(In some shops) Project accounting skills
Also, don't underestimate how much work this is. If you are team leading (i.e. working for a PM) then you can expect to lead a team of up to 8 and have the interaction with those staff and the PM take up 100% of your time (i.e. no time left for coding anything yourself). If you are a PM, you won't be able to directly supervise that many staff, because you have the added responsibility of steering the ship. Techies-turned-PMs are frequently tempted to take on the odd technical task - but resign yourself to the fact that you will have to delegate it to one of your staff in order for it to get done on time.
If you are having difficulty communicating the impossibility of a task, consider making a weekly/monthly report document that shows progress against plan and the outstanding issues and risks. Many of these will not change from week to week, but putting them there provides one place where (s)he can refer to them.
If something is impossible, then demonstrate in the report why it is impossible, and suggest an alternative. When presenting a problem, your many many times more likely to be successful in getting things changed if you also suggest a workable and realistic solution.
How do you guys manage thousands of servers spread throughout multiple datacenters?
How do you handle user accounts? Event notification?
Do you guys use "enterprise" software like Tivoli or Openview, or did you roll your own solution?
... to which I would add,
How do you balance the need to keep systems up-to-date against your (doubtless demanding) availability requirements? Is there enough redundancy in there that you just flip a machine out while it is updated? Presumably, however the machine is upgraded, this is automatic - you must have too many machines to do it any other way!
How to you test these updates (security patches, distribution updates, regular changes to your own software, configuration tweaks)? Do you have some kind of enormous test environment containing a copy of 50% of the main Google cache or something? For that matter, how do you do the testing itself? Do you type "Most clowns drink blue fruit juice on Mars" in the search box and just verify that you get 184 hits, and say "right, it works", or do you have a more sophisticated method of testing it (for example do you run your test system against a captive internal dataset)?
If your api says 'you can't pass a null here', or 'must be between 1 and 7', put an assertion inside that invocation, let the computer test it for you at runtime.
Well, I'm assuming that your systems start with analysis & design, followed by coding, redesign and more coding, go through unit testing (with more redesign if you are unlucky), followed by integration testing once unit testing is complete, and perhaps acceptance testing once integration testing is complete. This is more or less the traditional waterfall cycle when the deliverable is the finished code.
This strategy works - lots of shops use it all the time. However, the real premise of the process is that you want to get through client acceptance testing as soon as possible, as long as the result is not dissatisfaction on the part of the client with the software after they've accepted it. As you have noticed this strategy doesn't actually produce bug-free code.
This is not surprising. What you achieve is after all pretty much determined by what your goal was. You (shops in general) need to think hard about what your actual goal is. If your goal is nearly-zero-defects, then the traditional process isn't doing the right things for you. If however, your goal is to obtain milestone payments from your client, then it's pretty good. This is an area where the business goals determine the software engineering processes.
Let's put another hat on and think about what the negative affects of this strategy might be (negative is really defined in terms of what your goals are, but let's be vague about that for a moment).
If your goal is not "zero bugs" then you will stop work before there are no bugs left
Your software is delivered to the customer with bugs in it, which the customer will find
Your development team will partly move on to other areas, probably leaving a smaller number of people to deal with the remaining bugs
Maintenance programmers are typically less skilled than some of the original team - because some of the original team have been pulled off to activities which are more important to your business (e.g. delivering another set of code in order to meet a payment milestone somewhere else).
Skills evaporate over time - after N years it gets very difficult to find authoritative information on why something works like it does.
As the code is fixed, it gets brittle. The emphasis is on just fixing bugs and making low-risk changes in order to avoid breaking the production code - hence refactoring is rare.
All of the above factors are unpleasant for those left to maintain the code. Many of them also limit the longer term flexibility of the product and hence the useful life of the software. This feeds back into development processes because limited product lifetimes mean that there is less incentive to change your process to produce software which can persist (i.e. why make the effort to ensure that the system is flexible enough to last through 20 years of changing requirements when you expect the system to be retired after only 7 years?)
You mentioned XP - it offers a lot of techniques that resolve these problems:-
Programming in pairs - this makes for very efficient skills transfer, hence you limit the extent to which the expertise boils off
XP testing aims for automation - this encourages more testing and the stronger testing ability allows you to contemplate high-risk-high-return activities like refactoring.
Refactoring - which prevents your code getting old, brittle and hard to change
Many more I'm sure (I'm not an XP practitioner)
However, XP is best adapted to projects where a single team makes multiple frequent deliveries of code, can work closely with the client, and where the development project continues in the medium to long term. These characteristics allow many of the XP techniques, and this means that techniques taken out of XP may not help projects of a different style.
Having said this, the automated testing angle is a real strength. If testing is done manually, it's time consuming and expensive. Hence people don't do it as much as they might otherwise thing is appropriate. Maintenance deliveries often just undergo regression testing, and faults can creep in which might have been caught by the original unit or integration tests. Automated testing has many advantages:-
Automated tests are faster, so people actually do it!
You can redo all the tests after every change if you want.
Automated testing allows you to refactor without danger
Being able to re-run all the tests really does keep out the new bugs which would otherwise have been introduced during maintenance
Your testing coverage grows with time (since bew tests are introduced but tests are only retired when the relevant functionality is changed or dropped)
You don't fail to spot errors (quite often with manual testing regimes errors can go unnoticed because the tester doesn't spot a small bit of incorrect behaviour that the original team
might just have spotted).
Just as a data point, I work on some software that has an automated test suite. The suite contains between 500 and 1000 test cases; the test suite conducts those tests in under 5 minutes on a very old machine. To do these tests manually would take one full-time person at least a week.
The summary is:-
Understand your business's real goals
Cherry-pick techniques that will help achieve those goals (you might even be able to adopt a whole methodology if its processes are designed to achieve the kinds of goals that your business actually has).
Liability need not always be a problem; I work for a company that routinely supplies software which can result in the supplier being sued if there is a serious problem. This is not a particular problem because:-
The contract (note: not license agreement) limits the liability to an amount not greater than the contract value (Translation: you can get a 100% refund of your $25,000,000 but no more)
Most of this software is written in a context where the functionality is agreed with the client - there is no drive to include features just to beat the competition, because you already agreed with the client what they wanted right now and agreed a mechanism by which both parties plan upgrades.
While this doesn't translate directly to the Free software world, the idea that the damages are limited to the amount paid in the first place is useful (and obviously workable, or this wouldn't be a standard feature of so many contracts).
The issue over functionality is trickier - in the Free Software world, often people add features just because they think they're neat - and often they turn out to be. Where liability exists you need to worry about the extra liability you are taking on as a result of adding all these extra features, though.
Companies could supply software for (nearly) free without worrying too much about liability. Once the income from software sales becomes a signficant part of your turnover though, you start needing to ensure that the software is properly designed and adequately tested (of course thorough testing is no substitute for good design).
I'm unsure about how well this kind of measure would survive a transplant from a contract to a license agreement (since I'm not a lawyer).
Most of the reasons given in the linked article not to accept a counter-offer are silly. That's not to say that you should never accept one, but the reality is that wages are overhead and businesses try to keep them as low as they can as long as that's compatible with recruiting and retaining staff at a level they think they require.
In my experience, people normally change job for a new job at around 120% to 140% of their old salary. So at the most basic level, if you're not happy the extra money is not likely to make you much happier. On the other hand if you accept the counter-offer and then months later decide to leave anyway, you're looking at a new job which is 120% to 140% of your now increased salary. That's got to be good news. Of course, this doesn't apply so neatly to counter-offers with strings attached (e.g. agreement not to leave for 12 months or refund the extra salary) but in any case you should think twice before accepting such an offer.
At a previous job, I decided to leave to get a pay rise and reduce my commute, and was offered a boring job at 136% of my current salary. I talked to my current employer, and they offered to match it. Since my current job was more interesting and I wasn't unhappy, I agreed to stay.
Here's the interesting bit - in order to prevent morale problems, my employer gave the same increased package to my entire department! As you might imagine, I was flavour-of-the-month for quite a while among my colleagues.
Now that I think about it, this is evidence in favour of the point another poster made about employers using departing employees to adjust their idea of the market value of their staff.
I did eventually leave that job, but I did stay another two and a half years and enjoyed it.
Actually I think the first set of code is clearer - because it doesn't introduce the spurious variables which are themselves used in lieu of documentation.
Re:Turing-complete text editors
on
SedSokoban
·
· Score: 1
Does no one remember that the original emacs was written in TECO, a command-line driven text editor from DEC? I believe RMS first wrote a lisp interpreter in TECO macro language, then coded the rest of emacs in lisp.
As far as I understand Stallman's
paper on the original Emacs,
the original Emacs was written directly in TECO. The same paper appears to indicate that the first Emacs written in LISP was Multics EMACS.
Indeed, there are ways in which EMACS shows the results of not having been completely thought out in advance: such as, in being based on TECO rather than Lisp
Unfortunately Elvin seems to have a no-commercial-use license. Otherwise, I'd have said that it was an exciting system. I wish it met the Debian Free SOftware Guidelines - all it would have to do is be available for commercial use (see the DFSG document).
While I also like Tibco, there are a small number of things that might put someone off it:-
"Reliable" messages aren't reliable - if you want actually-reliable messages you actually have to use "Tibco Certified Messaging" not "Tibco Reliable Messaging". The Marketing department strikes again.
If you use Certified Messaging ("CM") you then have to have a ledger file in order that not-yet-delivered messages can persist. Management of ledger file space is tricky and historically Tibco has had severe problems (e.g. crashes) with large ledger files (e.g. >> 40Mb).
If you accidentally create a certified relationship with a new party (e.g. by incorrectly setting the CM name of a system just once) then the ledger files belonging to anybody who ever sent it stuff will grow larger and larger (with the size problem mentioned above) unledd you break the CM relationship. To break the CM releationship, you have to ask the application to do it - and unless the app has some way of telling it to break the relationship, this is very hard (i.e. I know of no other documented way to achieve it).
If you have short-lived processes (<30s) you can't use Tibco messaging effectively without a relay agent. This is because the sender's runtime support code has to be able to re-send the message datagram for up to 30 seconds - so shorter-lived processes work much less well and will lose data in the ordinary run of things. Using a relay agent solves this but is not something you can retro-fit without changing code (e.g. you can't do it to someone else's code). On the plus side, though, it's a one-line change.
Tibco messaging outside the local IP subnet relies on Tibco rvrd processes - which set up a point-to-point link for a set of subjects. This can be a small pain.
Multicasting is fiddly to set up (there's not a lot of good documentation on the correct usage of the network parameter).
Although Tibco also has a distributed transaction API, it's not clear how this interacts with TIBCO RV (RV is the name for the Tibco messaging product which everyone else calls Tibco). J2EE has transaction and messaging APIs and it's not clear to me if the Tibco products in those niches integrate seamlessly (I have used Tib/RV extensively but never used the transactional control product).
Tibco/RV messages are completely free-form - there is no way of ensuring that all messages of a specific type ("subject" in Tibco parlance) have any given structure. Of course, this can be a benefit too - it depednds.
Please don't get the impression from the above that Tibco is not a good product. It is, and it is (can be made to be) reliable enough for most purposes. For example, significant fractions of the UK's electricity market depends on Tibco for energy trading.
I followed the link to the kerneljanitors website. It's an interesting project. It suggests the auditing of a lot of things, e.g. all code paths including functions get_X() should also call release_X() and so on.
Interestingly, however, much of this stuff can be achieved with LCLint, which if I recall correctly has a mechanism which can be used to extend it to statically check almost anything. Now that sounds like a good idea (tip: if running lclint for the first time on a program, use the -weak command-line option!)
I suppose +5 posts are less likely to be "folded" away than +4 or +3 posts when a thread is long. Hence a random moderator is more likely to see it. Alternatively, perhaps some moderators browse with a positive threshold, daft though that may be).
Don't mandate key escrow. Key escrow will inhibit the adoption of encryption, and encryption is vital to both proper and secure authentication and to data privacy. Attempts by various parties to limit the widespread adoption of encryption might make their job easier but is not good for (internet) security. It is frequently said that if you outlaw encryption, only outlaws will use encryption - that is, making it illegal to use it will not stop criminals from actually doing so.
Re-think laws that make it possible to prosecute scientists for publishing the results of their research - i.e. the DMCA or parts of it.
Encourage the adoption of IPv6 - perhaps by allocating budget for adoption of this by government agencies (I mean carrot here, not stick).
This possibly doesn't buy you much - many DDOS attacks utilise captured machines, and so there would be no requirement to spoof the source address - since it is not the attacker's own address.
FWIW, nobody should allow 10.0.0.0/8 addresses to leave their network, since it is a RFC1918 address.
I'm assuming that since your system is a large project, it has subsystems in subdirectories. If this is the case, you can do a "pilot". Pick a very small subsystem and convert it to autoconf. Then pick a real target (for example, the most awkward system which is not gigantic) for a proof-of-principle. This process will provide you with enough evidence to back you up - or it will provide you with evidence that you shouldn't do the conversion after all. If you end up converting, you will have a top-level configure script that cascades down and calls the other ones.
Don't forget the Autoconf macro library and also the fact that there are thousands of free packages out there which will have configure scripts from which you can borrow - try to find packages in a similar domain to your own.
The difficulty (complexity, time taken) in maintaining a package which works on N platforms is usually proportional to N - or if you are unlucky, some small power of N like 2. What your code is really doing is trying to understand the properties of the target system and so the #ifdef __hpux__ for example in line 1249 of blurfl.c is actually trying to determine if the quux is use like this or like that. Autoconf on the other hand will produce a single preprocessor macro for driving the quux. This means that you don't have an extra 15 lines of #ifs to handle quuxes in other operating systems. Hence you may not have less #ifdeffed bits, but each of the #ifdeffed bits will be shorter.
Autoconf works differently to thge standard approach - it allows your code to work with each feature independently, and so while the normal approach is O(N) or O(N^2) in the number of suppoered OSes, the complexity of maintaining an autoconfiscated program is O(N) in the number of different features supported by the operating systems between them. The great thing about this is that Autoconf keeps these orthogonal and prevents these things from interacting too heavily, and it turns out to the the case that the total number of different features basically flattens out to some constant number even when you continue to add more supported OSes (i.e. there are only a certain total number of different ways of doing things even though each of the N operating systems can choose among X ways of doing Y things).
So, what this means is that you shold do the feasibility study as discussed above, but naturally autoconfiscating the whole system will take a while. The ideal time to do this is either
when you are in any case adding support for an extra platform or two or
on a piecemeal basis for each subsystem.
Another option to explore in combination with Autoconf is the Apache Portable Runtime. There is also Autoproject but I suspect that is a little lightweight for your needs.
Taking all the above together I suggest that you
Propose a feasibility study, using a couple of sections of the project
Identify a way of making the newly autoconf-ed section fit in with your existing build mechanism (so that you can roll out autoconfiscation gradually across the project).
Identify any related open-source projects which might have useful autoconf macros (e.g. Gnome has lots).
Slashdot Mirror
The jeweller doesn't have to - often the piece appreciates. I know someone whose engagement ring cost in the region of GBP 2500 in 1985; it's now worth about GBP 8000 (sold, I guess, second-hand). Of course, it's her engagement ring - she's not going to sell it.
The downside of this is that she lost the central stone out of the ring a fortnight ago (there are three stones, one large and two small). Fortunately, the insurance will replace it with one of an equivalent colour, quality, etc. The thing that amazes me is that this isn't even the first time the stone has dropped out! (In other words, the stone she just lost is not the one that was originally on the ring either!).
Personally, I bought the two-disk set and won't be buying the November release - I'm planning to buy the three films on DVD as they come out, and then to buy the great big three-movie boxed set once all three films are available on DVD.
ROOT is another option for visualisation (along with Octave and GNUPLOT). Interestingly, the ROOT system also includes a C++ interpreter (yes, interpreter!).
...but to do it you have to use EQUIVALENCE statements.
ObCVSWhinges:
On the whole CVS is good - in fact, in the most part it's good enough (ever heard the expression "The best is the enemy of the good"? Well, the good is the enemy of the best, too!).
My pains with it are
- It gradually gets slower as you add more files and revisions
- Inadequate hooks for plugging it into your bug tracker, work management system, database, toaster etc. The *info scripts exist but aren't really enough.
- There are obscure gotchas that mean I can't unreservedly reccomend it for use by just anybody (i.e. people without training/skills). These issues include problems with binary files being edited on several branches at once.
Oh yes, one last thing - use CSSC if you have to but don't use SCCS/CSSC if you can get yourself into a position where you don't have to. There are good reasons why the acronym "CSSC" expands to "Compatibly Stupid Source Control"!The other benefit of this is that the other guy doesn't get called a "Non-technical PM", which you have to admit isn't a very good job title.
In the (quite large, 12k staff) company I work for, the pinnacles of career (at least for most people's career paths) are
- Programme Manager - these are the guys the Project Managers work for
- System Architect - career progression here is measured in terms of the criticality or size of the project you run/work on
- Principal Consultant - your job here is to be your organisation's main expert on some specific thing (deep skills rather than the wider skillset which is more usual for a system architect)
We do have some career positions above those, but they're mainly line-of-business and divisional management, Managing Directors of various business units, and so on. We have a dozen or so members of technical staff who are more senior than the System Architects for large programmes and the principal consultantts, but they don't really have specific job titles (as you might expect at that level, people know them by their name and reputation alone).We have a group Technical Director (used to be the deputy Technical Director of the BBC), but he doesn't sit on the executive comittee - that may be something it would be best to change.
There is a list here.
As a technical person, skills that you will need to gain in order to be a successful PM will include
- Understanding the business context and business drivers
- Managing client relationships (even for internal clients)
- Estimating and planning skills
- Tracking progress against plan - and taking appropriate action (pay attention to this one!)
- An understanding of what timescales are realistic. For example, is it realistic to estimate design:code:test in the ratio 3:2:1? (answer: no).
- Understand that you need to make it possible for the client to change their mind half-way through
- Delegation skills (you can't do it all yourself, you know!) and motivational skills (i.e. understand the kinds of things you can / can't ask of people).
- Risk analysis/mitigation
- Personal organisation and time management
- (In some shops) Project accounting skills
Also, don't underestimate how much work this is. If you are team leading (i.e. working for a PM) then you can expect to lead a team of up to 8 and have the interaction with those staff and the PM take up 100% of your time (i.e. no time left for coding anything yourself). If you are a PM, you won't be able to directly supervise that many staff, because you have the added responsibility of steering the ship. Techies-turned-PMs are frequently tempted to take on the odd technical task - but resign yourself to the fact that you will have to delegate it to one of your staff in order for it to get done on time.If you are having difficulty communicating the impossibility of a task, consider making a weekly/monthly report document that shows progress against plan and the outstanding issues and risks. Many of these will not change from week to week, but putting them there provides one place where (s)he can refer to them.
If something is impossible, then demonstrate in the report why it is impossible, and suggest an alternative. When presenting a problem, your many many times more likely to be successful in getting things changed if you also suggest a workable and realistic solution.
How do you balance the need to keep systems up-to-date against your (doubtless demanding) availability requirements? Is there enough redundancy in there that you just flip a machine out while it is updated? Presumably, however the machine is upgraded, this is automatic - you must have too many machines to do it any other way!
How to you test these updates (security patches, distribution updates, regular changes to your own software, configuration tweaks)? Do you have some kind of enormous test environment containing a copy of 50% of the main Google cache or something? For that matter, how do you do the testing itself? Do you type "Most clowns drink blue fruit juice on Mars" in the search box and just verify that you get 184 hits, and say "right, it works", or do you have a more sophisticated method of testing it (for example do you run your test system against a captive internal dataset)?
It already exists - it's called Valgrind - an AC post provided a link to it. In case you can't find it, it's here.
See Offensive Programming for a discussion of this kind of thing.
This strategy works - lots of shops use it all the time. However, the real premise of the process is that you want to get through client acceptance testing as soon as possible, as long as the result is not dissatisfaction on the part of the client with the software after they've accepted it. As you have noticed this strategy doesn't actually produce bug-free code.
This is not surprising. What you achieve is after all pretty much determined by what your goal was. You (shops in general) need to think hard about what your actual goal is. If your goal is nearly-zero-defects, then the traditional process isn't doing the right things for you. If however, your goal is to obtain milestone payments from your client, then it's pretty good. This is an area where the business goals determine the software engineering processes.
Let's put another hat on and think about what the negative affects of this strategy might be (negative is really defined in terms of what your goals are, but let's be vague about that for a moment).
All of the above factors are unpleasant for those left to maintain the code. Many of them also limit the longer term flexibility of the product and hence the useful life of the software. This feeds back into development processes because limited product lifetimes mean that there is less incentive to change your process to produce software which can persist (i.e. why make the effort to ensure that the system is flexible enough to last through 20 years of changing requirements when you expect the system to be retired after only 7 years?)
You mentioned XP - it offers a lot of techniques that resolve these problems:-
However, XP is best adapted to projects where a single team makes multiple frequent deliveries of code, can work closely with the client, and where the development project continues in the medium to long term. These characteristics allow many of the XP techniques, and this means that techniques taken out of XP may not help projects of a different style.
Having said this, the automated testing angle is a real strength. If testing is done manually, it's time consuming and expensive. Hence people don't do it as much as they might otherwise thing is appropriate. Maintenance deliveries often just undergo regression testing, and faults can creep in which might have been caught by the original unit or integration tests. Automated testing has many advantages :-
Just as a data point, I work on some software that has an automated test suite. The suite contains between 500 and 1000 test cases; the test suite conducts those tests in under 5 minutes on a very old machine. To do these tests manually would take one full-time person at least a week.
The summary is :-
Wow. I didn't think the ACLU knew anything about computer programming...
While this doesn't translate directly to the Free software world, the idea that the damages are limited to the amount paid in the first place is useful (and obviously workable, or this wouldn't be a standard feature of so many contracts). The issue over functionality is trickier - in the Free Software world, often people add features just because they think they're neat - and often they turn out to be. Where liability exists you need to worry about the extra liability you are taking on as a result of adding all these extra features, though.
Companies could supply software for (nearly) free without worrying too much about liability. Once the income from software sales becomes a signficant part of your turnover though, you start needing to ensure that the software is properly designed and adequately tested (of course thorough testing is no substitute for good design).
I'm unsure about how well this kind of measure would survive a transplant from a contract to a license agreement (since I'm not a lawyer).
In my experience, people normally change job for a new job at around 120% to 140% of their old salary. So at the most basic level, if you're not happy the extra money is not likely to make you much happier. On the other hand if you accept the counter-offer and then months later decide to leave anyway, you're looking at a new job which is 120% to 140% of your now increased salary. That's got to be good news. Of course, this doesn't apply so neatly to counter-offers with strings attached (e.g. agreement not to leave for 12 months or refund the extra salary) but in any case you should think twice before accepting such an offer.
At a previous job, I decided to leave to get a pay rise and reduce my commute, and was offered a boring job at 136% of my current salary. I talked to my current employer, and they offered to match it. Since my current job was more interesting and I wasn't unhappy, I agreed to stay.
Here's the interesting bit - in order to prevent morale problems, my employer gave the same increased package to my entire department! As you might imagine, I was flavour-of-the-month for quite a while among my colleagues.
Now that I think about it, this is evidence in favour of the point another poster made about employers using departing employees to adjust their idea of the market value of their staff.
I did eventually leave that job, but I did stay another two and a half years and enjoyed it.
Actually I think the first set of code is clearer - because it doesn't introduce the spurious variables which are themselves used in lieu of documentation.
As far as I understand Stallman's paper on the original Emacs, the original Emacs was written directly in TECO. The same paper appears to indicate that the first Emacs written in LISP was Multics EMACS.
Stallman writes :-
How about: Just being technically better isn't enough.
Unfortunately Elvin seems to have a no-commercial-use license. Otherwise, I'd have said that it was an exciting system. I wish it met the Debian Free SOftware Guidelines - all it would have to do is be available for commercial use (see the DFSG document).
Please don't get the impression from the above that Tibco is not a good product. It is, and it is (can be made to be) reliable enough for most purposes. For example, significant fractions of the UK's electricity market depends on Tibco for energy trading.
Interestingly, however, much of this stuff can be achieved with LCLint, which if I recall correctly has a mechanism which can be used to extend it to statically check almost anything. Now that sounds like a good idea (tip: if running lclint for the first time on a program, use the -weak command-line option!)
I suppose +5 posts are less likely to be "folded" away than +4 or +3 posts when a thread is long. Hence a random moderator is more likely to see it. Alternatively, perhaps some moderators browse with a positive threshold, daft though that may be).
Don't mandate key escrow. Key escrow will inhibit the adoption of encryption, and encryption is vital to both proper and secure authentication and to data privacy. Attempts by various parties to limit the widespread adoption of encryption might make their job easier but is not good for (internet) security. It is frequently said that if you outlaw encryption, only outlaws will use encryption - that is, making it illegal to use it will not stop criminals from actually doing so.
Re-think laws that make it possible to prosecute scientists for publishing the results of their research - i.e. the DMCA or parts of it.
Encourage the adoption of IPv6 - perhaps by allocating budget for adoption of this by government agencies (I mean carrot here, not stick).
This possibly doesn't buy you much - many DDOS attacks utilise captured machines, and so there would be no requirement to spoof the source address - since it is not the attacker's own address.
FWIW, nobody should allow 10.0.0.0/8 addresses to leave their network, since it is a RFC1918 address.
Don't forget the Autoconf macro library and also the fact that there are thousands of free packages out there which will have configure scripts from which you can borrow - try to find packages in a similar domain to your own.
The difficulty (complexity, time taken) in maintaining a package which works on N platforms is usually proportional to N - or if you are unlucky, some small power of N like 2. What your code is really doing is trying to understand the properties of the target system and so the #ifdef __hpux__ for example in line 1249 of blurfl.c is actually trying to determine if the quux is use like this or like that. Autoconf on the other hand will produce a single preprocessor macro for driving the quux. This means that you don't have an extra 15 lines of #ifs to handle quuxes in other operating systems. Hence you may not have less #ifdeffed bits, but each of the #ifdeffed bits will be shorter.
Autoconf works differently to thge standard approach - it allows your code to work with each feature independently, and so while the normal approach is O(N) or O(N^2) in the number of suppoered OSes, the complexity of maintaining an autoconfiscated program is O(N) in the number of different features supported by the operating systems between them. The great thing about this is that Autoconf keeps these orthogonal and prevents these things from interacting too heavily, and it turns out to the the case that the total number of different features basically flattens out to some constant number even when you continue to add more supported OSes (i.e. there are only a certain total number of different ways of doing things even though each of the N operating systems can choose among X ways of doing Y things).
So, what this means is that you shold do the feasibility study as discussed above, but naturally autoconfiscating the whole system will take a while. The ideal time to do this is either
Another option to explore in combination with Autoconf is the Apache Portable Runtime. There is also Autoproject but I suspect that is a little lightweight for your needs.
Taking all the above together I suggest that you