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:

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

kelatebaru