Did you notice that programming use to be easier?
10 or 20 years ago you were spending more time writing code than now?
It is true for me.
10 years ago I was coding at work in Java and JavaScript. We were using MyEclipse and SVN without branches.
My day was something like this:
- update sources from SVN on trunk,
- look for info about stories,
- code:
- write code,
- run code,
- update sources from SVN on trunk,
- commit code if it was ready in given part,
- update sources from SVN on trunk,
- commit code (still if it was ready)
This was easy.
We had in each moment almost the most current source version on our machines.
We didn't have any CI tooling, but each time you updated and tried to build, and something was failing you were sharing with this and was trying to fix problem.
Without special monitors showing CI results.
Each week we had manual weekly build (written in ANT!), and QAs were testing this version.
It was working.
It was fast.
It was stable.
How it looks usually now?
You are coding with Java and JavaScript + ReactJS + Webpack + Gradle/Maven + Nexus + whatever else + GIT/HG with tons of branches.
Your day looks something like this:
- update from master (or current release master),
- resolve conflicts,
- commit,
- test on your branch (but it may take too much time),
- push to your branch,
- wait for tests,
- in case of failing investigate,
- look for info about stories,
- code,
- write code,
- wait till it compile,
- run code and some tests,
- commit code
- push code,
- wait for tests,
- look why some UI tests are failing,
- run those tests again,
- and again,
- create pull request,
- notice that in the meantime somebody else commited to master code he or she was cooking by last 5 days on own branch,
- merge,
- commit,
- squash commits (because somebody will complain that you have multiple commits),
- push,
- LINT or PMD or Sonar complaining,
- yeah, not in your code, but you needed to change some legacy code in class with 6 kLOCs....,
- hack Lint/PMD/Sonar,
- commit,
- wait for tests,
- CI is slow,
- create ticket for restarting CI,
- you need to stop because you have one of Scrum meetings,
- CI works again!!!!,
- tests are failing,
- again UX tests
I may little exaggerate, but from my perspective it too often looks like this (in many companies).
It seems that developers want to make things more complicated.
Or maybe it works in this way that some people have good ideas and intentions, but those latter are half baked, or introduced only because...
In several companies I saw problem with Maven.
Maven was in HQ and in other sites it was too slow.
So it was always decision, big managerial action "we are doing our own Maven repo which will sync-up with master in HQ!".
This was done.
After some short time people started to realize that they don't see most recent SNAPSHOTs, but after tinkering with /etc/hosts and making repo name resolving to IP of this Maven repo in HQ everything was starting to work.
From this time, in 1st or 2nd day each of newly employed was instructed to do changes in /etc/hosts....
Why? Because everyone is able to read on StackOverflow or something similar about setuping copies of Maven, but configuration is not so trivial....
(I'm still amazed that in one of companies they were extensively using ActiveMQ, and tried even to configure backups... but after trying they realized that it was much more complicated to configure and maintain so they simply killed backup ActiveMQ server without even changing apps configuration....)
Similar postsbeta
Which language is fastest? ;-)
Google Buzz - let's mark some comments as not spam ;-) or how to unhide "hidden" comments ;-)
How to get negative number from size() in LinkedList in Java? ;-)
What sux in G1?
Calculation of SSD life time in EEE PC
No comments:
Post a Comment