Thursday, 9 February 2017

Assumptions I held about software development, that no longer hold true for me

That architecture is more valuable than test

  1. Often what we do with software doesn't change that much. Good tests describe what we want to solve with software.
  2. Software changes greatly in many directions over time. The architecture we choose today will not "stretch" in every direction of change, requiring significant changes at some point.
  3. We can only sell features. Tests are a great description of features. We cannot sell an architecture.
  4. The right tests, written at the right level in the application will out live the architecture.

We need to re-write insert any software product from scratch

  1. It nearly always takes significant time to re-solve all the simple problems the old system does for your users.
  2. The expectation of the user is immense.
  3. Software is not construction, the foundations of our system are not in concrete. It's our own perceptions of the complexity of the current solution coupled with our desire to embrace new tools, that limits the changing the current solution. We think it's easier to start from scratch.
  4. One of the Facade, Adaptor or Proxy design patterns should be employed to bring fundamental change to a software system.

That you can be faster if you do Agile in software development, but keep all your traditional stakeholder, requirement, release and business management processes.

  1. Agility means you are agile from the customers’ point of view, i.e. they are getting something delivered from you every 1-4 weeks.
  2. It's hard to release every X weeks, if you can't put work through your production pipeline in less than X weeks.
  3. The overhead of breaking work down to fit into short sprints, actually makes the overall work take longer to do in the medium to long run.
  4. Agile allows you to maximise the amount of work not done. Can you choose what features not to do?

That I must enter "the zone" to be productive or that I work better on my own.

  1. We do require focus in a very busy world. But the zone has no feedback, so we often end up doing the wrong thing.
  2. It’s important to come out of the zone frequently so we don’t lose sight of our destination.
  3. We do need some quiet time to absorb information and reflect, but this isn’t productive time.

If I am efficient and productive, I am effective.

  1. Productive means you are active at building something.
  2. Efficient means that you are really great at building something.
  3. Effectiveness is measured by the receiver of the output of our work.
  4. We often build the wrong thing or we build a lot more than the user needs.
  5. It is better to build something small that is used and useful, than to build something large that is never used.

In software development, the "busy" team is the "best" team.

  1. It's nearly impossible to visualise the output of software teams.
  2. It's even harder to get objective measurement on that output.

Bad developers cause the most bugs.

  1. Bad developers usually deliver very little and the issues they create rarely get passed our first test loops, eg Code review and basic integration test.
  2. Developers who produce the most code, produce the most bugs.
  3. The code that is not written, contains no bugs.

Unit tests test methods

  1. Most unit testing is written towards all the methods in every class in our component. It is very tightly coupled to our design.
  2. If I have to change the test when I change the source, I can't be sure the method/class/component worked like it did before.
  3. The "acid test" for a good unit test is that you can change the implementation without changing the test.
  4. Refactoring means that I re-structure & re-write code, but it does exactly the same job it before.
  5. Good unit test is written towards the public API.

There are lots of good unit test and TDD articles/books and resources.

  1. Most say that for every method you write, you must have at least one unit test. This is wrong.
  2. Most say you must design for test. This is wrong. Good tests simulate real use.
  3. Most state that the "unit" is the method under test. The unit is the test itself.

Thanks to Contributors: Shane McCarron, Rachel O'Toole

No comments:

Post a Comment