For more information: info@acmesoftwareworks.com
Remember Software Development
is an social event.
About Acme Software Works:
Acme Software Works started in 1988 when I wrote CleanUp a file utility for DOS. I didn't sell many copies but the company under the name Dugger & Associates, Inc. was able to land a number of consulting contracts over the years with companies like IBM and Verizon. I have resurrected the name Acme Software Works a few years back and started developing software and hardware again.
About Me:
My name is Don Dugger. I am a retired Software/Hardware Engineer / Development Manager. I worked primarily in the Telephony industry. Started designing hardware in the early seventy's, and when the microprocessor became available I also wrote the code. From there I just kept writing code. And I'll still writing code.
I have worked as a hardware engineer and as the head of quality assurance early in my career. However most of the time I was working as a software engineer. I also managed large projects all of which were in excess of 100,000 lines of code and employed as many as 25 engineer. The problems of software development has been on my mind for decades. I have listen to academia over the years and have often felt that if they were in the trenches with us they may see things little differently. One thing I have come to understand is the best approach to software development depends a great deal on the type of project. Coding an app for a cell phone is very different then coding the infrastructure for a cell phone network. I do not want to come off as though I feel superior. I believe the it takes a great deal of skill to create a decent cell phone app. It's just that the rules are very different.
When I first started writing code we used a teletype machine and enter the code through a serial port. There were ROMs we could get from the CPU manufacture called a Monitor or Bug programs. Which allowed us to interact with the CPU and store and retrieve memory data a bite at a time. The first programs I wrote were enter this way, it was tedious and took an inordinate amount of time. It became clear early on that we were going to need development computers if we going to get anything done. The computers we used were largely of our own design that we had build for propose of writing the software or as we referred it, firmware, because the code resided in an EPROM. There were commercial systems available however they were very expensive and getting management to pay for them was rather difficult. We would design the hardware and then write the software. In the beginning it was primarily assembly language with a little BASIC, Fortran and PL/I thrown in for fun.
Years ago, back in the eighties, I attended a software conference. There was a speaker there from HP who explained that software development wasn't a scientific event but a social event. His point was that as engineers we were focused on technical things and forgetting that we had to communicate with others effectively in order to be successful.
This and a few other experiences got me thinking about how we saw the process of software development in other ways. I began to see that writing software was a craft not a science. Yes there's a great deal technology involved, however many crafts have varying degrees of technology. Machinists must have an high degree of understanding of math, in particular solid geometry, potters need to understand both physics and chemistry, musicians learn music theory that is full of math. Once I started to approach software from this point of view I began to see aspects of the work in a different light. I began to put more emphasis on tools, solid algorithms and clean and understandable code. I began writing the code so not only was it clear what was happening but it looked good on the page, after all it is an art form. And I was going to have to look at it again long after I had forgotten what the code was doing. If there is one piece of advice I would give a young engineers it's remember you may have to come back to your code in the future after you have forgotten what you did.Back in the late seventies I ran across a old IBM engineer who had written a Motorola 6800 assembler which I used on the job. I loved the way it worked I spoke with him on many occasions and he spoke of the work he had done at IBM and told me your tools are the key to success.