Comment from Xun Cheng
Time: January 2, 2007, 5:07 pm

It will be a nice book to read.
Regarding the difference betwen building engineering and software
engineering, I think the followings make a big difference:
1. you bid for the building contract before starting to build it and
once you win the bid, the “feature” of the building is set.
2. the land for the build is not a shared “space”. Once someone
starts a building project on it (such as a housing project), no
one else can “challenge”/compete by building something
potentially better/cheaper on the same land.

xun

Comment from W_W
Time: January 5, 2007, 8:15 am

sounds like a failure in the making, a book about software programming for the non-programmer?

[quote]
So while I hope that programmers will enjoy this work, it is meant equally or more for the rest of us.
…
I’m barely an elementary programmer myself. I wouldn’t presume to try to teach the experts.
[/quote]

The title also seems to be ripping off one of the better known programming help websites out there. Was this intentional to gain awareness of your book, or a ploy to gain sales due to the commonality of the names? Perhaps it was an honest coincidence, but in either case, what is there to be learned from reading about:
[quote]
three years following the work of the Chandler developers as they scaled programming peaks and slogged through software swamps.
[/quote]
whilst you tell their stories?

I don’t think i’ll be reading this any time soon.

Comment from Scott
Time: January 5, 2007, 8:37 am

Well, Marvin, nothing like dismissing a book before you’ve looked at it

As for “ripping off” anyone, when I conceived the book’s title in 2002-3 I poked around for “prior art”, as it were. There was a relatively low-profile documentary film by the same name; other than that, in four years of crawling the Web reading about software development I never found a site with a related title. So without more detail I’ll have to plead ignorance on that one.

Comment from mr programmer
Time: January 5, 2007, 11:13 am

My error: dreamingincode.com is what i meant to type. they just sound so similar. 😉

Comment from W_W
Time: January 6, 2007, 10:14 am

I appreciate your honest answer, Scott. As hard as it is to believe, it is possible you overlooked the site in question. It would appear it has become a little out of hand with a few of these posts, i was merely stating my opinion on what i could know of the book thus far. As a programmer of nearly 15 years, i must say i am still not inclined to read it.

Comment from Adrian
Time: January 9, 2007, 2:33 am

As a programmer for some 30 years, I think you have captured the essence of what is wrong with our industry. I will definitely read this book as Chapter’s 0 and 1 give an indication that there will be many valuable insights. I feel never too old or experienced to learn from other’s wisdom and experiences.

Comment from Lee
Time: January 18, 2007, 11:19 pm

Thought perhaps you’d started at chapter 0 because, in the tradition of BASIC programming, you forgot a line and didn’t leave enough space between the line numbers!!! 😉

Comment from Keith Raile
Time: January 23, 2007, 7:16 am

I am retired now but I spent 30+ years working in the software environment including development, support, management, marketing, & coding in a variety of languages. I spent so much time reading ‘core dumps’ (boy does that date me) that I started counting everything in hexadecimal. My specialty was Operating System Internals. Not something interesting to ‘normal’ people.
I purchased your book ‘Dreaming in Code’ and although I haven’t completed it yet I am enjoying it immensely. What memories it evokes. Congratulations on a job well done! I have raised a son who is doing software development and my 15-year old grandson is cutting his teeth on several languages, including BASIC and now Python. I really want to share your book with them and I have several options, buy them their own copy, loan them my copy, or … what I would really like is if this book were made available in audio format. Is there any chance of that happening?, or should I pursue options 1 or 2?
Thanks again,
Keith

Comment from sdf
Time: January 24, 2007, 6:34 am

joel now has his review up: http://www.joelonsoftware.com/items/2007/01/21.html

Comment from DaniGro
Time: January 30, 2007, 2:07 am

did you know that Mitch was asked several times by programmers from Europe to make a realistic time table for Chandler ? in 2004 and 2005?

Comment from Dave Beedon
Time: February 3, 2007, 4:51 pm

I just found out about “Dreaming in Code…” through salon.com. The thing that always irked me when working on a project, whether software-related or not, was management’s obsession with deadlines and its lack of discipline about sticking with a configuration that everyone has agreed upon. Those last-minute requirements can result in huge amounts of re-work, but the bosses don’t want to hear it. Idiots! FORTRAN drowned me, but I had fun with BASIC. Cheers.

