Flexibility vs architectual complexity

The Spring framework has some great technological solutions for structuring and managing complex applications. One of the probably mostly used parts is the IoC container resolving around the application context.

There are mainly two ways for leveraging this functionality, one old-school one based on xml files conatining bean definitions and one based on Annotations and Java configuration.

Both ways are highly convenient ways to wire up an application. People most of the time are very eager to use them, in some cases even without thinking about this too much.

Problems arise when an highly complex sytem is split in several configuration blocks (xml or java config) and these blocks are than shared with other applications built from the same codebase...because reusability is king.

This is when you change a seamingly innocent part of the code and you break 10 other applications, and than you are blamed for not being careful enough.

Indeed you can, and should be more careful, but if an architecture allows you to mess things up to such a great extent, that that needs probably a second thought.

Is the overlapping area between several applications a good idea? I mean, services fully configured included in several apps the same way...

Is configuration development and reuse a good practice? ...convenience over maintainability.

..or is it just me who cannot swallow this way of building an app?

Happy coding,

N

End of an era

After several (about 13) years you ended up a somewhat appreciated, senior contributor for a company. This status earned you some privileges and a certain degree of stability. Normally there is no sane reason to leave this warm feeling, this comforting community that surrounds you. 

...but there comes a time when despite your good feelings about this place you are in, you are presented with a choice that can support your life better, it can give something more to you and your family. (at least on paper)... and than comes the struggle.

You have to make a difficult decision and this decision will affect your life and your family's life. When this happens chances are that you become full of doubt about the uncertainties of the new direction and the reason for this is that you have become way to accustomed to the situation you are in. All those things that you ended up knowing and appreciating at the old place are raising the bar way too high for the new place. 

Should you keep these bars so high? Or should you lower the bars and start with little expectations from the new place and start raising these bars slowly as you get accommodated in this new place?

You have to close the past, and keep these great things you encountered at the old place as great memories, and start with a blank page. Expect for the good and do your work as best your abilities allow you.

The new place will bring new challenges, new people, different culture...and you have to try to understand this and give it a chance. Maybe it can lift you higher and open some parts of you that you did not know about.

We will see...

Happy coding.

N

Stepping into the same pothole?...twice

Sometime in the past, you've been through an experience that was quite unpleasant. Let's assume that it was a job interview at a company. You did not perform well, at least not as you would have hoped and on top of that you got into a rather humiliating situation. The view of the company got shattered by the behavior of the interviewers and everything ended with a feedback letter you wrote to the HR person of the company.

Fast forward to Today, someone else from the same company contacts you to have a new discussion about more or less the same kind of topic. Would you invest time and effort in having a similar discussion? Can you set aside your previous experience and start with a clean sheet of paper? 

Would you even consider working for a company that has a recruiting process that produces negative feelings in the candidates? 

Can you tell the general atmosphere in a company from the way a company treats job candidates during and before interviews? 

 

Customer is King...or a dictator

When a customer says jump...you say how high...usually.

In some cases customers come up with extreme request...like they want you to do all the development on their environment....the reasoning?...because of security...they don't want their system exposed...while it is ok for you to trust them with all your code...and move all your development to their premise.

Nowadays customers should be treasured...but where is the limit?

Would you refactor your Dev process for the sake of a customers paranoia? will the project pay for all the overhead caused?

....we will see ;)

Roadmap

 In software development, a roadmap (of a product) is that map, with directions and signs...telling you where a product should go.

This is not a planned route...or if it is it certainly is not the final one...it is just the directions ... like "just go north"...

Than developers will take this roadmap and will plan an actual route...with all its POIs ...all those stops (we call milestones) ...and we start the journey. 

At any moment the planned route can change...and than we reroute...place you POIs...remove old ones...but we are moving...towards that destination. Maybe we will not reach the original destination but we will certainly find another...a closer one. There will be always a destination. The destination is the most important aspect...the trip...not so much. This is not life.

For a company, planning a roadmap means investing in the future. It means placing your bets on certain features that could bring benefit for the company...even considering the invested effort.

So the question is always: will it pay off? ... on the short/middle/long term will the company benefit from this? ...because companies are there to produce profit ... that's one of the main goals.

If all the above are true...than who should come up with the destinations? 

Should developers be asked to come up with ideas to improve a product? ...and lay down some possible destinations? (bottom - up)

...or should the company come with destinations, goals, plans and than involve people to discuss them...find solutions to achieve them...to push those barriers? (top-down)

...to me both seem democratic approaches...but one seems more constructive than the other...and deciding which seems to be a subjective mater.

Anyways...it is roadmap time...that time of a year :)

The leader

 Leaders are there to lead...to show the direction...they should be the ones who stay in front of the flock and brake those barriers...the ones who fight among their followers...to give them strength and hope.

Managers are there to manage...to delegate...to give orders and expect reports....they push their people to the frontline...and watch what happens...and delegate the consequences.

Some people are born to be leaders...and the rest can only become managers.

If you think you are a leader...ask yourself a question: If you stand for an idea you believe in against the management of your company, will people follow and got your back? ...or will you stand alone?

If you remain alone...it might be a sign that you are not a leader...just a lone rebel...nobody understands.

Saying no

Imagine you are driving a car you helped building...in fact you did a lot to improve it...and still you are fairly convinced that it could drive many more miles...and your feel that your job is not done yet with this vehicle...just improving it would extend it's life quite significantly. 

And this vehicle caries several people....a department or so.

Than you get an offer...to jump to a new shiny tandem bicycle that one day could become a four wheel vehicle perhaps...and you are asked to be an architect for a now bicycle and take the sword up and fight to transform this bicycle into a car.

