You can pull up to 500 photos per flickr API call, so it's possible to fetch up to 180,000 photos per hour while staying under the limit.
638 karma · joined July 4, 2009
A smart elevator algorithm would adapt to the arrival behavior of people in a building through some clever stochastic simulation and modeling. For example, a simple model that could work quite well is to optimize for (read: minimize) the average time any passenger would wait for an elevator to arrive. But to do this, we need to model how frequently people request an elevator on each floor over the course of the day.
Modeling elevator requests - We can assume that the number of people who request the elevator on each floor is a Poisson process with a mean of n. On a representative day (i.e. for an office building, choose a weekday), we can observe the number of people who arrive at the elevator each hour. This data would drop in as the n in our Poisson arrival processes.
Computing optimal solutions - Using a statistical library, we can start generating simulated arrival data and apply integer optimization algorithms to determine which floor the elevator should rest on when there are no elevator requests, for each hour of the day.
Where engineers feel most repressed is when they are the ones directly making money for the company, but are being taken advantage of by "business people" who aren't making the company money.
You're right -- the people who work on products that makes the company directly are generally treated (and compensated) better at good companies. Imagine if these same engineers weren't treated well... I doubt they'd have much respect for their business-y colleagues/bosses.
A potential cause of the rift between (software) engineers and business people could do with how each group attempts to optimize for returns in their work.
In an ideal world, a software engineer aspires to write elegant code just once, then deploy their work on as many systems as possible (for installed software), to as many users as possible. The software engineer's dream: 1) write code once 2) profit off it indefinitely 3) scale up profits by running the program on as many computers (or for as many users) as possible.
In a "business person's" ideal world, they would come up with a magical process that prints money that is easy to rinse and repeat. A good example is the fast-food franchise model. The business person's dream: 1) come up with a repeatable money-making process 2) profit off it indefinitely 3) scale up profits by running the process with as many people as possible, in as many places as possible.
Before software became big business, business people and software engineers probably got along just fine. I'm guessing it was because most software engineers (or programmers at the time) played a mostly supporting role to the core business of these big blue chip companies. For example, they might be writing software to help cut costs or improve operations efficiency at a large manufacturing company.
Then software itself became a moneymaking business. Now software engineers were optimizing their work input to maximize profits by exploiting computer cycles. All the while, some of these "business people" in software companies came from the traditional school of thought. So they were optimizing to maximize profits by exploiting human cycles (basically employees, and this included software engineers). If anyone didn't want to be treated like a computer program, it was the software engineers. You can probably see where this is going -- this led to a point of contention, or power struggle, between the engineers and business folks.
P.S. If anyone has a link to the article I was referring to please do share!
Might have to wait a bit for the clip to load as Vimeo doesn't allow you to play from an arbitrary point of the video.
Once the idea of "completeness" is crystallized (based on listening to what people want), I think that's when it's a good idea to build it right.
By "building it right", I don't mean to pay the same amount of attention to all features for the sake of completeness. Here, I'm a proponent of the 80/20 rule. Specifically, that the important 80% of the features be implemented first. That doesn't mean ignoring the remaining 20%, just that the rest of it will need to be hashed out later/eventually. An 80% product is enough for a demo/risk-loving early adopters, but ultimately customers want to pay for 90%-100% products.
In my life at least, it's been rare to come across a math professor/educator who pushes harder for understanding (connecting the dots) rather than knowledge (disjointed lists of equations and theorems). Mathematicians' laments aside, inspired teachers are already changing the way that some students -- albeit a small minority -- view the field of mathematics.
For most problems that individuals face each day, linear programs are fairly simple to model and solve. However, there are lots of complex problems that are solved each day.
A few examples of large-scale linear programming problems: - For Amazon.com: what quantity of each item should be stocked at each warehouse each day to minimize inventory while also optimizing for shipping time and cost to demand nodes (customers). - For an airline: how to plan and schedule flights to all domestic and international airports to maximize profit - In shipping logistics: how to allocate trucks and set routes to minimize fuel cost while satisfying delivery time.
For complex systems, you can easily run up a linear program with millions of independent variables (producing millions of rows in the linear system).