Comment from Paul Randolph
Time: February 4, 2007, 9:23 am

I just finished reading Dreaming in Code. I liked it. I’m glad I saw James Fallow’s pointer to the book; and that I put it on my Christmas wish list. This book helps me see my work in a big picture context, which is valuable, since I’m in the atomization of my work. It gave me a feel for the Chandler experience, a summary of project management methods, and a long term view of computer evolution; and along the way I compared and contrasted with our product teams. I already quoted it in an Email to one of our teams.
Thanks,
Paul

Comment from Tal Rotbart
Time: February 4, 2007, 8:37 pm

Hi Scott,
I’ve replied to your earlier comment regarding my post.
http://www.rationalistic.com/2007/02/05/software/rosenbergs-law-rephrased/#comment-201

Cheers,
Tal Rotbart

Comment from Donald W. Long
Time: February 5, 2007, 11:57 am

The problem I see in many software projects is that testing is not done until QA mode. Most developers do not wish to be involved with this task.

I can say this with lots of experience. I work for a company called PolySpace and we create a tool that finds Run Time Errors in code and it should be used at the developer level. We have found that its very hard to reeducate the developers to use tools along this line. Most would rather wait until QA. At this point things are bottled up and the project will slip.

Have a nice day

Comment from cmm
Time: February 14, 2007, 5:59 am

The title of the book caught my attention. Just the other day I asked my boyfriend, “Do you think I will ever stop dreaming about code?”. My sister for years had no idea what I meant when I would tell her about how my code was going. Software programming is a mystery for a large percentage of the world. I cannot wait to read the book.

Comment from Sam Adams
Time: February 15, 2007, 11:18 am

As I read this book, I was amazed at how many times I said to myself, “finally someone else has recognized the same absurdities in software development that I have experienced”. I particularly enjoyed the discussion about whether software development is more like artistry than engineering. Every developer should read this book, if for no other reason than to have it drilled into them that there are no silver bullets or fool-proof development methodologies or languages, and that having one great success does not guarantee future success. I just have one question for you Scott: before writing this book, did you create a specification and a design for it ? Did you write the book using the iterative development method ?

Comment from Jeffrey Travis Atwood
Time: February 17, 2007, 11:38 am

“Dreaming in Code” is an excellent broad overview of how many projects become stymied and lose their way. Few managers have the luxury of trying various approaches simultaneously to see which team wins, like competitors. This injects urgency into the environment and forces advocates to put their money where their mouths are.

Regarding the comparison to bridge construction:

When we build a bridge, we can anticipate weather and traffic conditions from decades of recorded history. The surrounding city can only grow so fast, the river bottom can be explored, even earthquakes can be modeled. A lot of eyes view every construction element so that there are more knowns than unknowns. In the end, a bridge is so expensive, “fixed” and necessary that people are willing to live with the result even if it isn’t perfect; this process is more science than art.
With software, there are too many variables to test every combination, the hardware and software environment and infrastructure change regularly (upgrades and “fixes”) and are never thoroughly tested, we have tools which allow us to build something temporarily then tear it down, start over, throw out parts, and constantly invent new techniques; in the end, if it isn’t perfect, people aren’t willing to live with it and will throw it away or ignore it because they have alternatives; this process is more art than science.
Programming is still too process-centric rather than data-centric or information-centric. It’s like the processing side has trumped in the expression “data processing”. Until we can automate the building of programs like Henry Ford automated the building of cars and we can agree on data standards, everything is going to be bespoke, expensive and hand-crafted. The Henry Ford of data processing hasn’t come up with a good solution for automation yet.

Comment from thomas
Time: February 26, 2007, 5:08 pm

as a kid coming into the world of computer coding, Scott Rosenberg’s novel was a very interesting read and gave insight and information into the world of coding architects. He wrote of problems, shortcomings, and tediousness of the designing process, but also gave the feeling of optimism throughout all of the misery.

Comment from Justin
Time: March 19, 2007, 11:43 am

Loved the book, hope it starts a trend. I find it fascinating to get insights into a specific organization / project like that.

Comment from Jay
Time: March 20, 2007, 4:22 pm

Ive been programming for 8 years, and I just finished reading the book over the weekend.

Outstanding.

Well done Scott. I’m making this mandatory reading at the office.

Comment from Doug
Time: March 22, 2007, 6:33 am

