And here's a review of '21st Century C' from Andrew Binstock at Dr. Dobb's:
http://www.drdobbs.com/architecture-and-design/developer-rea...
Note that the review is on Page 2 of the article.
2,034 karma · joined June 13, 2008
http://www.drdobbs.com/architecture-and-design/developer-rea...
Note that the review is on Page 2 of the article.
It's that simple. It won't be easy, but it will be worth it. There are no silver bullets. For anything.
I've done both, and to be honest, FamilyTreeDNA seems more comprehensive to me.
The latter seems to break posting up between StartUp or non StartUp.
Reminds me of Jesse Storimer http://jstorimer.com/ who originally published 'Working With Unix Processes' independently which subsequently got picked up by The Pragmatic Programmers: http://pragprog.com/book/jsunix/working-with-unix-processes
Currently working on some books myself.
Of equal value is "the War of Art" by Steven Pressfield.
In my opinion, these are the only two "self help" styled books anyone needs.
Just because people want what you've built does not necessarily make it meaningful. Meaning is a very subjective, personal thing, based on your core values. What person x finds meaningful and is willing to pay for, person y may think is meaningless. So ask yourself whether you want to build something meaningful to you, based on your core values or do you just want to build the next hot game/app/whatever, and get rich. There's nothing wrong with the latter, but be honest with yourself.
I've been in situations where critical system changes to support new products were being described in Business Requirement documents, sent to the vendor for translation to Technical Requirement documents, returned to the client for approval, and then scheduled for implementation at some point usually 6 months beyond the original requirements process completion.
Could this be why there are NO widely used open source business systems in the financial services, heath care, and banking industries?
I've thought long and hard before about how to supplant a current legacy system that's taken root like an old oak tree in a financial services company. I honestly don't know how.
For example, a Life Insurance Administration System in a small insurance company. First, let's make some broad assumptions to make things easier:
1. The system will be "go-forward" only. i.e. we will not convert current policies onto the new system. 2. The system will NOT support any current product lines, but at launch will only support new product X, which is still in the product planning stages.
Given those 2 assumptions, how much customization will the new system require? The answer that everyone hopes for when they buy the software from the vendor (and the story the vendor sells) is, very little. The reality is that the system that goes live is usually very, very customized OR it ends up being very under utilized and simply interfaces WITH THE LEGACY SYSTEMS to meet the requirements of the product team, the regulatory bodies, the actuaries, etc. etc.
So what's a legacy system hating hacker to do?
The only way I could see legacy replacement being feasible is if big corp X decided that they were going to do full in house system development, and then market the core or the resulting system to their competitors. This isn't unheard of, and has been done in the past, but is pretty rare. The trend over the last 20+ years has been to out source virtually all of IT and buy off-the-shelf, vendor supported software to administer daily business. The argument, that big corp X is not in the business of software development is difficult to argue against. Alas, the end result is vendor lock-in, increasingly expensive services contract, and stagnant systems that are impossible to pry your business loose from.
The in-house/out-source cycle is fairly common in big financial services/health care corporations, usually on about a 4-8 year schedule.
I suspect the HN audience is not particularly interested in legacy systems development, or how one's insurance policy is administered. But, the next time you notice how large your insurance premium payment is, or complain about bank fees, or drug dispensary fees, etc. etc., stop and think for a second about what that money is paying for. In the case of insurance (which is the industry I'm familiar with), I'd argue that for a low-risk client, that a large percentage of your premium goes to administration of some sort.
* The Myth of Uniqueness: Each and every company doing business believes that their business is different and couldn't possibly be the same as another company's. This is not completely untrue, but it's also not completely true. The problem is that this myth is propagated by the enterprise software vendors. The profit margins on services to customize software is far, far greater than the margins on software licenses. It is in vendors best interest to promote software customization.
* 50 Years of Customization is Hard to Throw Away: OK, maybe there's not many 50 year old systems running in production any more, but there are 25 year old systems. The amount of money spent to customize those systems over the years is enormous and big corps are not eager to toss that money spent away to start over.
* Database Conversion is Hard: Not so much difficult, but hard in the sense that it requires many, many hours to first clean up the old database, run the conversion, then validate the new data. One mistake could mean that someone's policy lapses because the conversion broke the automated Pre-Authorized Cheque processing code for that one client.
* Working at Big Corps is Uncool: Let's face it, being a programmer at a big bank or insurance company is perceived as boring. The over 40 set that these jobs appeal to aren't traditionally big adopters of new technology. As these people get promoted into decision making roles, they default to safe, known technologies.
* Corporate Partnerships: Big financial industry companies outsource their IT to corporations like IBM. These services companies have a vested interest in maintaining the status quo. It's much like bee-keeping bears ;)
* The old stuff still works: Even though the legacy code is unreadable and numbers in the millions of lines, it still mostly works. The "if it ain't broke, don't fix it" argument is an easy one to make when your executives (beholden to the shareholders) have to make their quarterly numbers.
Don't get me wrong, I'd love to see start-ups in the financial services software industry pop up with innovative solutions. In fact, I've thought about attempting this myself, given my background. But the elephant herd of legacy vendors to find your way around is extremely intimidating. In fact, I actually saw a few small vendors pop up over the years, get small contracts within the big insurance company to do something innovative with their shiny new technology (but not mission critical to the corporation), and then watch that company take on more and more lucrative services contracts further from their core software product. Eventually, their initial product offering becomes a footnote for them and they turn into something else, legacy related.
The Elements of F*cking Style: a helpful parody. http://www.amazon.ca/Elements-cking-Style-Helpful-Parody/dp/...
The Yahoo Style Guide http://www.amazon.ca/Yahoo-Style-Guide-Ultimate-Sourcebook/d...