Live data from Hacker News

Project from Hell (2008)

projectfailures.wordpress.com

61–70 of 157 posts

Re: Project from Hell (2008)

#61
post #12

Earlier quoted context omitted.

> And there are people who claim performance doesn't matter, only correctness does. Hmm.. Performance is meaningless if the code is not correct. After all, I can make the code arbitrarily fast if I'm not going to be held to any standard of correctness: It always returns "FOOBAR". Done, and very, very fast. > Also: we chose C++, because it is fast. That is a bit naive. C++ is a standard, so how fast is a stack of pape…

C++ is only "fast" because people who care about performance use it and a lot of people who are good at compilers work on gcc/intel/llvm. If the LLVM team decided to spend 5 years making python "fast", I bet they could make it benchmark just as well as C++.

> If the LLVM team decided to spend 5 years making python "fast", I bet they could make it benchmark just as well as C++.

Better, perhaps, if John Walker's experiences with Javascript are anything to go by:

https://www.fourmilab.ch/fbench/fbench.html

John Walker has a program called fbench which is a floating-point benchmark built around raytracing. He's implemented it many times, in many languages, throughout the decades, beginning with implementations for the original IBM PC.

Anyway, the results are posted on the site, in terms of multiples of the speed of the C implementation, which is defined to be 1.0. The Python implementation is 2.633 (PyPy 2.2.1 (Python 2.7.3), Linux), and the Javascript implementation is 0.372 (Mozilla Firefox 55.0.2, Linux). Yes, it completes in approximately a third the speed of a C implementation compiled on full optimization (-O3) by GCC 3.2.3.

(The C++ implementation is at 0.939, GCC 5.4.0 -O3.)

Anyway, Javascript has been the target of a lot of people for a fairly long time, and, despite the fact it's a very dynamic (hard-to-optimize) language... well, the numbers speak for themselves. I have no doubt Python could be improved to a similar degree.

Downloads: https://www.fourmilab.ch/fbench/

The weblog post where he analyzes the modern Javascript numbers a bit: https://www.fourmilab.ch/fourmilog/archives/2017-10/001715.h...

Re: Project from Hell (2008)

#62
Being from France and having worked in a company that deals mainly with government contracts, I've seen some of these aspects first hand.

The company I was in was far from being as horrible as the one mentioned in this post and management was not complete douchebags, they never fired people for being 1 minute late, didn't impose strict hours.

On thing to keep in mind is that public contracts are extremely unhealthy for all the parties involved.

The government agency as more rights than a private organization asking for the same kind of job, the agency can impose everything as long as it is written in the scope statement document (which is rather mediocre in general, can be vague, can be self-contradictory and some requirements may not be doable at all), your actual technical offer as little weight.

I remember a project where we got screwed by one pretty vague phrase mentioning a document (which was not provided during the call for bids by the way). In this document there was a lot of idiotic guidelines regarding software path installation, init scripts, users running daemons... that even the government agency didn't follow internally, and that made any kind of automation extremely difficult. We got screwed also by indecision from the client in this project, first Debian was chosen, then CentOS, then a mix of Debian and CentOS, I reinstall our platform 3 or 4 times before it was decided...

Then there is the other part. The bids are generally quite competitive, and the most important factor is the price generally, little digging is done on the actual technical quality of the answer. As a result, these projects are generally undersold, with the idea that it will be possible to ludicrously bill maintenance and changes of scope after the initial contract. As an example, I've seen a project where the risk provision was ridiculously low despite the fact a core piece of the system was an off the shelf software that existed only on paper at the time of the call for bids (and we lost several months trying to make it work and advising the editor).

Also, sometime some legitimate risks are taken but are not completely assumed. For example, most of these contracts will have a tight schedule, but in general, the government agency will be quite slow on their parts (buying servers for example). So it's safe to assume that your tight schedule is a bit more lax, and you have more time than what is written on the contract. It's taken into account in the bid, but in the end, management doesn't remember it and ask you why it took more than the tight schedule agreed in the contract.

Globally, everybody is trying to screw everybody at the detriment of the users who actually need the system.

And as an engineer, it's really not satisfying to work in those conditions, you constantly cut corners (unit tests? no.), you have to make due with what you have (I literally stole old servers that seemed abandoned by other projects to work) and you produce sub-par systems that will blow up in production (and you don't have access to production systems, so any bug is pretty much catastrophic).

I decided to left this company when a sales guy told me that we were losing money because we "engineer were too perfectionist".

Re: Project from Hell (2008)

#63
post #34

I love how the first thing complained about was the use of C++ for the project. Compared to the lack of sane source control and release management, inexperience of the team, dozens of layers of abstraction, management bureaucracy, toxic culture, basic facilities like toilets being inoperative... I think using C++ was literally the least of their concerns.