Scott:
Hi. I very much enjoyed Dreaming In Code. To the question: “Why can’t we build software like we build bridges?”

One possibly useful perspective is to look at the question from a Use Case perspective.

Compared with software, bridges and other engineered structures have a fairly limited number of possible Use Cases. A bridge must be able to withstand a certain load of vehicles, a certain velocity of wind, a certain movement of the earth, etc. The number of possible Use Cases for complex software is so large that a complete test, for all possible Use Cases, is not possible. Look at what happened on 9/11/2001 when two buildings were subjected to the unexpected Use Case of contact with a 757 flying at high speed? The structual engineers of those buildings probably would not have predicted the actual result–that both buildings would “pancake” as if they had been subjected to a very well-designed, carefully executed, demolition.

My twenty plus years of working in the software development business has taught me that our “failure-to-complexity” ratio is much lower today, than in year’s past. And although, the reliability of our software does not approach the reliability we expect from bridges and other engineered structures, we probably could safely guarantee our software will be failure-free, for every Use Case we have tested.

So, from a “Use Case” perspective, might we successfully argue that software, bridges and buildings, all have about equal reliability?

Comment from William
Time: May 16, 2007, 7:40 am

Nice website.

Comment from FEAR
Time: May 27, 2007, 3:33 am

whoa you had computers in 1975, did they run on coal 😛
i look forward to reading this book

Comment from Robins Tomar
Time: June 9, 2007, 4:08 am

I totally agree with your opinions about the software industry, this industry is really changing.
I will consider reading the book once I get promoted to Program Analyist.

Comment from Sandy
Time: June 9, 2007, 7:41 pm

My tutor for Advanced Software Design (programming in Java) recommended ‘Dreaming in Code’ to make us feel better about the struggles that we have in writing our own code. I finished reading it a few minutes ago. Overall, it was a well-written book, with amusing titbits scattered throughout, and I enjoyed it a lot, though now and then it got a little dry as a lot of good books do. I’ve recommended it to someone else is who is also sometimes a programmer.

Comment from Freelance Website Design
Time: June 15, 2007, 6:28 am

I read your excerpt and it was well written. I am going to grab the book I think.

Comment from Andy Polack
Time: June 16, 2007, 10:50 am

Dreaming in Code is a book I have been reading by Scott Rosenberg. It is a fascinating look into why software projects so often flounder and fail. It would take a pretty thought-stimulating book to pull me back into the blogosphere again, and this book is it. This one has me excited folks.

As a computer science and mathematics double major, I feel like I have my fingers on where the computer science field is headed. Programming is becoming increasingly mathematical and elegant. Gone are the days when we banded together into small groups of two or three people and spent a night in our parent’s basement coding in Basic to create the next big 8-bit killer app or the days when assembly showed us a repetitious and slow picture of programming. Now software of all kinds is put together by professional teams of programmers relying on highly complex and optimized software. If you are a programmer out there and reading this, it is all sounding very familiar, I know.

What amazes me is the lack of planning and forethought that Rosenberg seems to imply goes into designing software. He leaves his readers with a feeling that programmers are mavericks of some sort – fly-by-nighters who get the job done and then run to the next task without regard for documenting what they have done. To a large extent, my guess is that this is partially out of a need to entertain his readers that Rosenberg does this – but I can’t help but feel like there is a certain thread of truth behind it. I have seen more than my fair share of overdue projects thanks to ill planning and preparation.

This is a disappointing revelation. I have learned first-hand at the college level, what poor planning and management can do to a software project. When I am writing code, particularly with a partner, I spend the first several hours in front of a blackboard, not a computer. Also, when I run into troubles programming in the middle of a project, I take time to step back and hit the chalkboard again. I talk through my ideas and work hard to make sure everyone knows my view. I’m not hesitant to throw out prior work and start fresh.

This leads me to the type of team dynamic I see quality software thriving under. There must be one leader of the team, someone not afraid to make a decision without as much information as the team might want to have… someone who will keep the project moving forward and not backward. That leader, however, must also recognize and yield to tension from his team. If a member has a different idea, a different structural approach, it is the job of the team leader to ensure that view is heard. Often if I am playing the leadership role, I will hand the chalk over to the person who wishes to comment on my scheme. “Don’t just tell me your idea, draw it out so we all can see it, it’s probably better than mine” I tell them. Ninety percent of the time, that is the case… my partner or teammate sees an easier way to tackle the problem we are working at. That is part of the process of software design though… teamwork is vital.

