The problem with that idea is that while there is likely to be a fairly direct corrolation between working conditions and productivity, unemployment depends on a lot of other, independent factors.
For a start, you can fudge the figures very easily. The number of people who are not in regular, gainful employment in the UK is a very different statistic from the number of people claiming a Jobseeker's Allowance or similar benefit, and the latter is what the government's figures tend to report. That alone makes any meaningful comparison with figures from other nations nigh-on impossible.
Even if we ignore that detail, unemployment still depends on many economic factors that remain more favourable in the UK (fingers crossed) than they are elsewhere in Europe. I don't see that you can reasonably argue that our low unemployment is caused, or even mostly caused, by the sort of working conditions we're discussing.
(Incidentally, I believe the guidelines in the UK now require various people, including cold-callers and call centre staff, to provide their name and the name of the company they work for at the start of any call.)
First of all, realise that you are asking for a quick-and-easy way to produce information that normally requires several years of solid experience in the relevant industry to estimate with any accuracy. You cannot possibly do this alone if you don't have a background in programming as well.
With that very necessary caveat, here are a few guidelines that might be of use. After discussing the reasoning behind them, I'll come back to address the questions in the original post.
It can take very different amounts of time to get the same work done, depending on a few key variables:
How good is the spec?
How much does the spec change during development?
How good are your team members?
How good is the controlling process?
These sound fairly nebulous, but there are some key points in each case that make all the difference.
1. How good is the spec?
First of all, you must have good specifications of the requirements. Start with something written in terms of the problem domain: what data will be in the database and how it will be used, what you want to be able to do with the UI, etc. Then have people who understand both the basics of the problem domain and the details of software development produce specs in software development terms based on your original requirements. Depending on the size of your project, this might be as simple as a database schema or two and a description of what the UI will look like. Around this point, someone experienced will be able to estimate how long the remainder of the project would take a typical team.
If you don't have a good requirements spec up-front, then clearly you won't produce very accurate technical specs from it, and the error in your estimates will be commensurately higher.
2. How much does the spec change during development?
This is a killer. Requirements often will change during the development of a project, either because the client's needs evolve over the lifetime of the work, or because you realise that the original plan was flawed and have to adapt. However, it takes significantly longer to adapt to changing requirements than it does to get it right, at least mostly, up-front. If your requirements are concrete at the start, and the most you're likely to need to change is a few details to adapt to things not working out as you first envisaged, your project will move fairly efficiently. If you constantly change things under your developers' feet (which is common if your original spec wasn't very good, for a start) then you need to double or treble the expected lifetime of the project.
3. How good are your team members?
Individually, a good developer can get an order of magnitude more work done than a mediocre one. If you get several good guys together on your team, and they're also team players and not prima donnas, you can estimate a much faster completion than you would from an average team. Of course, you'll have to pay these people significantly better, but they'll be more than worth it.
Incidentally, when you're forming a team, do get someone technically competent to gauge whether they know what they're talking about. A non-programmer is simply not qualified to do this, no matter how many clever books they've read or how many buzzwords were in their management magazine last week. Screwing this up is a great way to multiply the lifetime of your project by ten.
4. How good is the controlling process?
In a good, lightweight process, working with good people and good specs, you'll find that your team spends around 30-40% of its time planning and designing, a similar amount or a bit longer on testing and putting it all together, perhaps 10% on actually implementing the designs, and a few percent on overheads, mostly communication within the team to keep things organised.
In a bad process, you can ramp those overheads way up, easily wasting 50-75% of your developers' time on unhelpful paperwork and needless communications. Again, it pays to have a good project manager/management team, or to employ someone with good organisation skills if it's a one-person job.
So, there you have it. A good team, working fairly uninterrupted from good requirements specs and with a good co-ordinating process, will probably put together your software 50x faster than a team of poorly-trained code monkeys who are constantly messed around and following a heavyweight process that doesn't respond well to change. Of course, this doesn't really much happen; if you aren't smart enough to use good people and let them get on with their job, your project will join the vast majority: it will fail and be cancelled.
Back to the original questions...
With all of that in mind, it's hard to give specifics without knowing a lot more about your particular job, but I can give you an idea of what a typical, small-scale database application might be like.
UI work often makes up 50% or more of a project. Databases require some careful thought up-front, but tend to be fairly straightforward. Integration with an existing system is a bit of a minefield; as ever, if you've got clear specs to match against (and the existing system actually follows them, which is far from guaranteed!) it's fairly easy, but if you have to work things out for yourself due to lack of accurate information, this can be a big risk.
It sounds as though this project is fairly small scale. Assuming you have average developers, a small database would probably take a man-week or two to design and implement. A UI to provide basic input, searching and reporting functionality for a database of that size probably takes 2-3x as long as making the database itself. If you're only doing a simple transfer of data to another application, that might be done in a matter of days, but if you're talking to a big custom database app using non-standard protocols and detailed interfaces, it could take several weeks.
All in all, you're probably looking at 3-6 man-months to design and implement a typical application of the sort I imagine you're dealing with. Of course, then there are the overheads, particularly up-front requirements capture and the testing and QA time, so overall you're probably looking at 1-2 man-years of development from start to finish. Clearly this has to be a very random figure without a lot more details, but it's about par for the course designing small custom database apps with a decent team and decent tools.
As to your final question about porting: this really depends very much on how different the platforms are. If you know ahead of time that porting is likely to be a requirement, you can invest a little time during development to save a lot of time reengineering things later. Using portable tools and programming languages makes a huge difference here, and having people on the team with experience of the idiosyncrasies of each platform to be used helps a lot, too.
If you've done this well and your project requirements are amenable to porting, you might port successfully in 2-3 man-months. At the other end of the spectrum, sometimes things are so different that it really is faster to rewrite from scratch, though obviously you'll have gained a lot of insight the first time around so you'll generally get the second implementation done significantly faster than the original.
In Europe we have regulations to prevent this - stipulation on maximum working week etc. However, in the way the regulations were implemented in the UK, it's standard practice for everyone to sign a contract that allows overtime working with no fixed maximum.
Of course, whether such a contractual clause has any legal validity at all is a different matter; see the DTI information on working time regulations.
The thing that always amazes me is that incompetent managers continue to equate longer hours with higher productivity. The UK has the longest hours and lowest statutory minimum holiday entitlement of any EU member state, yet it also has almost the lowest productivity by any major benchmark.
The population of the US seems prepared to put up with any amount of abuse from the big corporate employers and such, and when someone from elsewhere with three times the annual holiday allowance suggests that demanding a reasonable limit on their working hours is entirely appropriate, I've seen US citizens here on/. rant at them about how they don't know how good they've got it. They just don't realise how abusive their employers are compared to the rest of the western world... <sigh>
By the way, I work in the UK, and I'm paid a salary rather than an hourly rate (and no over-time). My contract specifies a minimum 37.5 hour week, and I work pretty close to that. The company makes a genuine effort to treat its employees well, so most of us are prepared to cut them some slack when deadlines come up, but ultimately it's a two-way business relationship, and there are always limits to what would be acceptable by either side.
In contrast, at the last place I worked, the management was so worried about their financial state that they actually started asking people to defer taking their holiday entitlement, because we couldn't bill the clients for days when people were on leave and cash flow was that bad. Needless to say, everyone started taking their holiday immediately to make sure they got it at all, and many of the good people started looking for alternative employment around that point. Go figure...
Therefore, sue them for your damages:
an extra year in college (about 30000 dollars?)
income you will miss (the difference in salary between your student job and a regular job, another 30000 dollars).
Trust me, when you have to explain to a potential employer that you missed your finals because you were arguing with a cinema about the difference between 12am and 12pm so you could go see LoTR:TTT on the day it opened, you're going to be losing a lot more than $30k in salary income over your lifetime...
_Always_ ask for a supervisor when you are complaining and the front line isn't working.
Works great in person. On a phone, you'll probably find everyone in the call centre has "supervisor" in their job title, so they can shift you around to one of their equally powerless colleagues as a first move. Always get the name and job title of the person you speak to, and ask a black-and-white question about whether they have more power to help you than the last person you spoke to.
One of the funniest experiences I ever had was when a phone company, who had apparently gotten a contract to supply hundreds of student rooms but forgotten to hire the manpower to install it all, gave us the "call centre tennis" treatment. Someone looked up the (publicly available) contact details of their managing director, and called him at home at 9pm on a Saturday night to complain.
By 10pm we had two vans full of engineers out to install the phones for everyone in the block whose order was running late.
When confronted with this ambiguous situation I have always taken PM to imply night and AM to imply day (yes, I know that's not really what they mean).
Or argue with the manager, loudly, in the lobby, in front of lots of other people, untill he caves in and gives you a refund or exchange.
I appreciate that this was modded Funny, but there's a serious side to it.
Around the time I finished my degree, I went into my bank, looking to take out a loan so I could buy a car to get to my new job and put down the deposit to rent a place. I wasn't asking for a vast sum of money, and I had a contract in my hand from my future employer that would provide a reasonable guarantee of my ability to repay what I was asking for.
I was told that, while the person I spoke to understood my situation, the computer would automatically reject any application for a loan while I was still a student. Further, if he even tried just to see, it would damage my credit record, as a "loan denied" tag would get stuck against my name for years.
So, I thanked him for his time, and left. Two hours later I returned, having opened an account with an alternative bank who were more than happy to match or better every term I had with my existing accounts, credit card, etc. and were also prepared to offer me a small loan to get started with my working life.
I walked up to the front desk, and just about loud enough for the other few dozen people in the branch to overhear, I said that I'd like to withdraw the balance on both of my accounts, clear the credit card and then close all three, please. "Oh, dear," the lady there said. "Is there anything we can do to make you change your mind?"
Doubleplusooops.:-)
Guess what happened for the next five minutes, in front of a room full of customers... Actually, make that ex-customers. Two other people, presumably in a similar position to my own, promptly moved to the queue behind me and closed their own accounts as I left.
Sometimes, the only way to make a commercial entity see sense is to vote with your wallet. Other times, bad PR is far more effective. Either way, it pays to stand up for yourself using language they understand. Make sure you give word-of-mouth credit and customer loyalty to the good places as well, and between the two, you'll find your life gets far easier.:-)
Portability. They are just as locked in as any other development team using a single proprietary compiler with its own custom extensions. As a result, they are stuck using a tool that, with all due respect, produces pretty mediocre output compared to the best in the field. That might not matter too much for an OS, since chances are it doesn't take much advantage of either the things the other compilers optimise better or the features GCC doesn't support properly. In general, though, it's a very serious point (said the guy who writes code that compiles on 15 different platforms every day).
Standing up for your rights is absolutely not taking advantage.
If I pay $5 for a ticket at one time, and they take my money, then that is that. We have made a deal, and both sides are morally obligated to honour it. If they didn't like it, they were free to decline my money.
If they later go back on the deal, then they are morally (and almost certainly legally) obliged to honour their original side of the bargain, or to offer suitable compensation. That might mean putting on an extra showing at the time indicated, or at least providing a full refund (and, if they're smart, complimentary tickets to another showing later on by way of apology), or otherwise making it up to their customers in some reasonable way.
Now, if it was a legitimate screw-up that they can't correct with, say, an extra showing, and if everyone has been offered a full refund and an apology, I don't think you can really complain much beyond that. If you don't like it, vote with your wallet. But the details aren't clear from the original story, and it certainly sounds like the theatre is pulling a fast one the way it's phrased.
How many websites have you visited that were created for pleasure rather than financial compensation?
Many. But how many web sites are there that provide access to high quality information with clear presentation, the way a good book or journal would? Very few, and most of them are supported by other means.
Wanna bet? If they're any good, their public will buy them a beer and a burger whenever they're thirsty and hungry.
How do you know?
What *would* happen if IP laws did not exist is this - there would be less people calling themselves artists, and those who did would either be fully certain that they exist only to create, or fully certain that they're damned good.
What would happen if IP laws did not exist is probably more like this...
Firstly, academic research would all but stop, because the only product it produces is information, and the value of that information is drastically reduced. Consequently the funding would rapidly dry up. The picture would probably be much the same in both universities and industry, for the same reasons.
As a direct result of lack of research, medical science would grind to a halt. One of the single biggest turnover markets in the world is medical research, but the reason is that doing that research costs a lot of money. If the people investing that money have no guarantee that they'll see a return on investment, they'll get out of the market. They may be greedy -- although for all the high prices they charge, they do spend a fortune developing the good stuff in the first place, and write off several more fortunes on all the ideas that don't work out first -- but they're not stupid.
Along similar lines, say goodbye to any hopes for faster, more efficient transport infrastructure any time in the near future. Car manufacturers are currently throwing staggering amounts of money into R&D for things like fuel cell cars. Potentially, they solve the environmental problems of automobiles once and for all, which I hope you'll agree is a goal worth aiming for, but without the knowledge that they'll be the only ones who can produce cars based on the tech they develop, at least for a while, they have no reason to invest in it only to see their competitors rip off the end results within months.
This same picture repeats itself all over the world. IP is not just about music, or software, though obviously both of those things are information-based and have the same driving economics behind them. Personally, for all we knock modern software, I'm quite glad we've seen the improvements we have over the last fifty years. And where did those improvements come from? R&D, of course.
Now, if the cost of maintaining the incentives to research and develop is having intellectual property, and convincing a load of idealistic script kiddies that they can't have everything for free just because they want it, then as far as I'm concerned, so be it. You don't go driving through the streets like a maniac just because your car can do 90, because there are serious consequences, and people understand that. The irresponsible few who do it anyway are, rightly, treated as criminals and dealt with accordingly. It's about time the current teen/20something generation understood that there will be consequences to their wholesale ripping of music and software as well, and accepted the corresponding moral responsibility to work inside the rules.
The point is that it should not be illegal to copy it for private purposes.
Taken to the logical extreme, that means that everyone in the world can get any information they want for free using P2P or the like, and no-one ever gets compensated for making that material in any way.
The problem with these free-everything idealist arguments is that they don't scale.
Unfortunately, the sort of society you're describing couldn't come about overnight. Those sorts of changes would take many decades to get right even starting from an organised beginning. In the period that would follow the breakdown of encryption, I suspect what you'd actually see would be a period of panic and relative anarchy, a clampdown into police states to control it, and subsequently many years of corruption in governments desperate to retain control until they could reestablish the mechanisms that were there before using alternative means. The entire game doesn't change at all -- breaking one crypto algorithm isn't anything like enough to catalyse that -- it just gets really ****ty for a while.
You've seen and heard a lot about terrorism lately, I assume. When the intelligence agencies screw up, and something like Sept 11 happens, you hear all about it. How many terrorist incidents do you think such agencies prevent for every one that happens? I'm betting it's quite a few.
I realise that a lot of intelligence officers just read the local papers and use their brains, but I'm guessing that on-the-ground in-with-the-bad-guys people are still pretty important as well. If you blow the cover of every single intelligence officer in the world, who do you think it's going to hurt more, us or the bad guys?
Next up... You have a bank account, right? How would you feel about not only letting anyone who wanted to see the details, but letting any script kiddie with half a brain play with the money itself? If you remove the encryption that's used when things like transfers are done electronically, what exactly is going to stop them?
Now, I don't know whether either of these specific things is a valid example. I kinda assume that military and serious finance types have more than just a couple of prime numbers to protect their data. Then again, screw ups do happen, so maybe it's not so much more. It doesn't really matter anyway. Even if these exact things wouldn't crumble if you released an efficient prime factorising algorithm, there are numerous other things along the same lines that are bound to. RSA is a well-known and widely used algorithm that would be cracked instantly, for a start.
Now, I don't know about you, but personally I rate my personal safety, the security of my finances, the confidentiality of my health records and such pretty highly. Right about now, they're reasonably protected as far as I know. If you release something that cracks such a popular and fundamental encryption technique overnight, that all disappears. Me, I reckon I'd prefer living in the West to living in a third world country where the only people who have any control are the guys with the biggest guns, but maybe I'm just dumb like that...
The current system needs to be replaced, and that is the best method I can think of to replace it.
I truly and sincerely believe that you should think about that claim, and then think a whole lot harder about what you'd like to see replace it. There are plenty of places in the world, still, where the protections that we take for granted don't exist. I'm guessing you wouldn't like to be there a whole lot, and releasing all the stuff that's currently protected is a one-way trip.
I've always found it amusing that so many people buy beginners' books on technical subjects, and then post massively pro reviews on places like Amazon about them. By definition, these people are beginners in the subject, and therefore unqualified to review the books for technical accuracy!
By all means comment on whether you liked the writing style and presentation, but please... This is why people like Herb Schildt (familiar to almost anyone in the C(++) world) get rave reviews, yet continue to have enough serious technical errors in their work that informed critics write whole web pages pointing them out, in the hope that newbies see them first and don't get screwed because of their inherent naivety.
Trust me, you do not want to suddenly unleash an efficient algorithm for factorising into large primes on the world. For a start, security as we know it would more-or-less disappear overnight, if only because so much important data has been encrypted using algorithms that assume such factorisation to be hard.
While Quicksort is O(nlogn) in typical use, its worst case performance is O(n), although most serious implementations would use a variation such as Introsort to limit the worst case behaviour.
Mergesort is O(nlogn) in all cases. However, the constant factor is usually significantly greater than Quicksort, making the latter preferable for most uses.
Shell sort is significantly slower for most situations, though IIRC it's pretty good with data that's already almost sorted.
Re:But you can't guess what other types it would h
on
Java Gets Templates
·
· Score: 2
I think we're on the same wavelength, but just a couple of points are worth mentioning...
Firstly, it's almost invariably not true that (a+b)+c == a+(b+c) from a numerical analysis point of view. The problems of limited precision render such mathematical niceties, well, niceties. While I appreciate that it would be nice to program in a higher level language where such mathematical contracts were used, none of those under discussion around here will ever qualify.
As for overloading-heavy code being write-only, I couldn't disagree more. Code where operators are overloaded usefully (viz. typical mathematical types, string concatenation, etc.) is far more readable than the equivalent with longhand methods being used all over the place, particularly in a language such as Java that has no free functions. The only time such code becomes write-only is when the operators are overloaded in a misleading way (for example, having unexpected side-effects) and that's no different to the effect of choosing a bad name for any other function, or variable, or type.
But you can't guess what other types it would help
on
Java Gets Templates
·
· Score: 2
Here's what I propose: don't let the programmer overload "+" arbitrarily. But for classes which implement certain kinds of mathematical entities, have a set of methods they must implement with the types that make mathematical sense. [...] It should be possible to make it work well for mathematical objects, but unpleasant for anyone who wants to tries to cheat the system.
And how, exactly, do you propose to work out who is "cheating the system" and whose use is quite legitimate? Is the use of + to concatenate strings acceptable to you? What about other string-like classes? How about for adding date/time and time period classes?
At the end of the day, you can never anticipate every use to which such a feature could usefully be put. You have two choices: try, and provide something that is sometimes useful but usually frustrating, or leave the choice to the informed developer, and let them do what they will with it. The fact that C++ is still here is testament to the fact that the second approach works. I can't think of a single language that tries to restrict the programmer this way that has lasted more than a short period.
Why do you say "there goes your type safety"? Can you explain in detail why Java generics are not type safe?
It's not that they are necessarily not type-safe, not in the way that the current containers are because you have to perform a potentially wrong downcast to use them.
However, suppose I develop the world's greatest sorting algorithm, and I want to write a generic implementation for it to sort arbitrary sequence containers of arbitrary types. There are inevitably certain minimal requirements: I must be able to traverse my container in a suitable way for my algorithm to work, the types must support a suitable ordering relation, and so on.
As I understand it, several people in this thread are advocating the use of interfaces to ensure that only suitable types get passed to my sorting algorithm, thus ensuring type safety. The problem with that is what happens when someone comes along with a new container or sortable type that provides the necessary methods, but doesn't explicitly use that interface. Now my "generic" sorting algorithm can't be used, purely because of a naming issue. (I realise there are certain standard interfaces defined for things like comparison in Java, but obviously for types and algorithms in general that won't be the case.)
The requirement to implement interfaces explicitly is simply an unnecessary bar to the use of generics. In other languages, from C++ to SML, you can achieve similar effects without ever explicitly naming your interface. Instead, the algorithm simply fails to compile if it's used with types that don't match the way the algorithm uses them. Added to the presence of operator overloading, which standardises many fundamental arithmetic and logical operations from the start, writing generic algorithms that really are quite general is significantly easier.
Further, the concept of an interface as defined in languages like Java is inadequate to enforce useful constraints in practice anyway. The suggestion has been made, and refuted, many times in the C++ world, and alternative approaches to document and enforce constraints within template code have been developed instead.
The only alternative that I see as Java's generics stand today is to define all your generic algorithms to work with any Object, and go back to downcasting, but then you might as well never have bothered with generics in the first place.
Thus your two alternatives are either an interface-based system, which is type-safe but unnecessarily restrictive and less efficient, or to use generics only for type-safe containers and to write your generic algorithms in terms of Objects, which leaves open type safety loopholes.
Ultimately, implementing generic algorithms will always suffer because one man's search method is another man's find. It is helpful to offer methods of standard names to make generalising code easier, but clearly you can't have a standard interface for everything in a general purpose library that may be put to any use. I advocate the use of operator overloading, because the sorts of calculations performed by built-in operators tend to be useful in a wide variety of contexts. Beyond that, if your generics only deal with the methods that are actually presented, whether or not they're explicitly identified by a formal interface, at least you keep the range of application as wide as possible. If you need to go farther still, you're into the land of intermediate classes (such as the iterators in C++'s standard library) to standardise an interface by force. In that case, you can always implement a named interface there, but of course there's an inherent performance hit in doing so, and you really want such intermediate classes to be so lightweight that you don't even realise they're there under normal use.
My objection isn't just that primitive types and UDTs work differently, although that is a fundamental cock-up that should long since have been fixed. My main objection is that we already have a sensible way to represent these concepts, and it's absurd to go around reinventing the wheel, and in a somewhat arbitrary way at that, rather than going with the obvious.
Is it really wrong that a multiply-and-add operation on two matrices be written as M = A * B + C? Or that a new date should be calculated with seasonEnd = seasonBegin + seasonLength? Why is it in any way better to write something like:
M = A.Multiply(B).Add(C)
M = Matrix.Sum(Matrix.Product(A, B), C)
M = MultiplyAndAdd(A, B, C)
or any of the zillions of other possible permutations? Do you honestly feel that this is less subject to abuse, or less error-prone?
And why shouldn't my parameterised tree container, and the algorithms that operate over it, be able to work with int and float data, as well as BigNumber and FixedPoint values? Why should I have to write it all twice (at least)?
Operator overloading is much cleaner, reduces the programming effort required to develop parameterised data structures by a factor of at least two, and consequently reduces error rates. The only point I've seen against it that is true is that there is scope for misleading operator overloads to be provided. It isn't hard to see the conclusion, if only you sit down and look at it objectively.
Oh, and the implicit conversion thing relates to the fact that I can convert an object into a string just by context ("some " + myObject + " thing") but I can't implicitly convert to an int for analogous summation purposes, say.
Re:AAAAAAAAArgh -- missing the point sooo badly
on
Java Gets Templates
·
· Score: 2
I believe Java generics don't support primitive types, only classes and interfaces.
Oh, dear. I read about that when the proposals first flew around a while back, but I confess I thought they'd changed it, and didn't really check in detail this time.
That's a shame, because now one of the few really good things that was going to come of this hasn't.
However, IMHO the best solution isn't to add operator overloading, but rather to standardize an addition interface:
We already have one of those: it's called the + operator.:-)
But seriously, your approach is fundamentally flawed in at least one totally unnecessary way: it requires a different interface to be implemented for each relevant method, so a numeric class might well have to implement more than a dozen interfaces just to do the basics (and still wouldn't be compatible with primitive types, unless you're going to provide that interface for them as well). Presumably your parameterised functions or types are also going to list all the interfaces they require of each parameter type explicitly as well?
This is similar in concept to Comparable, and doesn't resort to operator overloading, which is, to Java, nothing but syntactic sugar.
But Comparable has always been a bit of a dark hat in a room full of white suits. It's there exactly because the need I'm talking about exists, but for some reason people I've never fathomed Java people don't seem to like operator overloading.
The question is, at what point does this break down? Do you provide interfaces for LessThanComparable, StrictlyLessThanComparable, EqualityComparable, InequalityComparable, GreaterThanComparable and StrictlyGreaterThanComparable, to correspond to the various equality and inequality operators? (Do you make the primitives provide them as well?) Do you try for more abstract concepts, such as Ordered or StrictlyOrdered? The latter is probably better style, but then you lose an element of precision that might be important when working with arbitrary types. Perhaps you start with an interface for each method, and then create more abstract, compound interfaces derived from them? But now, my poor little class that just wants to compare two int members for an ordering, is supporting multiple layers of interfaces, several at a time, and providing an artificial method, just so I can sort it?
Thanks, but I'll take operator overloading and proper generics any day.
And by the way: I'll think about admitting that operator overloading is mere syntactic sugar just as soon as you show me a class that works like a function, so I can pass it in to a generic algorithm.:-)
That's how templates in C++ work. It's not how generics in Java work.
I did mention that myself, if you check.:-)
In Java, if you specify that any class T can be used, you can call only methods declared in Object on variables of type T. If you want to call other methods, you must constrain the type to a subtype of Object.
And this is where the approach now taken in Java is seriously inferior: there goes your type safety. How, pray tell, are you going to mandate that some third party library developer must implement a suitable interface in any class they provide, such that you can write generic methods to work with a whole family of types that support the interfaces you need, without knowing in advance what they are? Must they implement a single-method interface for every method in their class, and must you specify explicitly which methods' interfaces are required for your generic function? I don't think you've thought this through far enough.
Slashdot Mirror
The problem with that idea is that while there is likely to be a fairly direct corrolation between working conditions and productivity, unemployment depends on a lot of other, independent factors.
For a start, you can fudge the figures very easily. The number of people who are not in regular, gainful employment in the UK is a very different statistic from the number of people claiming a Jobseeker's Allowance or similar benefit, and the latter is what the government's figures tend to report. That alone makes any meaningful comparison with figures from other nations nigh-on impossible.
Even if we ignore that detail, unemployment still depends on many economic factors that remain more favourable in the UK (fingers crossed) than they are elsewhere in Europe. I don't see that you can reasonably argue that our low unemployment is caused, or even mostly caused, by the sort of working conditions we're discussing.
Oooooh, you're evil.
But I like your style. ;-)
(Incidentally, I believe the guidelines in the UK now require various people, including cold-callers and call centre staff, to provide their name and the name of the company they work for at the start of any call.)
First of all, realise that you are asking for a quick-and-easy way to produce information that normally requires several years of solid experience in the relevant industry to estimate with any accuracy. You cannot possibly do this alone if you don't have a background in programming as well.
With that very necessary caveat, here are a few guidelines that might be of use. After discussing the reasoning behind them, I'll come back to address the questions in the original post.
It can take very different amounts of time to get the same work done, depending on a few key variables:
These sound fairly nebulous, but there are some key points in each case that make all the difference.
1. How good is the spec?
First of all, you must have good specifications of the requirements. Start with something written in terms of the problem domain: what data will be in the database and how it will be used, what you want to be able to do with the UI, etc. Then have people who understand both the basics of the problem domain and the details of software development produce specs in software development terms based on your original requirements. Depending on the size of your project, this might be as simple as a database schema or two and a description of what the UI will look like. Around this point, someone experienced will be able to estimate how long the remainder of the project would take a typical team.
If you don't have a good requirements spec up-front, then clearly you won't produce very accurate technical specs from it, and the error in your estimates will be commensurately higher.
2. How much does the spec change during development?
This is a killer. Requirements often will change during the development of a project, either because the client's needs evolve over the lifetime of the work, or because you realise that the original plan was flawed and have to adapt. However, it takes significantly longer to adapt to changing requirements than it does to get it right, at least mostly, up-front. If your requirements are concrete at the start, and the most you're likely to need to change is a few details to adapt to things not working out as you first envisaged, your project will move fairly efficiently. If you constantly change things under your developers' feet (which is common if your original spec wasn't very good, for a start) then you need to double or treble the expected lifetime of the project.
3. How good are your team members?
Individually, a good developer can get an order of magnitude more work done than a mediocre one. If you get several good guys together on your team, and they're also team players and not prima donnas, you can estimate a much faster completion than you would from an average team. Of course, you'll have to pay these people significantly better, but they'll be more than worth it.
Incidentally, when you're forming a team, do get someone technically competent to gauge whether they know what they're talking about. A non-programmer is simply not qualified to do this, no matter how many clever books they've read or how many buzzwords were in their management magazine last week. Screwing this up is a great way to multiply the lifetime of your project by ten.
4. How good is the controlling process?
In a good, lightweight process, working with good people and good specs, you'll find that your team spends around 30-40% of its time planning and designing, a similar amount or a bit longer on testing and putting it all together, perhaps 10% on actually implementing the designs, and a few percent on overheads, mostly communication within the team to keep things organised.
In a bad process, you can ramp those overheads way up, easily wasting 50-75% of your developers' time on unhelpful paperwork and needless communications. Again, it pays to have a good project manager/management team, or to employ someone with good organisation skills if it's a one-person job.
So, there you have it. A good team, working fairly uninterrupted from good requirements specs and with a good co-ordinating process, will probably put together your software 50x faster than a team of poorly-trained code monkeys who are constantly messed around and following a heavyweight process that doesn't respond well to change. Of course, this doesn't really much happen; if you aren't smart enough to use good people and let them get on with their job, your project will join the vast majority: it will fail and be cancelled.
Back to the original questions...
With all of that in mind, it's hard to give specifics without knowing a lot more about your particular job, but I can give you an idea of what a typical, small-scale database application might be like.
UI work often makes up 50% or more of a project. Databases require some careful thought up-front, but tend to be fairly straightforward. Integration with an existing system is a bit of a minefield; as ever, if you've got clear specs to match against (and the existing system actually follows them, which is far from guaranteed!) it's fairly easy, but if you have to work things out for yourself due to lack of accurate information, this can be a big risk.
It sounds as though this project is fairly small scale. Assuming you have average developers, a small database would probably take a man-week or two to design and implement. A UI to provide basic input, searching and reporting functionality for a database of that size probably takes 2-3x as long as making the database itself. If you're only doing a simple transfer of data to another application, that might be done in a matter of days, but if you're talking to a big custom database app using non-standard protocols and detailed interfaces, it could take several weeks.
All in all, you're probably looking at 3-6 man-months to design and implement a typical application of the sort I imagine you're dealing with. Of course, then there are the overheads, particularly up-front requirements capture and the testing and QA time, so overall you're probably looking at 1-2 man-years of development from start to finish. Clearly this has to be a very random figure without a lot more details, but it's about par for the course designing small custom database apps with a decent team and decent tools.
As to your final question about porting: this really depends very much on how different the platforms are. If you know ahead of time that porting is likely to be a requirement, you can invest a little time during development to save a lot of time reengineering things later. Using portable tools and programming languages makes a huge difference here, and having people on the team with experience of the idiosyncrasies of each platform to be used helps a lot, too.
If you've done this well and your project requirements are amenable to porting, you might port successfully in 2-3 man-months. At the other end of the spectrum, sometimes things are so different that it really is faster to rewrite from scratch, though obviously you'll have gained a lot of insight the first time around so you'll generally get the second implementation done significantly faster than the original.
Of course, whether such a contractual clause has any legal validity at all is a different matter; see the DTI information on working time regulations.
The thing that always amazes me is that incompetent managers continue to equate longer hours with higher productivity. The UK has the longest hours and lowest statutory minimum holiday entitlement of any EU member state, yet it also has almost the lowest productivity by any major benchmark.
The population of the US seems prepared to put up with any amount of abuse from the big corporate employers and such, and when someone from elsewhere with three times the annual holiday allowance suggests that demanding a reasonable limit on their working hours is entirely appropriate, I've seen US citizens here on /. rant at them about how they don't know how good they've got it. They just don't realise how abusive their employers are compared to the rest of the western world... <sigh>
By the way, I work in the UK, and I'm paid a salary rather than an hourly rate (and no over-time). My contract specifies a minimum 37.5 hour week, and I work pretty close to that. The company makes a genuine effort to treat its employees well, so most of us are prepared to cut them some slack when deadlines come up, but ultimately it's a two-way business relationship, and there are always limits to what would be acceptable by either side.
In contrast, at the last place I worked, the management was so worried about their financial state that they actually started asking people to defer taking their holiday entitlement, because we couldn't bill the clients for days when people were on leave and cash flow was that bad. Needless to say, everyone started taking their holiday immediately to make sure they got it at all, and many of the good people started looking for alternative employment around that point. Go figure...
Trust me, when you have to explain to a potential employer that you missed your finals because you were arguing with a cinema about the difference between 12am and 12pm so you could go see LoTR:TTT on the day it opened, you're going to be losing a lot more than $30k in salary income over your lifetime...
Works great in person. On a phone, you'll probably find everyone in the call centre has "supervisor" in their job title, so they can shift you around to one of their equally powerless colleagues as a first move. Always get the name and job title of the person you speak to, and ask a black-and-white question about whether they have more power to help you than the last person you spoke to.
One of the funniest experiences I ever had was when a phone company, who had apparently gotten a contract to supply hundreds of student rooms but forgotten to hire the manpower to install it all, gave us the "call centre tennis" treatment. Someone looked up the (publicly available) contact details of their managing director, and called him at home at 9pm on a Saturday night to complain.
By 10pm we had two vans full of engineers out to install the phones for everyone in the block whose order was running late.
Exactly.
I appreciate that this was modded Funny, but there's a serious side to it.
Around the time I finished my degree, I went into my bank, looking to take out a loan so I could buy a car to get to my new job and put down the deposit to rent a place. I wasn't asking for a vast sum of money, and I had a contract in my hand from my future employer that would provide a reasonable guarantee of my ability to repay what I was asking for.
I was told that, while the person I spoke to understood my situation, the computer would automatically reject any application for a loan while I was still a student. Further, if he even tried just to see, it would damage my credit record, as a "loan denied" tag would get stuck against my name for years.
So, I thanked him for his time, and left. Two hours later I returned, having opened an account with an alternative bank who were more than happy to match or better every term I had with my existing accounts, credit card, etc. and were also prepared to offer me a small loan to get started with my working life.
I walked up to the front desk, and just about loud enough for the other few dozen people in the branch to overhear, I said that I'd like to withdraw the balance on both of my accounts, clear the credit card and then close all three, please. "Oh, dear," the lady there said. "Is there anything we can do to make you change your mind?"
Doubleplusooops. :-)
Guess what happened for the next five minutes, in front of a room full of customers... Actually, make that ex-customers. Two other people, presumably in a similar position to my own, promptly moved to the queue behind me and closed their own accounts as I left.
Sometimes, the only way to make a commercial entity see sense is to vote with your wallet. Other times, bad PR is far more effective. Either way, it pays to stand up for yourself using language they understand. Make sure you give word-of-mouth credit and customer loyalty to the good places as well, and between the two, you'll find your life gets far easier. :-)
Portability. They are just as locked in as any other development team using a single proprietary compiler with its own custom extensions. As a result, they are stuck using a tool that, with all due respect, produces pretty mediocre output compared to the best in the field. That might not matter too much for an OS, since chances are it doesn't take much advantage of either the things the other compilers optimise better or the features GCC doesn't support properly. In general, though, it's a very serious point (said the guy who writes code that compiles on 15 different platforms every day).
Standing up for your rights is absolutely not taking advantage.
If I pay $5 for a ticket at one time, and they take my money, then that is that. We have made a deal, and both sides are morally obligated to honour it. If they didn't like it, they were free to decline my money.
If they later go back on the deal, then they are morally (and almost certainly legally) obliged to honour their original side of the bargain, or to offer suitable compensation. That might mean putting on an extra showing at the time indicated, or at least providing a full refund (and, if they're smart, complimentary tickets to another showing later on by way of apology), or otherwise making it up to their customers in some reasonable way.
Now, if it was a legitimate screw-up that they can't correct with, say, an extra showing, and if everyone has been offered a full refund and an apology, I don't think you can really complain much beyond that. If you don't like it, vote with your wallet. But the details aren't clear from the original story, and it certainly sounds like the theatre is pulling a fast one the way it's phrased.
Many. But how many web sites are there that provide access to high quality information with clear presentation, the way a good book or journal would? Very few, and most of them are supported by other means.
How do you know?
What would happen if IP laws did not exist is probably more like this...
Firstly, academic research would all but stop, because the only product it produces is information, and the value of that information is drastically reduced. Consequently the funding would rapidly dry up. The picture would probably be much the same in both universities and industry, for the same reasons.
As a direct result of lack of research, medical science would grind to a halt. One of the single biggest turnover markets in the world is medical research, but the reason is that doing that research costs a lot of money. If the people investing that money have no guarantee that they'll see a return on investment, they'll get out of the market. They may be greedy -- although for all the high prices they charge, they do spend a fortune developing the good stuff in the first place, and write off several more fortunes on all the ideas that don't work out first -- but they're not stupid.
Along similar lines, say goodbye to any hopes for faster, more efficient transport infrastructure any time in the near future. Car manufacturers are currently throwing staggering amounts of money into R&D for things like fuel cell cars. Potentially, they solve the environmental problems of automobiles once and for all, which I hope you'll agree is a goal worth aiming for, but without the knowledge that they'll be the only ones who can produce cars based on the tech they develop, at least for a while, they have no reason to invest in it only to see their competitors rip off the end results within months.
This same picture repeats itself all over the world. IP is not just about music, or software, though obviously both of those things are information-based and have the same driving economics behind them. Personally, for all we knock modern software, I'm quite glad we've seen the improvements we have over the last fifty years. And where did those improvements come from? R&D, of course.
Now, if the cost of maintaining the incentives to research and develop is having intellectual property, and convincing a load of idealistic script kiddies that they can't have everything for free just because they want it, then as far as I'm concerned, so be it. You don't go driving through the streets like a maniac just because your car can do 90, because there are serious consequences, and people understand that. The irresponsible few who do it anyway are, rightly, treated as criminals and dealt with accordingly. It's about time the current teen/20something generation understood that there will be consequences to their wholesale ripping of music and software as well, and accepted the corresponding moral responsibility to work inside the rules.
Taken to the logical extreme, that means that everyone in the world can get any information they want for free using P2P or the like, and no-one ever gets compensated for making that material in any way.
The problem with these free-everything idealist arguments is that they don't scale.
Unfortunately, the sort of society you're describing couldn't come about overnight. Those sorts of changes would take many decades to get right even starting from an organised beginning. In the period that would follow the breakdown of encryption, I suspect what you'd actually see would be a period of panic and relative anarchy, a clampdown into police states to control it, and subsequently many years of corruption in governments desperate to retain control until they could reestablish the mechanisms that were there before using alternative means. The entire game doesn't change at all -- breaking one crypto algorithm isn't anything like enough to catalyse that -- it just gets really ****ty for a while.
You've seen and heard a lot about terrorism lately, I assume. When the intelligence agencies screw up, and something like Sept 11 happens, you hear all about it. How many terrorist incidents do you think such agencies prevent for every one that happens? I'm betting it's quite a few.
I realise that a lot of intelligence officers just read the local papers and use their brains, but I'm guessing that on-the-ground in-with-the-bad-guys people are still pretty important as well. If you blow the cover of every single intelligence officer in the world, who do you think it's going to hurt more, us or the bad guys?
Next up... You have a bank account, right? How would you feel about not only letting anyone who wanted to see the details, but letting any script kiddie with half a brain play with the money itself? If you remove the encryption that's used when things like transfers are done electronically, what exactly is going to stop them?
Now, I don't know whether either of these specific things is a valid example. I kinda assume that military and serious finance types have more than just a couple of prime numbers to protect their data. Then again, screw ups do happen, so maybe it's not so much more. It doesn't really matter anyway. Even if these exact things wouldn't crumble if you released an efficient prime factorising algorithm, there are numerous other things along the same lines that are bound to. RSA is a well-known and widely used algorithm that would be cracked instantly, for a start.
Now, I don't know about you, but personally I rate my personal safety, the security of my finances, the confidentiality of my health records and such pretty highly. Right about now, they're reasonably protected as far as I know. If you release something that cracks such a popular and fundamental encryption technique overnight, that all disappears. Me, I reckon I'd prefer living in the West to living in a third world country where the only people who have any control are the guys with the biggest guns, but maybe I'm just dumb like that...
I truly and sincerely believe that you should think about that claim, and then think a whole lot harder about what you'd like to see replace it. There are plenty of places in the world, still, where the protections that we take for granted don't exist. I'm guessing you wouldn't like to be there a whole lot, and releasing all the stuff that's currently protected is a one-way trip.
I've always found it amusing that so many people buy beginners' books on technical subjects, and then post massively pro reviews on places like Amazon about them. By definition, these people are beginners in the subject, and therefore unqualified to review the books for technical accuracy!
By all means comment on whether you liked the writing style and presentation, but please... This is why people like Herb Schildt (familiar to almost anyone in the C(++) world) get rave reviews, yet continue to have enough serious technical errors in their work that informed critics write whole web pages pointing them out, in the hope that newbies see them first and don't get screwed because of their inherent naivety.
Trust me, you do not want to suddenly unleash an efficient algorithm for factorising into large primes on the world. For a start, security as we know it would more-or-less disappear overnight, if only because so much important data has been encrypted using algorithms that assume such factorisation to be hard.
It depends on what you're measuring.
While Quicksort is O(nlogn) in typical use, its worst case performance is O(n), although most serious implementations would use a variation such as Introsort to limit the worst case behaviour.
Mergesort is O(nlogn) in all cases. However, the constant factor is usually significantly greater than Quicksort, making the latter preferable for most uses.
Shell sort is significantly slower for most situations, though IIRC it's pretty good with data that's already almost sorted.
I think we're on the same wavelength, but just a couple of points are worth mentioning...
Firstly, it's almost invariably not true that (a+b)+c == a+(b+c) from a numerical analysis point of view. The problems of limited precision render such mathematical niceties, well, niceties. While I appreciate that it would be nice to program in a higher level language where such mathematical contracts were used, none of those under discussion around here will ever qualify.
As for overloading-heavy code being write-only, I couldn't disagree more. Code where operators are overloaded usefully (viz. typical mathematical types, string concatenation, etc.) is far more readable than the equivalent with longhand methods being used all over the place, particularly in a language such as Java that has no free functions. The only time such code becomes write-only is when the operators are overloaded in a misleading way (for example, having unexpected side-effects) and that's no different to the effect of choosing a bad name for any other function, or variable, or type.
And how, exactly, do you propose to work out who is "cheating the system" and whose use is quite legitimate? Is the use of + to concatenate strings acceptable to you? What about other string-like classes? How about for adding date/time and time period classes?
At the end of the day, you can never anticipate every use to which such a feature could usefully be put. You have two choices: try, and provide something that is sometimes useful but usually frustrating, or leave the choice to the informed developer, and let them do what they will with it. The fact that C++ is still here is testament to the fact that the second approach works. I can't think of a single language that tries to restrict the programmer this way that has lasted more than a short period.
It's not that they are necessarily not type-safe, not in the way that the current containers are because you have to perform a potentially wrong downcast to use them.
However, suppose I develop the world's greatest sorting algorithm, and I want to write a generic implementation for it to sort arbitrary sequence containers of arbitrary types. There are inevitably certain minimal requirements: I must be able to traverse my container in a suitable way for my algorithm to work, the types must support a suitable ordering relation, and so on.
As I understand it, several people in this thread are advocating the use of interfaces to ensure that only suitable types get passed to my sorting algorithm, thus ensuring type safety. The problem with that is what happens when someone comes along with a new container or sortable type that provides the necessary methods, but doesn't explicitly use that interface. Now my "generic" sorting algorithm can't be used, purely because of a naming issue. (I realise there are certain standard interfaces defined for things like comparison in Java, but obviously for types and algorithms in general that won't be the case.)
The requirement to implement interfaces explicitly is simply an unnecessary bar to the use of generics. In other languages, from C++ to SML, you can achieve similar effects without ever explicitly naming your interface. Instead, the algorithm simply fails to compile if it's used with types that don't match the way the algorithm uses them. Added to the presence of operator overloading, which standardises many fundamental arithmetic and logical operations from the start, writing generic algorithms that really are quite general is significantly easier.
Further, the concept of an interface as defined in languages like Java is inadequate to enforce useful constraints in practice anyway. The suggestion has been made, and refuted, many times in the C++ world, and alternative approaches to document and enforce constraints within template code have been developed instead.
The only alternative that I see as Java's generics stand today is to define all your generic algorithms to work with any Object, and go back to downcasting, but then you might as well never have bothered with generics in the first place.
Thus your two alternatives are either an interface-based system, which is type-safe but unnecessarily restrictive and less efficient, or to use generics only for type-safe containers and to write your generic algorithms in terms of Objects, which leaves open type safety loopholes.
Ultimately, implementing generic algorithms will always suffer because one man's search method is another man's find. It is helpful to offer methods of standard names to make generalising code easier, but clearly you can't have a standard interface for everything in a general purpose library that may be put to any use. I advocate the use of operator overloading, because the sorts of calculations performed by built-in operators tend to be useful in a wide variety of contexts. Beyond that, if your generics only deal with the methods that are actually presented, whether or not they're explicitly identified by a formal interface, at least you keep the range of application as wide as possible. If you need to go farther still, you're into the land of intermediate classes (such as the iterators in C++'s standard library) to standardise an interface by force. In that case, you can always implement a named interface there, but of course there's an inherent performance hit in doing so, and you really want such intermediate classes to be so lightweight that you don't even realise they're there under normal use.
My objection isn't just that primitive types and UDTs work differently, although that is a fundamental cock-up that should long since have been fixed. My main objection is that we already have a sensible way to represent these concepts, and it's absurd to go around reinventing the wheel, and in a somewhat arbitrary way at that, rather than going with the obvious.
Is it really wrong that a multiply-and-add operation on two matrices be written as M = A * B + C? Or that a new date should be calculated with seasonEnd = seasonBegin + seasonLength? Why is it in any way better to write something like:
or any of the zillions of other possible permutations? Do you honestly feel that this is less subject to abuse, or less error-prone?
And why shouldn't my parameterised tree container, and the algorithms that operate over it, be able to work with int and float data, as well as BigNumber and FixedPoint values? Why should I have to write it all twice (at least)?
Operator overloading is much cleaner, reduces the programming effort required to develop parameterised data structures by a factor of at least two, and consequently reduces error rates. The only point I've seen against it that is true is that there is scope for misleading operator overloads to be provided. It isn't hard to see the conclusion, if only you sit down and look at it objectively.
Oh, and the implicit conversion thing relates to the fact that I can convert an object into a string just by context ("some " + myObject + " thing") but I can't implicitly convert to an int for analogous summation purposes, say.
Oh, dear. I read about that when the proposals first flew around a while back, but I confess I thought they'd changed it, and didn't really check in detail this time.
That's a shame, because now one of the few really good things that was going to come of this hasn't.
We already have one of those: it's called the + operator. :-)
But seriously, your approach is fundamentally flawed in at least one totally unnecessary way: it requires a different interface to be implemented for each relevant method, so a numeric class might well have to implement more than a dozen interfaces just to do the basics (and still wouldn't be compatible with primitive types, unless you're going to provide that interface for them as well). Presumably your parameterised functions or types are also going to list all the interfaces they require of each parameter type explicitly as well?
But Comparable has always been a bit of a dark hat in a room full of white suits. It's there exactly because the need I'm talking about exists, but for some reason people I've never fathomed Java people don't seem to like operator overloading.
The question is, at what point does this break down? Do you provide interfaces for LessThanComparable, StrictlyLessThanComparable, EqualityComparable, InequalityComparable, GreaterThanComparable and StrictlyGreaterThanComparable, to correspond to the various equality and inequality operators? (Do you make the primitives provide them as well?) Do you try for more abstract concepts, such as Ordered or StrictlyOrdered? The latter is probably better style, but then you lose an element of precision that might be important when working with arbitrary types. Perhaps you start with an interface for each method, and then create more abstract, compound interfaces derived from them? But now, my poor little class that just wants to compare two int members for an ordering, is supporting multiple layers of interfaces, several at a time, and providing an artificial method, just so I can sort it?
Thanks, but I'll take operator overloading and proper generics any day.
And by the way: I'll think about admitting that operator overloading is mere syntactic sugar just as soon as you show me a class that works like a function, so I can pass it in to a generic algorithm. :-)
I did mention that myself, if you check. :-)
And this is where the approach now taken in Java is seriously inferior: there goes your type safety. How, pray tell, are you going to mandate that some third party library developer must implement a suitable interface in any class they provide, such that you can write generic methods to work with a whole family of types that support the interfaces you need, without knowing in advance what they are? Must they implement a single-method interface for every method in their class, and must you specify explicitly which methods' interfaces are required for your generic function? I don't think you've thought this through far enough.