At a previous employer, I got to see this whole turn of events unfold [the wrong person deciding to move to "The Cloud"]. It went something like this:
a) CEO (non-techie btw) gets wind of "The Cloud"
b) SalesForce.com reseller somehow gets past the call screeners and directly to the CEO's phone.
c) CEO flies to San Francisco to a "DreamForce" convention to see Sting perform and hear Colin Powell speak and hear Virgin and Coca Cola sing praises to the platform.
d) CEO signs up for 3 years of SalesForce.com and a bunch of addons without consulting anyone
e) CEO flies back and tells everyone (and I quote: "OK everyone, I'm driving this car down the street with no headlights on, hang on, here we go!")
Needless to say I was out of that place not soon after. It was a real shame to see this "Cloud" technology forced down everyone's throats on a whim of the CEO, when he had absolutely _zero_ input from anyone else in the company (IT or otherwise). Especially when we had a really good system in place that just needed a few tweaks to make it perfect.
My friend who still works there now as to run around like crazy coding a bunch of APEX scripts just to hold things together. It's a sad, sad mess unfortunately.
IMHO, a good developer needa to CARE about what he/she is writing.
I'll say that again! Good developers also need a proofreader when posting on
IMHO, a good developer needa to CARE about what he/she is writing. Here are some points I've gathered from two decades of development work:
Care about the code
The quality of the code, efficiency, consistency are all key. Internal documentation is very important. Even if you don't think anyone will *ever* look at that code again, guess again. Someone will probably end up going back over it in the future to fix a bug or add a feature -- often times that is YOU, the one who wrote it. So leave enough comments behind to tell the next guy (or you when you've long forgotten that code) what in the world you were thinking. I've known way too many developers that simply say "yes sir" to their boss and crank out the code as fast as possible. They don't bother to think for themselves things like "what would the customer want" or "how can I design this to be as efficient as possible but still be understandable"? People who view development as simply a "day job" and don't take pride in their work end up causing themselves and others pain down the road. Being a developer should be more than simply writing code that works. You should care enough to write code that works and is elegant.
Care about the end user
Whether your code is a script that nobody will ever see, or a GUI application that people will use daily, a good developer puts themselves in the customer's perspective. They care about efficiency. They care about how the people who will use their software on a daily basis will perceive it, and how it will impact their workflow. Try to imagine how shaving even a few seconds off a process that someone does many times a day could add up over the years. With the power of modern computing, it's all too easy to become lazy as a developer and not put much thought into scalability, or to write sloppy code that doesn't make good use of resources.
Care about robustness and security
Writing good code also involves covering yourself in terms of error trapping. Make sure your code can (attempt to at least) fail gracefully when the unexpected occurs. Also, make sure you always code with a view to security. Way too much software is written in such a way where security and error trapping is put off until later. All too many times, due to time constraints or simply forgetting, these tasks never get done, and as a result insecure, buggy software is released.
Don't be afraid to start over
Good developers also aren't afraid to refactor their code. Sometimes it takes finishing a good chunk of code and analyzing how it performs in the real world to realize you did it all wrong and you need to rip it up and redo it. That's OK. Try to learn from it and do it less as you mature as a developer.
Memorize the headers and APIs you use most
Try to memorize headers and such of key APIs and libraries you use often. Personally, I find it all to easy just to keep looking up that function over and over whenever I need to use it. But if you trust yourself and memorize the documentation, then you can code more efficiently with less interruptions from having to go and look up that function call every time.
Keep it simple
It's easy for a developer to code "the kitchen sink" and bombard the user with a million options and settings. Yes, the program can do everything someone could possibly want, but overwhelming and confusing the end user is never a good idea. It's much better to think things through carefully and build only what is necessary, or if all the options must exist, build it in layers so the most important options are visible first, then the advanced users can dig in and configure to their heart's content.
This is the same problem we've always had, whether its someone's website on a shared host or a colo server. You need to back it all up and doing a naive dump of the entire thing will take too long and cost too much in bandwidth, so you take a dump of the entire thing once (preferably when you have the thing you're deploying locally) and then take incremental backups from there.
I agree with this approach. If you can get an initial full backup and then use something like RSync with a cron job to handle the incrementals, that would be ideal.
Some info regarding RSync with EC2 is here: http://stackoverflow.com/quest...
One of the worst offenders when it comes to data exports has to be salesforce.com. If you delete a single custom object they charge you upwards of $10K USD to recover your data: https://help.salesforce.com/HT...
Even worse, you get it back in CSV format. My former employer decided to go with them for their entire operation (sales, marketing, and production/warehouse). I left around the time they started implementation, and it was a complete nightmare!
I recall the customer experience when Apple itself went from the Symbol scanners to the Linea Pro sled + iPod combo as being pretty much night-and-day. The old devices were clunky and slow, and the new were fast and efficient. Being able to sign with your finger onscreen was also a big plus. Paperless receipts are great!
I disagree. For our implementation (see my post above), it was two of us and we managed to connect many disparate applications. As long as you understand what you're interfacing with and sufficient API documentation exists, it's not that difficult. We managed to connect to UPS, FedEx and USPS for shipping label generation/package tracking, Authorize.net for payment processing, DBA Manufacturing (the legacy MRP system we were using) for importing the customers, suppliers, and items, and OpenCart for our web store.
It took the two of us about 12 months of solid work to accomplish this. I'm sure Telsa's ERP system involves a lot of supply-chain connections (good ERP systems need this capability), yet they were able to pull it off in 4 months.
We just went through this exact same exercise at the company I work for. When our antiquated, poorly-designed MRP system started causing too many headaches, we carefully counted the cost of moving to something like Salesforce.com or SAP, but ultimately ended up writing out own system from scratch. After running the two systems in parallel for 6 months to ensure the new system had data integrity we were comfortable with, we cut it off. Having just closed our first month "live" on the new system, I must say it's a real breath of fresh air for both the IS staff and the rest of the company. Gone are the days waiting for the slow moving MRP company to update their slow system to add features or fix bugs for us. Our hands were tied with the old system, and now the door is open to all sorts of possibilities. People are constantly saying "wow, we can do xyz now!" or "this wasn't even possible before with the old system". The daily complaints about the old system have been replaced with daily feature requests and positive comments.
The small team that built it remains on staff, and if something doesn't work, we fix it. If someone requests a feature that makes sense to the overall design goal, we sketch it out, schedule it, and implement it. We carefully weigh everyone's feature requests and implement only those that make sense for the overall "greater good" of the system. That way we keep feature creep down while building something that helps people get their job done faster. In the time between bug fixes and feature request, we are constantly polishing the system to make it more efficient. We now have a DEV environment where we can test out new ideas and features and release them to production only when they are ready.
Since we built ours with FOSS technologies, it's been a joy to integrate with our other trading partners (suppliers, our web store shopping cart, etc). The money we are saving on not having to pay for licensing costs (recurring yearly, never ending), we have invested in hardware and infrastructure to run the new system.
Perhaps the biggest benefit is when the system is released, the company will have a team on staff that knows the system inside and out, because they built it.
I would highly recommend any company considering buying an out-of-the-box ERP system to consider having an in-house team build them a custom solution. With the right group of developers, it can be a really rewarding experience for everyone!
If entropy is increasing, where is it coming from?