Still No Silver Bullets

Not so very long ago, I made my living writing code. My colleagues and I did our best to understand what our customers needed, and to write code that was easy for other programmers to understand, solid, defect free.  When our managers asked us how long it would take to create a new feature or modify and existing program, we studied the problem, considered how much code we’d need to write or change, how we’d integrate the new functions with existing functions, and what sort of testing would allow us to feel confident our work was complete and correct.

Our managers were often not satisfied with our estimates.  They wished we could deliver working software more quickly.  They suggested we were exaggerating how complicated the work was.  They hinted we were padding our estimates, and spoke sternly of work expanding to fill the available time.  Then they revised the estimates to fit their desires and handed down a due date.

Strangely enough, the work usually took longer than the managers wished it would.  Our managers contemplated the gap between wished-for and actual delivery and pronounced us not sufficiently productive.

And so the quest to improve our productivity began.  First it was CASE tools.  They were supposed to improve productivity by an order of magnitude (they did not).  Then came Rapid Application Development (apparently the managers stopped reading after “Rapid”).  The next improvement, Object Oriented programming, was supposed to save the day (it did change the way we think about programming).  When I left that company, the productivity pill was a development methodology that took up an entire 4-foot bookshelf.

And the quest to improve productivity in software organizations marches on.  More and more often, the quest includes some flavor of Agile Methods, and a promise of hyper-productivity, quick delivery, and change for free.

Agile methods can help achieve business results, get software out the door faster, adjust to new priorities, and dramatically reduce the number of errors that reach the customer.

Agile encourages close collaboration with a product owner or customer (whether that’s an internal customer proxy, product owner or an end-user of the software). This helps teams understand the customer and his context, so they can make better decisions about feature design. Short iterations and frequent demonstrations of working features keeps development close to customer needs and wants.

Agile methods encourage planning based on demonstrated capacity, using agile methods can help prevent cost overruns and help managers make decisions to continue funding feature development–or not. Iteration planning and tracking story points helps teams and management understand capacity. Without this information, plans are merely wishes.  Armed with such information, managers have the opportunity to review progress and viability at the end of every iteration.

Working in short iterations to produce working software can allow a company to realize revenue early; when teams finish small chunks of features each iteration, it’s no longer necessary to wait until all the features are completed to test and deploy. Every feature slice is tested and ready for customer acceptance at the end of the iteration. When the slices add up to a marketable set, managers can choose to release.

Agile engineering practices such as automated unit and customer tests, pair programming, and frequent integration find errors early which reduces the number of defects released to the customer. That results in lower support costs, find and fix costs and bad press generated by buggy products. Practices such as simple design, Test Driven Development and refactoring keep the design flexible and clean, avoiding design degradation and escalating costs for future changes.

Many teams who use agile methods are building strong cross-functional teams and report that their satisfaction with work-life and work/life balance is higher. Working at a sustainable pace and re-establishing pride in work bring intrinsic motivation. That makes it easier to attract and retain employees.

But when agile methods—extreme programming, scrum, kanban or some combination there of—are imposed as a way to “fix” perceived programmer productivity problems, the effort almost always fails.  Sheep-dip training programs, “going agile” by decree and cherry-picking the agile practices that don’t seem difficult won’t achieve great results.

No method, or set of methods can improve results unless managers also change the way they do their work.

Managers need to get organizational systems working.  Managers must do the hard work of understanding the market, their customers, and make difficult choices about what work to do and what work not to do.  Managers need to study how teams and organizations really function and then create systems and environments that don’t hinder people from doing work.

Writing software is hard.  Agile methods can help.  But they are not a silver bullet.  And no method can improve productivity unless management also changes.

14 Replies to “Still No Silver Bullets”

  1. Peter F. Drucker wrote in 1986 about changing management: “[…] realize that it is both the subordinate’s duty and in the subordinate’s self-interest to make the boss as effective and as achieving as possible. The best prescription for one’s own success is, after all, still to work for a boss who is going places. Thus the 1st Do is go to the boss […] and ask: ‘What do I do and what do my people do that helps YOU do your job? And what do we do that hampers YOU and makes life more difficult for YOU?’
    You [being master of your own destiny] are responsible for the performance of all the people on whom your own performance depends. The first person on whom your performance depends is your boss, and the boss is thus the first person for whose performance you have to take responsibility. But only by asking, ‘what do I do to help or to hamper you?’ – the best way to ask is without beating the bush – can you find out what the boss needs and what gets in the boss’s way?”

  2. One day, perhaps, it will become obvious there are no werewolves, so there are no silver bullets. Until that day, management will continue to go after the latest “productivity helper”. Love the post.

  3. This is so true. While I like Agile (heck, I built a web app around it), it won’t fix some kind of programmer productivity “problem.” Great post.

  4. Hear! Hear!

    Many managers look for productivity fixes in the wrong places. A lot of productivity is lost due to operational problems, outside of the real development process. As a manager, it’s my job to make sure the things that are supposed to “automagically” work actually work that way. Only when that happens will any optimization of the development process even be effective.

  5. Esther,

    My experineces mirror yours for the first three paragraphs. It seems like you missed Structured Programming, an early aid to productivity (it didn’t) and a later digression into Service Oriented Programming, which raised OO to the point where teams could work on selected portions of the code, making Agile (in it’s various flavors) practical. All of these provided a slight improvement in the overall sanity of programming, but all fell short of being revolutionary. All seemed to have the goal of requiring dumber programmers to get the job done, with the possible exception of Agile, which seems to require a very good team, all of them. In the end, Mr. Brooks is still right. Now instead of throwing the first one (or two) away, we just refactor it to death.

    Nice article, thanks!

  6. Oh if only all technology departments would embrace this, my sleepless nights and fruitless days– agonizing over why the darn thing looks like a tree when I wanted a treehouse– would end. 🙂

    Signed, a frustrated client-side PM

  7. Nice post Esther. Over the last 26 years I’ve been in the IT industry the two things that frequently seem to be missing in product development management of software and Systems companies is systems or holistic thinking and a seeming lack of a basic understanding of the difference between an estimate (probability based, range) and a commitment.

    The silver bullets of the past didn’t look at optimizing for the whole just one aspect of the system. Remember during the 80s with CASE tools, the magical code generation features? :-0 What a disaster that was!

    Software is most often a complex endeavor and an empirical problem by nature. Systems thinking is necessary for success, especially amongs managers. And at the rate of advance of technology and the practical applicaton of it, it is doubtful there will ever be a Silver Bullet in this problem domain.

  8. […] I’ve used the ‘experience pain to force change’ approach to get new ideas in place but this clearly isn’t as powerful as getting a whole organisation buzzing about what it does and how it can do it better. It’s hugely important that leaders at every level of an organisation create that buzz. Just adopting Scrum or XP doesn’t achieve this and similarly a community focused on those methods won’t change organisations. Still no silver bullets then… […]

  9. […] Software development is changing and has to change in respect of business calling for a different type of requirement; one that has to be done faster, and requires frequent changes in new front office situations in response to the market, so more and more people turn to considering Agile. Esther Derby has interesting posts on this topic both in terms of the use of the term as applied to a business but also a great post that sums up Agile development under the title of ‘Still No Silver Bullets’. […]

Comments are closed.