That is not to downplay the importance of individual contribution. I approach programming like I approach mathematics. In math, when you are stumped by a hard problem, you mull over it a while… you let it seep into your subconscious until everything you do reminds you of different aspects of that problem. It has been said by some that mathematicians have a haunted or aloof air about them; that is because they are always so focused on the abstract… on the cleanest solution attainable. It is the same definition of elegance that software designers strive for in their code that mathematicians strive for in their proofs. Master one, and you will have a good idea what it takes to master the other. While I can claim to be no Einstein at either mathematics or computer science, I have written my fair share of proofs for classes and have a good mathematical intuition for an elegant solution. It heightens the senses and makes you feel alive. It is better than any drug, it must be. The adrenaline kicks in and the endorphins fly. There have been times both in programming and in doing mathematics where I have been so impassioned by it so as to be driven to let out a sort of primal scream – an audible reaffirmation of my success, either at comprehending the beauty, or contributing to it.

Non-“mathies” or those foreign to programming will likely have little idea what I am talking about here… at least with regards to mathematics or computer science. For those of you who fall into this category – think of something you excel at (something in the arts works best for this thought experiment, but any asset will do). Think of the feeling of elation you get when you successfully complete a task related to that asset of yours. That feeling, that fleeting second when you could be no more proud – that is a programmer’s nirvana. It is that feeling software endeavors must capture in its members. Programmers’ individual contributions to a project should elicit that sort of “nirvinic” reaction from peers.

I am convinced that with the atmosphere of teamwork and programming nirvana I have spoken of, that fewer software projects would fail. With a good problem specification and these traits, any software team can and will develop something innovative, useful, and elegant.

Comment from Sky O.
Time: August 1, 2007, 5:24 pm

Why can’t we build software like we build bridges? Probably just because software engineering is a younger science/art.
I found it kind of eerie that just last night I finished reading Dreaming in Code, and then today this is in the headlines:
http://kstp.com/article/stories/S156329.shtml

😉

Comment from diet
Time: August 7, 2007, 6:09 am

Many usefull tips in your book. for pre-intermediate and expirienced programmers

Comment from Joseph Roy D. North
Time: August 14, 2007, 12:04 pm

I cannot entirely concur with your assertion, “Because computers count from zero!”, just allow me to assure you!
When I started with IBM’s FORTRAN II in 1963 on an IBM
1410 mainframe, the array index for subscripted variables
started at 1, NOT 0, which was Mathematically (i.e., a natural number) correct.
When I started with C in 1987, those indices started at 0, NOT 1, which is Mathematically INCORRECT, I continue to believe!
This inconsistency has always perturbed me – as a
Mathematician – and it should – at long last – be rectified, i.e.,
NOT be allowed to be propagated in perpetuity, I believe!
Penultimately, therefore, computers can count from either
0 or 1, therefor, whatever their human masters require!
“And ye shall know the truth, and the truth shall make you
free.” (ref.: St. John 8:32, KJV, 1611).

Comment from Tim Wright
Time: August 23, 2007, 6:05 pm

I just finished reading “Dreaming in Code” and felt it was time to comment.

Here’s the executive summary. “Brilliant!”.

I started coding on a “Compukit UK 101” (Ohio Superboard) – a 6502-based system with 8MB static RAM and basic in ROM. I have been programming for quite a long time at this point In the intervening 30 or so years, the disparity in our advances in the hardware space vs the software space are painfully obvious.

I am very lucky to work in an organization with many highly talented and experienced engineers, yet I still feel that they would greatly benefit from reading the book. It does an outstanding job of explaining why software is “different”.

Frankly, it should be compulsory reading for anybody whose job touches on software in any respect whatsoever, be they programmers, development managers, project managers, etc. Given the ubiquity of computers and software, it would be highly enlightening to everyone else.

Bravo!

Comment from Sam
Time: August 29, 2007, 4:37 am

Dreaming in Code could be fun or painful. What reaction does the title give you? If you can’t bear to open the laptop on the weekend then stay away, it will be like work. If you feel lucky to be paid doing something you’d happily do for free then give it a try

Comment from Rick Jordan
Time: September 17, 2007, 9:06 am

I loved your book. Besides strong feelings of empathy with the programmers at Chandler, after turning the last page, my lasting impression was a sense of relief.