They also started, if I'm doing my arithmetic right, in 1996. Honestly, I could see C++ having been their best choice back then. Every language I would rather do a large project in is either newer than that or would have been pretty immature for a large project in the mid-90s.

C++ was pretty immature for a large project in 1996. It was first standardized in 1998.

Re: Project from Hell (2008)

#64
post #35

Earlier quoted context omitted.

> So they were not really employees, but consultants. On places where it's hard to fire people, mostly everybody works as consultants and people tend see those positions as normal job positions.

In Germany it is hard to fire somebody. Almost nobody works as consultant, and consultants are not normal job positions.

Skilled consultants are to some extent mashed together with unskilled labor in politics and law and there has been a very long campaing now to basically make hiring contractors extremely unattractive.

So now you hire an engineering consultant, train him/her for a few months on the job and are forced by law to let that person go after 18 months to repeat the cycle.

Re: Project from Hell (2008)

#65
post #12

Earlier quoted context omitted.

> And there are people who claim performance doesn't matter, only correctness does. Hmm.. Performance is meaningless if the code is not correct. After all, I can make the code arbitrarily fast if I'm not going to be held to any standard of correctness: It always returns "FOOBAR". Done, and very, very fast. > Also: we chose C++, because it is fast. That is a bit naive. C++ is a standard, so how fast is a stack of pape…

C++ is only "fast" because people who care about performance use it and a lot of people who are good at compilers work on gcc/intel/llvm. If the LLVM team decided to spend 5 years making python "fast", I bet they could make it benchmark just as well as C++.

There's more to it than that. C++ is designed for implementations to produce fast code. "Leave no room between C++ and Assembly" has been a guiding principle of C++. This is not true of Python, and thus the engineering effort required for an implementation to reach the same level of performance is huge, if at all possible.

Re: Project from Hell (2008)

#66
post #12

Earlier quoted context omitted.

> And there are people who claim performance doesn't matter, only correctness does. Hmm.. Performance is meaningless if the code is not correct. After all, I can make the code arbitrarily fast if I'm not going to be held to any standard of correctness: It always returns "FOOBAR". Done, and very, very fast. > Also: we chose C++, because it is fast. That is a bit naive. C++ is a standard, so how fast is a stack of pape…

C++ is only "fast" because people who care about performance use it and a lot of people who are good at compilers work on gcc/intel/llvm. If the LLVM team decided to spend 5 years making python "fast", I bet they could make it benchmark just as well as C++.

No, It’s not possible to optimise Python like c++ because of the characteristics of the language. Plenty of very good people are working on Python optimisation and it’s still painfully slow and will always be.

Re: Project from Hell (2008)

#67

>Average turn-over for the newcomers: 3 months, the legal time to leave your job in France. Can someone explain the meaning of this? I think something got lost in translation.

I took it as you aren’t allowed to quit until you’ve been somewhere for three months.

Actually it depends. When you're on probation period in France you can quit as well as be fired on the spot or within 2 weeks depending how long you've been hired for (don't remember the exact timeframe). Then after your probation period is over (it can last from 4 to 7 months) there is 3 month notice period on both (employer and employee) sides.

Re: Project from Hell (2008)

#68

> “C++ for dummies” on many people’s desks. Surprised they didn't get fired for reading/learning at work when you're paid to be programming all the time. Although I've never been fired for reading at work, I've had it made clear on multiple occasions at different jobs that reading wouldn't be tolerated, and I was already down a couple of strikes.

What in the actual fuck? I can't fathom how this would even theoretically work. Like people ostensibly would just memorize every api and library they might ever have to use in advance?

Re: Project from Hell (2008)

#69
post #61

Earlier quoted context omitted.

C++ is only "fast" because people who care about performance use it and a lot of people who are good at compilers work on gcc/intel/llvm. If the LLVM team decided to spend 5 years making python "fast", I bet they could make it benchmark just as well as C++.

> If the LLVM team decided to spend 5 years making python "fast", I bet they could make it benchmark just as well as C++. Better, perhaps, if John Walker's experiences with Javascript are anything to go by: https://www.fourmilab.ch/fbench/fbench.html John Walker has a program called fbench which is a floating-point benchmark built around raytracing. He's implemented it many times, in many languages, throughout the de…

That is only a very specific benchmark and as that post said the result is so strange probably because of the changes in the C trigonometric functions lib that slowed down a lot to increase precision.

Re: Project from Hell (2008)

#70
post #35

Earlier quoted context omitted.

> So they were not really employees, but consultants. On places where it's hard to fire people, mostly everybody works as consultants and people tend see those positions as normal job positions.

In Germany it is hard to fire somebody. Almost nobody works as consultant, and consultants are not normal job positions.

In Poland social insurance is lower as a contractor. Also taxes for someone with high income (linear scale).
Post reply on HN