Any serious programmer has dreamed of code. A great day for me is a day when I don't want to go to sleep because I'm in the zone coding and in the morning I wake up early to get coding as soon as possible. Flowcharts, lines of code, and programming concepts all jump over the fence all night as my brain solves whatever puzzle I'm working on.
Programming is solving problems. Programmers have been solving problems for more than 50 years now, but there is still no consensus on how to do software development. I've been in the computer software industry for more than 30 years and I keep hearing the same complaints and ideas being recycled again and again.
The book Dreaming in Code: Two Dozen Programmers, Three Years, 4,732 bugs and One Quest for Transcendent Software chronicles a software development project in the early 2000s. I found it all very familiar and sighed deeply many times as I followed a team face the same hurtles and obstacles I faced during my career in software development. I'm proud that as Director of Release Delivery, Architecture, and Portals, the company I worked for delivered every release on time while I was on the job for more than 4 years (4 to 6 releases a year).
I was mostly a project manager but also an advocate for repeatable processes and systemic attitudes towards delivering software. When everyone was on board, it was great. Software flowed out the door on time and on budget. But every time new management arrived I had to justify why it took so many people to get software out the door. "Why can't we just zip up the development libraries?" I was asked more than once. Arrrrrrg!
After I left the company they didn't ship another release for more than 2 years. Should I feel bad about that? I don't.
Dreaming in Code shows the non-technical reader why it is so difficult to create and deliver software on time and on budget. I encourage all people interested in software development to read pages 239 through 269 to get a high-level overview of the methods that have been tried to produce solid software. It's a good read.
Programming is solving problems. Programmers have been solving problems for more than 50 years now, but there is still no consensus on how to do software development. I've been in the computer software industry for more than 30 years and I keep hearing the same complaints and ideas being recycled again and again.
The book Dreaming in Code: Two Dozen Programmers, Three Years, 4,732 bugs and One Quest for Transcendent Software chronicles a software development project in the early 2000s. I found it all very familiar and sighed deeply many times as I followed a team face the same hurtles and obstacles I faced during my career in software development. I'm proud that as Director of Release Delivery, Architecture, and Portals, the company I worked for delivered every release on time while I was on the job for more than 4 years (4 to 6 releases a year).
I was mostly a project manager but also an advocate for repeatable processes and systemic attitudes towards delivering software. When everyone was on board, it was great. Software flowed out the door on time and on budget. But every time new management arrived I had to justify why it took so many people to get software out the door. "Why can't we just zip up the development libraries?" I was asked more than once. Arrrrrrg!
After I left the company they didn't ship another release for more than 2 years. Should I feel bad about that? I don't.
Dreaming in Code shows the non-technical reader why it is so difficult to create and deliver software on time and on budget. I encourage all people interested in software development to read pages 239 through 269 to get a high-level overview of the methods that have been tried to produce solid software. It's a good read.
RSS Feed
