A pretty interesting read that brings across 101 ideas that Mr DeMarco has found in his many years of helping make projects operate better.
While theA pretty interesting read that brings across 101 ideas that Mr DeMarco has found in his many years of helping make projects operate better.
While the story won't win any prizes, the ideas covered are quite topical and well described. If you are looking for an occasionally amusing, easily digestible way to take in some key concepts of software program management, than this is the book for you.
Do note that there are a few derogatory comments directed towards CMM and lean development (in the 90s meaning of lean). For the most part, I think his comments are well made and quite apt. He's not really anti those those things but he does make a point that if they are used incorrectly they will do more harm than good (and that they often hide deeper, nastier problems)...more
I'm a fairly well versed programmer in some of the older style languages like C and C++. If you have some archaic C question, I may be your woman. I'mI'm a fairly well versed programmer in some of the older style languages like C and C++. If you have some archaic C question, I may be your woman. I'm not so familiar with Java - in fact the last time I touched the language I could run to the local coffee shop, get a coffee, and get back to my program and it would just be starting up (back in the dark days, when java was really slow). Fast forward 12 years and not only is Java nimble and performant, but its something I need to know. Yesterday. Knowing this, I turned to the Head first series as they get their points across quickly and cleanly.
Head First really does teach the topics so that you'll remember them. Most into programming books give you an example and you work through it. In Head First, yes there is an example, but the examinations happen via stories, diagrams, pictures, games and really good (bad) humor. What this means is that no matter how you learn, you'll find something that helps the concepts stick. Each chapter builds upon the last and each chapter reinforces lessons from before. You can tell that people who really know how to teach designed these books.
Now this book is basic. I personally didn't mind reading about Objects and Object-Oriented design yet again. I also didn't mind reading about polymorphism, encapsulation, et al. The main reason for this is the presentation. Well that and there are a few subtle differences between C++ and Java that they talk about that I need to know. But mostly its the fun way they present the topics. I mean even if you know these topics cold, I still found some of their examples and comparisons well thought out and memorable. So much so in fact that I can see using them to help explain concepts to people I'll mentor or to marketing folks.
If, however, you have programmed in Java before and are comfortable in the world of OO, and are looking for something to take you to the next step, I'd suggest you keep moving onto other books (Effective Java by Bloch is amazing). However, if you are new to Java, and even new to programming, you'll love the Head First books. The writing is clear and engaging (and correct!), the examples make sense, and way they tailor lessons to trigger different parts of your learning brain is really well done. ...more
"Beautiful Data" is a collection of essays on data; how people have transformed it, worked within its confines, and offers a glimpse of where we might"Beautiful Data" is a collection of essays on data; how people have transformed it, worked within its confines, and offers a glimpse of where we might go. Many of the essays are wonderful snippets into how some people perceive data while others fall flat. Overall its a mostly enjoyable read that helps open up your mind to new potentials.
First a disclaimer; I am not a data person. However I've been involved, fairly heavily, in the data field. In the parlance of the world, I'm a back end person. However I'm always trying to think about the front end; how will things be used and what information can we gleen from the system (or systems). With that in mind, this is a book that speaks to me - its all about the front end.
Some of the best essays in the book would be:
The first essay by Nathan Yau he talks very much about user created data and personal databases (knowledge bases). What's exciting here is how he takes data already out there, data you have provided, and creates something useful and yes, beautiful, out of it.
The Second essay by Follett and Holm really gets down to how if you want the data, you need to present it in a way that brings people into the process. As someone who has a slight crush on the statistics and practices in polling (and designing poll questions) this essay really was a fascinating read.
The third essay by Hughes detailed how he handled images on the Mars mission. There wasn't anything here that wasn't done in embedded systems 15 years ago; still it was a great walk down memory lane since I used to program embedded imaging systems.
Chapter 4 really hit home PNUTShell is cloud storage and data processing in real time. This really is the stuff of the future.
Chapter 5 by Jeff Hammerbacher really didn't offer too many insights but his writing style is fluid and fun plus he offered a glimpse into how Facebook grew.
We then have the slow section of the book - Chapter 8 on distributed social data had promise but it read more like a company white page than an interesting article. Same with Chapter 12 and sense.us.
Thankfully chapter 10 on Radiohead's "House of Cards" video was there - and here we are presented with true beauty in data - beautiful enough to create a music video out of!
I'm still on the fence with Chapter 13 - What Data Doesn't Do. It was an interesting chapter but it felt both too long and too short at the same time. I almost felt that in the author, Coco Krumme, were to write a book on this topic, I'd want to read it. However her essay was not the right vehicle.
Finally, the last chapter - "Connecting Data" was a truly inspiring piece; one that offers up paths for the future. I am sure a few start ups will form over the questions posed in by Segaran (or maybe the questions to the questions).
Overall there were enough strengths to overcome the weak chapters. My main complaints are trivial; poor binding of the book, too many PhD candidate papers and not enough from out in the trenches. I'd love to see something from Stonebreaker here; its hard to talk about beautiful data and not have him in it. Or forget Sense.us and talk about many eyes. Or map reduce. Still, "Beautiful Data" succeeds. It opened up my mind to different possibilities for data representation and usage. ...more
Mr Reese has taken on a loaded topic and in less 200 pages he succinctly gets his major points across on that most nebulous term; Cloud Computing.
StaMr Reese has taken on a loaded topic and in less 200 pages he succinctly gets his major points across on that most nebulous term; Cloud Computing.
Starting in the first chapter, Mr Reese begins with his definition of cloud: 1) it must be accessible from a web browser or web service api (non proprietary) 2) 0 capital expenditure to start 3) you pay for only what you use
These simple statements provide the baseline for the rest of the book.
From here he dives right into the meat of the matter. The majority of the book details the things you, and your organization, will need to keep in mind as you move, or contemplate the cloud. Some of this is very obvious; cost of ownership, security, disaster recovery, hardware costs, backup, scaling, etc but Mr Reese pulls out the threads that make the cloud different: both in good ways and bad.
For example, a new wrinkle for cloud is what happens when your cloud provider goes out of business or has a poorly worded injunction exposing all their data (including yours) to the federal government? This is not something you worry about when you own the servers. Mr Reese elegantly explains how you can make this something you don't need to worry about even in the cloud; as long as you use some type of encryption.
Another example of where the cloud provides a potentially huge win would be in disaster recovery. Here a cloud provider provides redundancy of location and with virtual machines you should be easily able to get your system up and running again fairly quickly as long as you've taken the proper precautions (snapshots and a sane backup strategy).
Throughout the entire book, he really drills in security in the cloud. In several of the chapters, not including the security chapter, he keeps coming back to how the little things you do in your design can have a huge impact on your overall security. This is a major worry point and a barrier of entry point for many and Mr Reese spends just the right amount of time explaining how you can truly mitigate the security risks.
Another thread that runs throughout the book is scaling your application. This, to me, is one of the bread and butter wins of cloud computing. Mr Reese talks to some designs that work, and some that don't, when it comes to scaling. While all scaling talk is high level, I believe he succeeds in getting you the reader, to know what questions to ask in your next architecture meeting.
The book is a great overview and it focuses you to ask the right questions when you are dealing with cloud computing. Especially on the Amazon system. Mr Reese takes great pains to point out that yes, he is biased in talking about Amazon since that what he knows. Two appendices do talk about GoGrid and RackSpace but those read more like slick marketing glossies. And that's one of the two failings of the book. The other minor quibble is that a few times Mr Reese tries to go into detail about how something is done on the Amazon cloud (especially EC2 and S3). This is a mistake given how high level this book is. The appendix on the EC2 instructions also seem a little out of place. However these are minor quibbles.
If you are looking for a great introduction to the cloud, what it is and how to think about it, then this is the book for you. If you are looking for something to help you program, interact and learn the API for say Amazon, this is not the book for you. ...more
I really wanted to like this book more - at times the information is really good, like the "working in the background" section. However most of the boI really wanted to like this book more - at times the information is really good, like the "working in the background" section. However most of the book feels like bits and pieces were cut and pasted into place. Thus author seems to repeat himself often, especially early on. What's worse, the repetition doesn't reinforce any major points of the platform either. I'm left guessing that the book was rushed to print before it was fully edited.
There is some good information here though. And this gives a solid glossing over many of the major themes of Android - which makes this a decent compendium. So if you are looking for an overview of simple GUI development, general, small applications, and some talk about background processes and communications and some of the hardware you could do a lot worse.
However, you could also go to the Android development website and get the same information there as well. ...more
What a great book! Every programmer and manager should read Joel - even if you don't agree with him, he brings up tons of points you just cannot ignorWhat a great book! Every programmer and manager should read Joel - even if you don't agree with him, he brings up tons of points you just cannot ignore. For instance, one of my pet peeves is lack of up front planning. And when I say lack, I mean none. The amount of pain this has caused me in the past is impossible to measure (and there is a reason I'm reasonable good with time estimations - I plan what I can up front). Reading him talk about the lack of planning in software dev really warmed my heart.
Another nice little piece was his talk on strings at the beginning. As an embedded engineer I know first hand how costly string manipulations are. I tend to forget that not everyone knows this. Its good to see a mainstream programming book take this topic on.
I will also admit to loving his support of Microsoft; I also feel that they get short shifted and for similar reasons (they really did bring computing to the masses). Finally Joel nails the differences between Microsoft programmers and Linux programmers - to a T. The general breakdown is MS programmers design the GUI first and add the CLI later while the Linux folks do the opposite. In general, this makes a lot of sense, especially when you compare Linux and Windows from about 2 yrs ago. Or Gnome today (KDE ftw).
If you program, or love someone who does, read this book.
"Software Estimation" by Steve McConnell provides a very broad overview of many ways to reduce the software estimation errors for your development cyc"Software Estimation" by Steve McConnell provides a very broad overview of many ways to reduce the software estimation errors for your development cycle. Like all of Mr McConnell's books, he provides crystal clear writing with tons of techniques that are ready for application in the real world.
One of the many great things about "software Estimation" is the sheer number of methods he gives. From Lines of code, to function points, to similar projects, to industry estimates (broken down by sub category so that database is different from embedded devices), to t shirt sizing, to maintaining development history: he makes it clear that you have a lot of different options available to you. He takes great pains to emphasize that one size does not fit all. Additionally he gives rationales for when the estimate techniques work in a project's lifecycle.
With all the methods described, another point driven home is that software is something of an art and that you can reduce the amount of uncertainty but you can never fully remove it. None of the methods that improve estimation are silver bullets. I love that he draws the line in the sand here. Its very true and in fact he goes a step further, pointing out that on successful projects the "cone of uncertainty" converges as the project matures. The converse is also true. Wise words indeed.
The final chapter feels more like a tack on, however the message contained therein is something that needs to be stated again and again: marketing/management is not the enemy. It is important to remember that everyone has the same goals and that the battle really should be a collaboration. However good this chapter was, it still felt out of place.
There are a few niggling issues that I had. The biggest gripe is that he talks a lot about estimation software packages. In fact, he makes assumptions that the reader has knowledge of these packages. Working in start-ups, I've never even heard of these packages until this book. Its a small gripe, but it did detract. Another issue would be some of the examples on applying the various techniques towards the end of the book were far too glossy and far to dry. I think there was some good information there but you, as the reader, will need to make a few assumptions. Which, to me, is always a dangerous thing. Not as bad as fighting a land war in Asia, but still dangerous.
Overall though, as a software engineer/manager I found this book to be invaluable. The techniques are usable right away and really helped me convey the uncertainty I had in ways that I wasn't able to in the past. I think this should be required reading for anyone who works in the software industry. ...more
Sometimes you read a book and you find yourself feeling an eerie sense of Deja Vu. Dreaming in Code is just such a book. The main premise surrounds thSometimes you read a book and you find yourself feeling an eerie sense of Deja Vu. Dreaming in Code is just such a book. The main premise surrounds the Chandler project and how its project lifecycle grows and changes over time.
What was truly fascinating was watching all the pitfalls the project went through. In almost every case I had the sense of having had that happen - from feature creep to lack of testing to a un-articulated design - I've been there. Its even more interesting to see the same mistakes I've lived through repeated here - you'd think we'd have learned from the past.
Sprinkled within the story were tangents into the history and theory of programming. These were sometimes interesting but, especially towards the end, they felt like filler.
Still this is a great book and very much worth reading by software professionals
if there is one book on c++ that every programmer should own, its this one. This is the book I'm constantly going to when I forget something or need tif there is one book on c++ that every programmer should own, its this one. This is the book I'm constantly going to when I forget something or need to get more information on some STL class...more
solid discussion on the patterns of software programs run amok. More importantly, it has a few ideas on how to bring the miscreant programs back on trsolid discussion on the patterns of software programs run amok. More importantly, it has a few ideas on how to bring the miscreant programs back on track. Its a little dated and a little on the light side at times but overall well worth the read ...more