Relief because your book confirmed a notion of mine: That the Open Source movement has little chance of threatening the profit-driven, commercial software community in any significant way.

Programmers, like myself, thank Microsoft and Bill gates on a daily basis for creating a standard (imperfect as it may be) and an infrastructure to develop software that clients are willing to pay for.

Many of us are often too busy making money to be bothered with rants and flames regarding the injustices of the world that seem to permeate the Open Source community.

It reminds me of the the socialists and Communists in the 60’s – the it sounds really good to bash the establishment but eventually when they needed to pay a mortage and send their kids to schools, many of the liberal threw off their robes and sandals and put on their grey suits and loafers.

Likewise, the Open Source movement sounds great and has instant appeal. But like Communism and socialism, it just doesn’t work in real life.

Comment from Vanesss
Time: October 1, 2007, 8:18 am

I heard that computers in 1975 were as big as a house, am i right?
To be honest, i have never been interested in programming language, using computers only for mails and chat. But i just read the excerpt of your book and it sures look very nice. I think i finaly found where i will be using my amazon gift card I’ll come back once i read it, Vanesss

Comment from Website Builder
Time: October 4, 2007, 11:27 am

Hey Vanesssa,

Well kind of. I started in the business in 1974 and the mainframes were kept in large rooms that had to be air conditioned. The programming language used most often in business apps was COBOL.

Despite what many people say nowdays it was kind of a neat language.

I myself haven’t programmed in 10 years except for a little php. I mostly used off the shelf software for anything I need as there is so much to choose from.

It is amazing to see how computing has progressed from the mainframes to the PC and everything in between. I still remember when we had minicomputers the size of fridges at our branch offices to run apps to do data collection that we would then transmit to the home office via modem a few times a day.

Very sophisticated stuff back then.

Mike

Comment from mic
Time: November 13, 2007, 10:02 am

Engineering is a human activity, practiced by individuals and teams of people. Too few books talk about the people and how they worked together to build something new. This is the best book about computer engineering since “The Soul of a New Machine” a generation ago. It follows a team on an ambitious open source project and shows who writes great software, and the satisfactions that make them work hard to do a difficult job well.

Comment from David
Time: November 24, 2007, 5:04 pm

I congratulate you for bringing such an important and complicated topic to the general public. You have performed an invaluable public service, to introduce the arcane world of programming to a general audience. Most impressive is the way you have interlaced your Chandler story with a tutorial on the history of software development. Try as we might, the tar pits of Frederick Brooks are still with us, afflicting us with their painful obstacles which have yet to be overcome. Yet, through all the smoke and debris of failed projects, I have seen a ray of hope. The hottest field in software project management today is disaster recovery. Since the majority of software projects are horribly mismanaged, disaster recovery specialists have come along to rescue these otherwise failed projects. Once these specialists come in, the first thing they demand is total control. Then they marginalize the offending management, sales and customers while putting the software development team at the heart of the project. Then they institute mandatory software processes like source code control, daily builds, daily tests, metrics and earned value. By the time they are through, the software escapes from its death march into the light of usability. The question remains: Why do disaster recovery experts have to be called in the first place? Why can’t projects just be properly managed from the beginning? The basic disconnect between business managers, project managers and software teams may take a generation to be resolved. For now, disaster recovery looks like our only sure-fire way to fix the problems which you identified.

Comment from Ciaran
Time: November 25, 2007, 1:18 pm

I have worked as software developer in numerous product companies since 1989. I was fortunate enough to be part of projects involving small teams of good engineers together for a couple of years at a time in exciting and ambitious undertakings. I think Scotts passage where he witnesses the repair of large portions of the Golden Gate Bridge provides a brilliant context for the often asked but naive question “Why can’t we build software the way we build bridges?” I interpret this differently from many of the other readers: Who would wish to even ponder the costly and traumatic replacement of this rusting structure. Who would wish a similar fate for the software they had written?

On software project management “disaster recovery”, when really bad things happen to software projects (and they do) it is mainly due to lack of experience or lack of talent. Putting the right people in place is the first step and by the way, source code control, daily builds, daily tests are bread and butter among competent software developers, not part of a silver bullet to “fix” a project in crisis.

