2024 Public Training Schedule
December 9 – 12, 2024 – Agile Analysis and Design Patterns
Half-Day Sessions
Follow me on Twitter:
Blog Post Categories
- Announcements {19}
- Articles {2}
- Bits and Pieces {74}
- Blogosphere {1}
- Bonuses {2}
- Build in Small Batches {27}
- Collaborate {38}
- Create CLEAN Code {34}
- Implement the Design Last {11}
- Integrate Continuously {30}
- Off-Topic but Interesting {3}
- Rants {82}
- Refactor Legacy Code {24}
- Say What, Why, and for Whom Before How {22}
- Seven Strategies {38}
- Specify Behaviors with Tests {17}
- Write the Test First {27}
Archives
Privacy Policy
(c) 2024 To Be Agile
- March 24, 2010 ( 2 comments )
- Rants
I’ve been a software developer for over a quarter of a century and I’ve seen software development change quite a lot in that time. When I started out writing code the main concern that I had was to make my software work.
It was challenging to make software do what we wanted back then because not only did we have to figure out what we wanted to actually do but we also had to do it in such a way that it would run fast. Machines back then were very slow and memory was extremely expensive so we were constantly finding clever ways to make our software run faster and in less space. Very often this was at the expense of making the code easy to read and understand.
Today the forces of the industry are very different and we recognize that speed at all costs is wrongheaded in most cases. Computers are very fast and memory is very cheap and as a result these things are no longer a high priority for us. There is a new priority for our new limiting factor in the equation of software development and when I ask people what it is most of them cannot tell me.
The new limiting factor in software development is software developers. We’re only human and there are a finite number of us as the demand for software continues to increase. As result we have become scarce resources so the quality of the code we write and how maintainable it is becomes much more important today than it ever was.
{2 Comments }
Previous Post: « Dolphins and Developers
Next Post: We Can’t Keep Starting Over »
David, I happen to agree – but I’m a reformed programmer who has splecifically focussed in quality since 1990. How many professional programmers, do you suppose, agree that they can write more software by focussing on quality?
Hi Ian,
That is a great question and I think the answer depends on how quality is approached. We all want to do a great job and we do the best we can. Often, quality becomes a lower priority because of deadlines or other constraints. We often operate under the mistaken belief that quality takes longer but it really doesn’t have to.
I certainly used to believe that “quick and dirty” was quicker. But then I met some developers who wrote quality code and wrote it much, much faster than me. I started to model what they did and realized that speed often has to do with what is habit for us (see my post The Habit of Quality I wrote a few weeks ago).
Paying attention to code quality, following design principles and practices do not really take extra time. Yes, cohesive software typically has more classes and that implies more typing than if I were to write a program in a single class. But does the extra typing really take more time? Not when it makes debugging easier. I think people are largely unfamiliar with the quality practices I advocate so they confuse lack of familiarity with difficulty.
Sometimes people look at some of the practices I suggest and think, “Oh, that’s something else I have to worry about,” so it feels like a burden. But when we do these practices it becomes very freeing; a lot of our fear around changing our code goes away and we gain a lot of velocity through our confidence.
I’ve trained thousands of developers in quality software practices and virtually everyone agrees that these things take little extra time and saves them a lot of time as they go. Come to one of my classes and I’ll make a believer out of you too.
Thanks,
David.