Hacker News new | past | comments | ask | show | jobs | submit login

The unappreciated key to rapid software development is having a realistic plan:


"Point the boat in the right direction and row" is the dominant paradigm in the industry.

The concept of "technical debt" is I think harmful because it is a two word phrase that stops thought. In the real world if you want to take on commercial debt, the bank and/or bondholders and originators are going to want to see a detailed financial analysis that will indicate they will get their money back.

Probably 80% of effort on software is maintenance, but it is rare for any project to start out thinking about the cost of maintenance.

As a maintenance programmer, you're 100% correct. Our systems are not designed to be maintained and so our ability to work is severely hampered.

Within the area of maintenance programming, if you inherit a program with a poor testing infrastructure (or even worse, have to produce it yourself) you will make the system worse over time or move at a snail's pace.

Automated testing and unit tests need to be present to make effective changes during maintenance to systems. Otherwise too many of our changes are shots in the dark. They add the feature we wanted (we can test that much), but may have broken a dozen other things that we won't see until much later in the schedule.

A lack of automated testing and good unit tests also motivates managers to adopt more waterfall-styled schedules. Pushing integration of the various change requests to the last possible moment, with a comprehensive test suite run after that. This creates huge schedule risk, but from their perspective is necessary. Why? Because they don't want to spend the time/money running that huge, comprehensive, largely manual test suite more than once in a year. They don't accept that a partial test suite (a representative sample, if you will) could be executed with greater frequency and give similar results, with the full suite run once for certification testing at the end.

You're definitely right that unit tests are a part of the solution.


can be read in a few different registers (making a case for what unit tests should be in a greenfield system, why and how to backfit unit tests into a legacy system) but it makes that case pretty strongly. It can seem overwhelming to get unit tests into a legacy system but the reward is large.

I remember working on a system that was absolutely awful but was salvageable because it had unit tests!

Also generally getting control of the build procedure is key to the scheduling issue -- I have seen many new project where a team of people work on something and think all of the parts are good to go, but you find there is another six months of integration work, installer engineering, and other things you need to do ship a product. Automation, documentation, simplification are all bits of the puzzle, but if you want agility, you need to know how to go from source code to a product, and not every team does.

That book is something I wish I'd read when I started my career. This is a holiday week so all the management types were out, but I had planned to have management buy a copy for the office library next week. I still need to finish it, but most of what I have read, I've been able to apply to projects in the past. I should probably actually reread it because it's been a while.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact