In this talk, I rant about 3 issues in software engineering, which I repeatedly stumbled over in my career so far: - Choosing the tools because we like them, not because they are the best for our problems. - Rewriting software from scratch, not evolving it instead. - Piling up awesome masses of dependencies. ... and one general recommendation I draw from my experience: Build your applications as a set of APIs.

1. Hi

2. My name is
Benjamin Erhart

3. I'm here tonight, because I love programming
Perl.

4. But... I actually don't want to talk about Perl, which
is, by the way, a great multi-purpose, multi-
paradigmatic, community driven, often
underestimated, mature programming language
usable for all sorts of things and especially great
for data centric web applications.

5. Instead I want to talk about things one level
higher.

6. Theses for Better Mobile and Web
Applications
Benjamin Erhart
berhart@netzarchitekten.com

7. or:
Various Rants about Programming
Topics

8. BTW:
If you want to learn about Perl, there's an
Austrian Perl Workshop coming up occurring
between November 2nd
to 3rd
at NCMs offices.
or
just ask me about a training!

9. whoami
Im self employed and partnered with friends at
die.netzarchitekten.com
I'm a passionate software engineer in the fields of web and
mobile with 10+ years experience and had worked my way up
to Head of Development of leading SMEs.
I'm available for hire to build your next application, consult
you and your team in the arts of proper version control and
build management, how to program Perl and JavaScript or
help with any security issues you might have application-wise!

10. 1

11. Choose your tools depending on
your problems, do not try to solve
your problems with your favorite
tools.

12. Why?
Seems obvious when standing in front of a
toolbox.
In IT, tools are often chosen because of the wrong
reasons.

13. We already know them.
Sure, but: The average life of some technology
on the internet is shorter than 10 years. So you
better move on, if you don't want to fall behind!

14. We can't find people with knowledge
in better ones.
So what? Good programmers will program good
in any language. Just give them two weeks to
have a look around, maybe kickstart them with a
little training.
Your programmers are not so good, yet?
Well, looking beyond one's own nose is the first
step to become better. Let them explore new
stuff!

15. It's too expensive to do it with these
fancy new technologies.
The best fitting new technologies will save you
development time, bug fixing time, customer
care time and response time . Otherwise, they
wouldn't be best fitting. I guess, that will make up
for the extra costs...

16. The others use it, too!
Great! Then there's a perfect opportunity to get
an advantage. The same tools surely won't buy
you that.

17. 2

18. Do not rewrite software from
scratch, but evolve it constantly!

19. This lesson is actually 13 years old*,
but worth repeating any time!
Everybody loves to start fresh, because:
It's harder to read code, than to write it.
*) www.joelonsoftware.com

20. Evolve it constantly
Environment changes constantly, even if you
don't recognize it for a while:
Server hardware breaks, old OS versions don't
run on new ones.
Libraries in use change APIs in new versions.
Documentation for old one vanishes.
If you stop development for ½ year, chances are,
your application will fall behind so much, you
can't catch up anymore.

21. Enhance the old code
– Put it in source control immediately if you haven't, yet!
– Start versioning, if you haven't, yet!
– Add a proper toolchain for continuous integration/deployment.
– Add documentation.
– Add unit tests.
– Add automated interface tests, if the products value allows it.
– Refactor, refactor, refactor.
– One step at a time, to allow for a continuously working product.
– Do not stick to old environments – don't be afraid of building new parts
with new technologies.

22. 3

23. Avoid dependency hell for all it's
worth!

24. Wealth through self-restraint
– Avoid using other libraries in your own, which only
“make the language nicer”.
– Do not use libraries, which replicate behaviour of
another library you already depend on, just because
you think it's “cooler”.
– If you can't get it into your (and your colleagues) build
chain easily, don't use it!

25. Why?
– Keep resource usage low.
– Keep needed knowledge for new colleagues low.
– Keep build times low.
– Keep demands on IDEs and toolchain low. Not everybody loves your
fancy editor.
– Avoid unnecessary restraints and need to work around stuff which
turn out to be not as a good an idea as thought in the first place.
– Your going to pile up enough dependencies over time anyway!

26. 4

27. API-ize your applications best as
you can! – restful

28. Testing
Complex MVC chains responding with HTML are
hard to test.
Web APIs returning data structures are way
easier.

29. Server off-load
Move business logic to the client, render client-
side.

30. Responsiveness
Viewer requests with shorter response times
obviously feel less sluggish to the user.

31. Interoperability
Reuse your APIs to integrate into other websites
or mobile applications.

32. Thanks for your patience!
Benjamin Erhart
die.netzarchitekten.com