...but by some reason you don't feel the urge...your inner voice tells you that you cannot ride two vehicles at once...and there are more things to achieve here...nothing shiny though...but being spacious it could bring several people with you... 

...than you say no ...and a world collapses... people take this personally because you were expected to take this role...they were counting on you...although nobody mentioned this ... and suddenly you are excluded from the bicycle project...and now you are puzzled...what just happened...and you see people around you consider this as a not an appropriate attitude....and probably they are right.

Maybe saying no is not so well accepted...if it was at all? 

When you are an employee can you...should you say no to things like assignments? I mean when there is an option to say no, of course.

I'll leave you with this,

Happy coding. 

Just do ... Git

My latest task at the company is to support (and carry out) the migration of our codebase (significant amount of code in ~100+  software modules/projects) from CVS to Git.

This is expected to go a seamless as possible without affecting the current work of the whole department (30+ devs) so I needed a whole arsenal to tips an tricks to do this, but it seems that things are starting to take shape.

Together with this migration we also decided to move from legacy Hudson to Jenkins, and from legacy file-share based artifact repository to Nexus...just to keep things interesting...

...so the new Year comes with new gear(s) ... Git and his friends... beginning of a new era at the company... and who knows ...maybe at some point we might go wild and switch to Maven or Gradle :)
...but until than the trusty Ant and Ivy will keep things flowing.

Alone with you thoughts (ideas)

There are times when the thoughts you have in your mind cannot be explained. You can't call these feelings...in the meaning of ... I have a feeling that...

This is when if you try to explain you fears you are not understood...people, colleagues look at you with the "who are you" look on their face...and you can't stop asking the question...who is not seeing the big picture...you ore the others?

Testing is important...may I say...very important part of a developers life. You create something, following your inner intuition and skills and than you need a proof that it is really something useful.. and it does make an impact...or it scratches and itch. Testing gives you this feedback.

When you don't have tests or you are too busy to write tests...is like playing the Russian roulette...you might get shot...and being shot hurts...so they say.

This time of the year everyone is thinking about the winter holiday...they rush to push things out...things need to be done...finished...and tests are not important.

This is the time when I feel that I am not proud of the work we do as a team...and as much as I push for "open your eyes people" all I get is "you are right...but...this is not possible at this moment" ... we "will fix this next year".

...so you end up keeping your ideas, thoughts, to yourself...and add this to the pile of sorrow...

Maybe things will be better next year...

Happy holidays, and get some well deserved rest...I sure will.

Avoiding conflict

I hate conflict...mostly the one caused by subjective ideas, decisions...there is no win-win outcome from those...only frustration.

When you are assigned to work on a task and you make decisions on an area which ha no standards to follow there is always good idea to discuss with others....to ask for objective feedback...to make sure your view is not definitely wrong...

It sometimes happens that by asking for feedback all you get is subjective opinions which are not backed by facts ...and if you try to disagree or ignore these kind of opinions ...when these do not move you further....you end up in conflict...causing tension... and called an arrogant...d**k.

Feedback about a work item should be objective...apart from personal opinions...this means being a professional. 

Subjective feedback should be listened to, but it is destined to be ignored most of the time....so don't be surprised if your feedback is rejected.

If all you have is subjective feedback, than make it clear that "if I would have to do this I would do it like this...because..." This can...for those few open minded ... start a thinking process...and eventually maybe lead to a better solution.

Don't force your subjective ideas on others...let them decide if they want to listen or not.

... eventually time will prove you right or wrong...and it is ok to be wrong from time to time.

Upgrading the technology stack

If you develop software chances are that eventually your state of the art technology stack will fall behind...something that once was great stuff becomes old and outdated.

Using always cutting edge technology is simply impossible in a bigger company and bigger projects...as with every technology stack update you introduce regression...and since the customers have no direct benefit from this...eventually the company will cut the effort for staying up to date.

Something that works should not be changed unless there is a good reason for it.

And so we end up using Ant+Ivy and CVS and Java 8 in 2019...where everyone is using Maven and Gradle and Git and Java 11...and you have to argue constantly why...

Upgrading the technology stack of a department is not that simple...we have to move slowly and cautiously...and we will get there...and products will not suffer.

..and everyone will be happy...except those who will not.

Key persons

A key person is someone who's presence is absolutely required to resolve an issue...develop a feature...decide something.

When such a person is missing...is out of office by some reason...things tend to get stuck.

To avoid these situations the software development processes have evolved and they came up with the idea of cross-functional-teams and peer programming. These make sure that a knowledge about some topic is shared at least between two people...preferably with the whole team... nice and easy...no more key persons...done.

Thing is that there is a certain type of knowledge that cannot be shared...and this is experience...the luggage you are building during your professional career...and in some cases this is the key knowledge that makes the difference between you and Joe/Jane.

...but assuming that everything would be a shared knowledge ...and every team member could pick up your work and be able to continue it...how valuable would a person be in a team? ... what would be the difference between you and a factory line worker? ... companies would love that...right?

As much as some companies would like...there are roles in this domain where people are not interchangeable...although knowledge is shared...you will not be the same as Joe/Jane...and these persons will be the most valuable asset in the company.

There will be always a certain type of persons with that key knowledge...and you have to live with that.

Vacation period...when you work in a team

Vacation period is the time of the year when sometimes several colleagues from your team are out of office...This is the time when if you have a task that depends on a work done by a colleague left for vacation...most of the times there is little chance that you can complete your work...and you might end up blocking others...and so on.

This is the least productive period of the year.

Maybe it would be better to just call the period...and abort the mission of delivering something significant.

This would lead to less work to fix later...and less frustrated colleagues.

Just accept that there are times when is better not to commit anything....and no worries...things will be finished eventually...when everyone is present... physically and mentally.