Monday, 2 July 2012

Development Principles - Think first programming

A professor once told me:
Remember, a string goes into the server, a string goes out. Not more, not less.

So let's ask the following questions:
  • do you need a seven tier architecture?
  • do you need to write a servlet container in PHP?
  • do you need to derive a class more than twice?
  • where do you need OOP?
  • do you need design patterns?
  • how to choose the right technology?

And here are the development principles:
  • keep it simple and stupid! (kiss principle)
  • don't write your architecture on more than one slide
  • write less code, you must maintain it!
  • test your code, you're responsible for it!
  • don't import much code from libraries, you might need to fix or upgrade it
  • don't trust user input, don't trust foreign code, trust your own code
  • don't use design patterns you don't understand
  • no backup, no future
  • don't use technologies you haven't evaluated for the current task
  • if you're not sure how to decide, make more tests
  • don't follow general recommendations for technologies or frameworks or marketing events
  • be careful with magazines recommending technologies or methodologies, their use case might be different
  • never stop looking for new technology, new methodologies, new strategies
  • go from the problem to the solution, not backwards!
    • don't use Zend Framework or Doctrine to solve all your problems!
    • don't use PHP to solve all your problems!
  • let every programmer choose his favorite programming language, use the right language for the right task
  • it's not a problem to make a mistake, it's a problem to make the same mistake twice or ignore warnings from others who already made the mistake
  • don't follow the rules above if you're successful with other rules!

And finally: It's not all about good programming, it's all about making good decisions!

Typical issues:
  • everybody is using scrum, we need scrum (solution → problem)
  • we want the highest quality, we use scrum (scrum focuses on deadlines and features, product owner only cares for functionality and business value, not quality, bad workarounds save deadlines)
  • symfony was great in the last project, we must use it in the next project (solution → problem, different task → different tools)
  • I can't write good specification or documentation, so I skip it
    (it's like coding, you need to practice, practice, practice ...)
  • a good programmer can write good code in any language
    (learning a language in depth takes several years)
  • we hire a cheap junior and let everything fix later by a senior
    (can end in rewriting all the code)
  • good programmers have certificates
    (certificates are normally multiple choice tests, have nothing to do with real programming)
  • we choose a standard framework and extend/optimize the components later
    (can end in rewriting the framework and the own code on the long term)
  • it's an advantage in competition to use framework x (no, competitors can also use framework x)
  • we work agile, so we use the biggest framework (agile architectures are normally very small)
  • we need to get something online as fast as possible
    (might not be customer oriented, bad usability, wrong features, low quality, waste of resources)
  • we evaluated database systems for 3 months and selected the framework in 10 minutes
  • to get money for making the estimation, we've committed the final deadline to the investor

Quotes:
  • our small team is able to work faster, smarter, and more efficiently by minimizing the size of our PHP codebase and removing all unnecessary layers of abstraction (source)
  • The best developers don’t just rely upon what they know; they actively are trying to push the boundaries of what they know. The best developers that I’ve ever met aren’t all the smartest people that I’ve met, but they all have had a strong drive to be better (source)

What does it mean to be agile?
Wooga, number 3 in social gaming worldwide, slide annotated with technology, dates and numbers

Keep it simple:
ircmaxell on dependency injection

No comments:

Post a Comment