Frameworks like EJB and web development are the COBOL of today, programmer straitjackets that “cripple the mind”. Headed for obsoletion and someday to be relegated to the status of cautionary tales, technologies such as these are frequently put forward as Silver Bullets. In education, the learning of so called “hard” concepts such as pointer manipulation and garbage collection is regarded by many as “obsolete”. Those who disagree are treated with the same contempt as the boy who saw that the emperor had no clothes. To solve many of software developments current ills, begin your revolution in Universities.

The “big picture” that computing students search for is probably so big that none of us can see it. Software development “HARD”? Give me a break. Of course it is hard. Bridge building is hard. Anybody wise will tell you that nothing worthwhile is easy and if it was everybody would be doing it. In fact, the most fundamental software blunders were usually made by people who lacked experience and made wrong choices, underestimating the difficulty of a task being undertook, not executing due diligence in their investigations or perhaps they simply were unqualified. Of the people who have made such mistakes, some never see the error of their ways, or never accept responsibility, or don’t stick around to clean up the mess. However, there will always be a few who are eager to put their hands up, point out the flaws in what they have built and want to do it again, differently. We call these people engineers, those who some day should take on a project that is the software equivalent of the Bay Bridge replacement. But they will never complete such a project “without a hitch”. That is never how the software engineer expects it to be.

Comment from Jeff RPG
Time: November 28, 2007, 9:01 am

I think it’s an important topic that the general public should be more aware of. Everything we use in our every day life, going from ATM to video games, had be be programmed. People are not aware of the important role programmers are playing in our life and the book is the perfect way of informing them. It is not a boring definition of what the job is and actually brings us to want to learn more about the subject. What i have to say is great book, i spent a lot of my free time in the last week reading it, i am not done yet, but i just love it.

Comment from Greyrock
Time: November 29, 2007, 11:09 am

Scott,

I’m just finishing reading your book. Having just retired from a 40 year career as a programmer, software designer and development team manager I think you captured perfectly the psychology, issues, frustrations and joys of the software development enterprise.
Good work!!

Comment from Asia Business Advisor
Time: January 5, 2008, 7:59 am

Why can’t we build software like we build bridges – a well-thought out question.

My take on this is: probably because human mind is unique in thoughts of how to build software (service/application etc.), as for bridge there are physical demands and requirements from architectural point of view that limit the thoughts – thus making building bridges easier task due to laws of nature that do not apply so much for building new endless permutations of code for endless new expectations by users of software.

Comment from Top news
Time: January 8, 2008, 5:58 am

Hi! loved your book. Besides strong feelings of empathy with the programmers at Chandler, after turning the last page, my lasting impression was a sense of relief.

Comment from ross T
Time: January 25, 2008, 9:44 pm

I loved this book! I have been a designer of medical products for many years and I think Scott really got it right when he described the real process involved in innovation. Too many companies try to just make copies of things. A blue laptop instead of gray, or a word processing program with 13 ways to copy and paste.

To invent takes guts. And sometimes the process involved in innovation isn’t always a straightforward path. It’s fraught with failures, dead ends and U-turns.

Someone once said “Invention is a blind man in a dark room looking for a black cat that probably isn’t there”.

Comment from Calculator
Time: February 8, 2008, 7:30 pm

Probably one of the best books about team collaboration. It’s astonishing seeing each individual talk about their approach to productivity software where their own productivity seems to fluster. This book establishes a great enlightenment about knowing how to understand the personalities of your team members in order to figure out how to communicate and cooperate with each other.

Comment from adana evden eve nakliyat
Time: February 20, 2008, 5:17 pm

On software project management “disaster recovery”, when really bad things happen to software projects (and they do) it is mainly due to lack of experience or lack of talent. Putting the right people in place is the first step and by the way, source code control, daily builds, daily tests are bread and butter among competent software developers, not part of a silver bullet to “fix” a project in crisis.

Comment from jb
Time: April 6, 2008, 12:53 pm

Just bought it at an airport bookshop. Thanks for writing this book ! As James Fallows says ” The first true successor to Tracy Kidder’s Soul of a New Machine”, but it’s been such a long wait ! And I’m only on page 0 (I love that). Really enjoying it. I am a programmer of 30+ years.

Comment from cyprus property
Time: April 11, 2008, 6:51 am

s I read this book, I was amazed at how many times I said to myself, “finally someone else has recognized the same absurdities in software development that I have experienced”. I particularly enjoyed the discussion about whether software development is more like artistry than engineering.