Java Deep

Pure Java, what else

Can you call non-static method from a static?

There are questions on a Java technical interview that even the most entry level junior is expected to give the right answer for. Since I am facing candidates who are not that junior I do not even bother most of the times to ask those questions. I assume that the candidate knows the correct answer. Some time however there are some candidates who I feel from the start they are juniors and to cut the interview short not wasting his/her and my time I ask some of those simple questions. The answers usually reveals the real level of knowledge and we can get to an agreement in short time about the assessed level.

Sometimes I also meet candidates who not only simply do not know the answer but give wrong answer. To know something wrong is worse than not knowing. Out of these very few even insists and tries to explain how I should have interpreted their answer. That is already a personality problem and definitely a no-go in an interview.

One such simple question is:

Can a static method in a class call a non-static method of the same class?

If you know Java a little bit you know the answer: no, it can not. A static method belongs to the class and not the instance. It can even be executed using the name of the class directly without any instance of the class. It can even run when there is not even a single instance of the class in the whole JVM. How could it invoke a normal method that runs attached to an instance?

But then again: the answer from one candidate this time was: yes. And he even started to explain that it may happen that the static method has access to an instance. It may get an instance as a method argument and through that reference it can call an instance method. That person was right. It did not, however, mended the fact that he did not know Java good enough, but as a matter of fact in this very specific question she was right.

What is the morale of the story? You tell.

Do we need coding conventions?

There are things that just come natural and we forget to wonder if it could be some other way. It is like that the sun rise morning and sets evening. But scientists raise the question and even though the sun still rise in the morning and still sets evening we gathered a lot of knowledge about it. It is similar to every profession. We do thing, follow procedures and do not ask the question: why? Should we?

In some cases we follow some procedure because that is the way we always did. We write program codes in lines, because that was the only way to record code in RPG that was created for Hollerith cards. You do not even know what a Hollerith card is but you still write code lines in an editor and still many times the suggested maximal line length is 72 characters. Should we write code into 72 character length lines? No, obviously. Many times we do not. Modern editors and screens make it more feasible to have longer lines. Still there is a maximum length that makes the code more readable. Integrated development environments, like Eclipse wrap too long lines if we ask them. Nobody questions it. What people question is the actual length of the line. Should be 80 character, 130 or 125 or something else? One thing is certain: when coding in a team there should be only one decided and agreed limit. The sad thing is that setting a coding standard sometimes is a good ground and source for dissension.

From my practice the most important Java coding question (as far as temperature of debates shows) before starting a project is:

“Should there be a space between the keyword ‘if’ and the opening parenthesis?”

You may laugh, but just look at the following two sample code segments:

  if( debugIsSwitchedOn )log.debug("Here we go");


  if ( debugIsSwitchedOn )log.debug("Here we go");

Now you can understand that answering this question and having a consensus on that may make a project success or fail. The proper selection between waterfall and agile methodology is a matter of free choice and does not really effect the outcome of the project as much as this question. At least if I measure importance based on the effort put into the debate usually.

Now you think that I am kidding. Some way yes, but lets have a look at from another angle:

If having or not having a space between the keyword ‘if’ and the opening parenthesis is not important then why do people invest so much emotion and effort discussing it?

It seems that such nuances are important for the developers. And what is important for the developers is important for the project. Unhappy developers do not deliver successful project.

This is not a hard coded area, like performance of reflection or thread local usage in Tomcat that you can try, test, measure and have a final word. This is more psychology that I am not an expert in, but still I have my experience in coding and I have my ideas about the question I set forth. After all having a discussion about a topic we are not expert in is at least such a good ground for a dispute as something that is more religious than fact based, like the space between the ‘if’ and ‘(‘.

Code is owned by the developer

Today agile methodology says that the code belongs to the group. Anyone can fix any part of the code. In old times it was not the case. We did not stick to such “expensive” and strict rules. Developers were lone wolfs and were responsible for their own code. Sharing the code has its cost involving the other members to learn the code somebody else from the group developed. In the long run it is cheaper when you consider the maintenance cost of the code starting even before the first release during debugging sessions. Even though sharing the code is not the human nature. Developers in the deep soul are still lone wolfs and honestly when I code I am alone. I am in a kind of flow state many times realizing that last ten minutes I spent with coding was actually more than an hour. Having enough experience I am not reluctant to share the code with others, explain if needed what and why is there. (Btw: need for extensive explanation is already a code smell unless the other side is junior, in which case the explanation is more kind of education.)

This means that in the deep heart we still own the code. Each and every member of the developer team should feel owning the code to be effective when she has to fix a bug, extend a feature. And the feeling is greatly affected by small nuances, like how we usually format the code. I open the source code in my IDE, I see the code using the coloring and the font face I set (that already makes it a bit cosy) and try to understand the code. If the coding convention is totally different from my code: it is a distraction. Up to some level I can convince myself not to pay attention to the fact the the opening braces are on the next line, like we do when we program C# but it is an annoyment when we code in Java. That is not the way we usually do it. Eclipse, IntelliJ or even some vi macro helps to reformat, but then we waste time when comparing the pull request in GitHub: there will be a lot of changes most of it formatting. We loose the information in the noise.

If the group has coding convention the code will look more like mine even if developed by some fellow programmer. I will look at it, I will understand it easier. You should not underestimate the effect of that.

The actual coding convention is not important

It is more important that the group has one (and only one). To have it settled during the start of the project is a good topic to increase group cohesion. Even if the discussion goes into a wrong direction and the final decision is not optimal, what can you loose? A space between the keyword ‘if’ and ‘(‘? People, especially when a group is recently formed has to forge itself and forging is usually at high temperature. It has to be like that and what can be a better topic where flames make no real harm?

The dumbest interview question ever

This article is not really about informatics at first. But on second though…

Why are sewer covers round?

This is the interview question that I believe is the most pointless ever. This is asked many times and the interviewer usually expects the clever answer: “Because this is the shape that prevents the cover to be dropped into the hole under it.” When I got this question once I had different answer: “Because there are no corners and thus there are no singularities where very huge forces can appear, which are responsible for cracks usually.” Actually I learned that at the university when I had to study a subject about mechanics and machinery. I graduated as electric engineer and I only later became software specialist. After many years of software engineering I have now a different opinion about this question.

What I really think sewer covers are round for?

Because it was always the way like that. Somebody, sometime a hundred or two-hundred years ago created the first sewer top and there was some reason to design it round. They documented it (or not) and started the production. For a short period of time the engineers knew the reasons, but after, say 20 years, the reasons were forgotten and sewer covers were created round for some forgot reasons. Simply because that was the way to do it.

So what? Somebody designed it and it was good,we can follow. Is there any problem with the approach? YES.

The decision was made in a certain environment that radically changed. Labour was cheaper that time, automation was non-existent and metallurgy was far from what it is now. I do not imply that the round form is bad. I do not imply that we have to use octagonal or star shaped sewer tops. I only express my strong belief that nobody was checking the validity of the assumptions recently.

What does it do with software?

Nothing really more than design and logic that we also use in software engineering. As well as routine, practice, pattern, drill. Many times without considering the original boundary conditions.

So next time when somebody asks you this question on an interview just tell them: “Because this is the shape that prevents the cover to be dropped into the hole under it.”

Use of optional is optional

After the article of last week “Optional in collections” today I can’t help but talking a bit more about the same beast. A bit more detail.

The class Optionial originally introduced by Google Guava and later included in the Java 8 package is simply a wrapper that wraps an optional object. The wrapped object is optional in the sense that it is either there or there is no object in the wrapping, in which case it is empty. There is not too much magic there. The wrapping code, the class Optional insist that the object wrapped is not null. After all null is null and not an object. An object is never null. Only a reference to an object can be null.

These are nuances, fine details; but important fine details. After all, these fine details are those that required the introduction of Optional. Average java coder does not see the importance of such tiny details. They think that Optional is just as good as a variable to the wrapped object itself assuming that the variable can also be null. At some level they are right. At their own level.

That level says that the good code works, can be understood and that is it. Most of enterprise legacy code that run banks, insurance companies, pace makers and weapons were made on this level. You can not do about it, just hope that you have the luck and a software bug will not select your house, bank account or body (in case of medical device) in a “bomb” explode there. What you can do is to understand the issue and do your part to slowly improve the situation. It will take a few generations unless we all are wiped out before that.

“Code working” and “possible to understand” are the very basic requirement for software. Some old times we said that if the software runs then it was ok and for the maintenance it was enough if there were two “person” who could understand the code: the coder who created it and God, who created the coder. Fortunately there are also levels higher. (I mean above the coder. Not above God.)

“Code working” and “easy (not so hard) to understand” are the next level. This is important in case you have to debug the code and need to identify the root cause of some malfunction. “Code working” and “easy to modify” are again new steps up the ladder. I had seen code that I could easily understand. The code was running. But the dependencies between the different modules were so complex like a macrame or a traditional Italian spagetti. Wherever I wanted to change something to fix a bug here, there were a few other places where the program started to fail. Easy to modify: that code was not.

The next level is “code working”, “easy to modify” and “hard to create bad modifications”. This means that the code provides style and internal data structures and APIs that the maintaining person will follow to some level and will create a working modified code that still works, easy to understand and to modify. This is the point where we get to the point of Optional.

When a method returns Optional is says that it may return something or just nothing. Optional<Integer> may return an Integer but it may just return an empty Optional, which means: there was no Integer that I could return. Why is it any better than returning an Integer that may optionally be null?

Optional method return value

The answer is that in case of returned Optional<Integer> you can not

integer = methodReturningIntegerOrNull();
otherInteger = integer +1;

that causes NPE. Why you do that? Because you forget to check, and the JavaDoc mentions the possibility somewhere at the end of the description that is not visible in the mouse over window when you code. In case of Optional<Integer> you are forced to

optionalInteger = methodReturningOptionalInteger();
if( optionalInteger.isPresent() ){
  otherInteger = optionalInteger.get() +1;

Still there is a small chance that you will write:

optionalInteger = methodReturningOptionalInteger();
otherInteger = optionalInteger.get() +1;

but in that case you deserve what you get.

Optional helps you to create more code and less documentation. It gives a semantic to pass on some optional value in a way that is harder to neglect than a nullable value. It says: I do not trust you handling null properly, therefore I give you a wrapped object so you have to handle optionality explicitly.

If you consider that you can easily answer the questions

  • requiring Optional<Something> as a method argument
  • having a private field optional.

are good ideas.

Optional method argument

There are pros and cons. When the argument says

countFrom(Optional<Date> from, Date to);

it is clear that the from value may be missing and there should be some special default semantics when an absent value is passed. On the other hand the caller may pass null to get the special behavior. It is less likely that the caller will pass null just by mistake neglecting the optionality. Even if the argument is Optional the argument actually passed can still be null and I expect that the method throws NPE in this case. Last, but not least there is another danger introducing Optional: the caller may pass an Optional embracing an object that is not a Date. Generics can be circumvented in Java easy and a sloppy coder may pass a wrong Optional. It means that you have to implement assertions in your method:

  • argument is not null,
  • argument is of the proper type.

Also recall that Optional, in case of a method return value says: I do not trust you handling null properly, therefore I give you a wrapped object so you have to handle optionality explicitly. What would this message be when you create the API requiring Optional as an argument? Please do not trust me! Give me only Optional because even I do not trust myself to handle a null value properly. Weird… On the other hand I trust that you will not pass null or wrong type.

In my opinion: in this case using Optional does not deliver more value than having proper documentation for the API and does not force the caller to behave better than it would anyway. On the other side you put extra code on your own shoulder.

Give Optional to code you trust, accept it from code that does not trust your code but do not request it! Trust yourself!

Private Optional Fields

When you declare a local, private field to be Optional you will force the developer of the class itself to pay more attention to the optional feature of the field. The cost of this is the extra wrapper, the extra clutter in the code handling optional. On the other side there is no much gain, because you can get the same level of quality extending your unit tests checking all cases where null value of the field is to be considered. Since all the code is in the hand of the current developer being responsible for the whole code there is no benefit of Optional. It is again, like you not trusting yourself. That is a serious issue needing more and different treatment than what Optional Java class can provide.

Optional in functional programming

You can use Optional to program Java in functional programming style if you want, but Java is not a functional language and optional and lambda and the functional style methods alone will not make it to be. But that is a different topic for later.

Optional in collections

Sometime it is argued that the type Optional is worth being used in collections. It allegedly solves the problem of e.g.: HashMap that returns null in case there is no mapping for a key as well as when the value null is mapped to the key. If you use a Map<Optional<Something>> then you can clearly separate a missing mapping and an absent value. And that way you are one level deeper in the rabbit hole.

First of all

you can

tell if a key is mapped to null or not mapped without using Optional. There is the method containsKey(). This is one more method call to separate the non-mapped key from a mapped null value. However calling the methods of Optional is also. So what is the point? On the other hand

you do not need

to tell if the key is mapped to null or the mapping is missing. If there is a difference in your program code between the two cases then you created the code for the business login in a wrong way. This is certainly code smell. Think of null as “nothing”, and instead of thinking “null is assigned to the key ‘aaaaaarrghhh'” say out loud: Nothing is assigned to the key ‘aaaaaarrghhh’. You see? There is no difference except that all look at you now in the office.

And using optional as a value in a Map

you will

end up one level deeper in the rabbit hole after a while. Code lives independent life. It is not only you, who develop it. In large organizations there are developers who are certainly drunk when code. (This is the only reasonable explanation for some code.) They will soon populate your Map<Optional<Something>> with

  • null values,
  • absent Optional values
  • and even with Optional object that wrap something else but not your “Something“.

From time to time, if you are lucky you may even find some non null, non absent Optional<Something> values.

Some thoughts about yagni

Yagni means “You Aren’t Gonna Need It”. This is a phrase used many times to refuse the development of some features that may be needed later but not now. Yagni means that you should develop a feature in your code, which is needed and when it is needed and not sooner.

Why do we have this term at all? Do developers tend to develop features that are not needed? It should be like that otherwise there would not be any expression for the phenomena. It may seem crazy for someone not knowing how a programmer thinks and works.However the fact is that programmers do like to develop features that were not requested.

Why do programmers tend to develop features that are not needed?

Reasons and Problems of Yagni

Coding a feature, which is similar to one I have just developed is easier than something totally unrelated. Developing similar features one after the other is simpler than developing one, then doing something totally different and developing the second one weeks later. The developer is “on the track”. She knows how to develop the feature having just developed a similar one.

The problem is that many times the feature will not be needed (1). Even if it is going to be needed there is high probability that it will be needed a bit (or a lot) different from what has been developed (2). The code developed but not in use by business has costs attached to it (3), but no business benefit.

If (1) the feature is not needed in the future the investment devoted to the development of the feature is wasted. It does not matter who is financing it. It may be financed by the business but many times I see that it is financed by (usually junior) developers creating the feature after work hours. They argue that it was a good way of learning, practicing. However I strongly believe it is not a good way of learning. It is a way someone lies to him/herself. The cognitive patterns in the brain prevent to admit: “I was wrong and wasted my time.” One can do more valuable things during that time and doing free work is not professional. There are better ways for learning or practicing something. Be professional!

If the feature is needed but in a different format (2) you have to modify it. It is not likely that the cost of the development at the first place and the modification is cheaper than developing the feature the correct way upfront.

Even if it is needed and exactly the way it was developed the costs (3) associated with the prematurely developed features include maintenance, increased complexity debugging, maintaining and costs related to the delayed delivery of the features that were needed in early stage. It is likely that you do not deliver feature “ONE” faster if developed it together with feature “TWO”.

When Yagni is Good

The only situation when Yagni seems to be valuable is when developing a feature A alone needs extra coding that gets useless and erased when the latter feature is developed. For example you need feature A and to have it without the other feature B you need some extra classes that you will just throw away when you finished the development of B.

The reasoning is good as formal logic. Only the basic assumption that such situation exists may not be true. The need for some extra code for A but useless when B is developed is a code smell. In that case you have to think about how to develop those extra classes so that they can be usable also by the feature B later on.

But wait a minute! Isn’t that yagni by itself? Developing some classes differently just because some later features will need it differently? No, it is not. To get that correct we have to distinguish between

Feature Yagni and Structure Yagni

So far I was speaking about feature yagni. Structure yagni is different and is not really a yagni. Well, most of the cases.

Wording is important! I do not advocate writing the classes for A in a way so that they can be used by B but nothing else. What I recommend is that you check your style and coding to find the reason why the extra classes would be thrown away. If you can write it different way so that they can be used when B is implemented then they are reusable (by definition). In that case your code is generally good (or at least better) style.

That way implementing good style code, creating clean code, good data and class structures is not yagni. The implementation of a feature not needed yet: that is yagni.

Refactoring is not Yagni

Even if creating clean code needs more work than the Q+D solution this extra coding, including some extra classes is not yagni. We do develop code that is not strictly needed by any business function. That way when there is some not soo good code and we refactor it is also not yagni.  This is not l’art pour l’art. It is needed by business and sometimes, if the seniors and BA do their jobs right business people even know it.

Practice avoid yagni

Writing code that does not develop extra features and is not especially prepared to be ready for extra features not needed yet (yagni), but are open for extension is hard. It is a kind of art and needs a lot of practice. Actually this is what we do when we strictly follow TDD. We develop a test first and it fails. Then we deevelop the code that is minimally needed to fulfill the test. Then we create the next test and so on. When doing TDD you never create a new test while there is a test failing and you never develop any (non test) code unless there is a test failing and you develop the code to pass the test, but nothing else.

This is exactly the practice to develop without yagni. It works on the small scale. When you start you hate it first. It seems to be slow and cumbersome like dacing hogtied. But after a while it becomes a habit, your code style improves and without realizing your way of thinking changes and you get the yagni free design on higher levels.

Teenage Sex and What the sun.misc.Unsafe Misery Teaches Us Generally

Lukas Eder wrote an article about the miseries of the proposed drop off of sun.misc.Unsafe. If you have not heard that Oracle will remove the internal sun.misc.Unsafe class in Java 9 then read the article of Lukas and follow some of the links he provides at your discretion. His article is about what we learn from this happening.

sun.misc.Unsafe is a class available in most of the Java implementations delivering some “unsafe” functionality that are not available in other ways. These functions are not part of the specification and are not guaranteed to be available. They just happen to be there and are available via some nasty reflection hack. In other words: you should not use it, but you can. There are some Java tools that help protect you from using the interface but not too heavily.

Other languages, like Perl do not even have that level of protection. In that language there is no ‘private’, ‘protected’ or other access modifier. What is created in a module it is there. You can use an underscore in front of the method to signal that it is meant to be private but that is more a polite ‘please’ than a harsh ‘thou shalt not’. The philosophy there says that you won’t come to my bedroom, not because I am standing there with a machine gun, but because going there would not be nice.

What sun.misc.Unsafe misery teaches us is that it does not work. Sorry to say, but it seems you need to have a gun in your hand to prevent library users invading your bedroom. That is also what Lukas suggests: put all your library internal code into a single package and make all package private.

But there are also other approaches. If you look at Jira and Confluence and the extensions you can write you see a different approach. By natural evaluation Jira started small and the designers probably never dreamed about such a huge developer community writing all purpose extensions to their software. They simply did not define an API at all. There were the jar files, the classes in them and extensions were free to invoke any method of any class more or less. The result: every extension had to be tested against each version of the software and when you had an extension working with one of the versions of Jira it may not work with the next (minor upgraded) version. Atlassian had a long way to define an API that is stable and is “officially” available for extension modules. Do they put everything else into a single package? I do not think so. Instead they listen to their customers, they have developers forum and they do have empowered employees listening on those channels and understand the needs and their API provides features that are needed by the users.

And this is the more appealing approach. If you provide the features that the users of the library need, they won’t bother to go into the bedroom.

If you do not provide the features, they WILL come in. You can not prevent them doing that, just like you can not prevent teenage sex. If you do provide what they need, they will not use forbidden calls no non API classes.

This is actually what Sun and later ORACLE failed to do properly (imho). They did not provide the features and “unsafe” was just there. They warned us many times not to use that, but they failed to tell what to use instead. And now it all is coming apart at the seams. What will be the consequences?

What I see as most probably scenario is the following:

  • Java 9 will come out without unsafe.
  • Because many libraries make use of the “unsafe” package implementation the industry acceptance of Java 9 will be delayed. The enterprise standard Java version remains 8 (or 7 or 6 in some enterprises) for prolonged time.
  • There will be signs of possible market loss for Java that will drive Oracle to give some solution.
  • There will be some API developed by Oracle providing a limited set of features (most commonly used features) of the current unsafe feature set.
  • Libraries will be modified within few months using the new API.
  • Enterprises will skip to the version that supports the new API.

What I do not expect to change is the attitude of Oracle to customers.

We will see how accurate it was in … two to three years?

Why we do not use comments

When I learned PASCAL programming at TU Budapest in 1986 there was a preprocessor developed specially for student code. It stopped the compilation process if the number of inline comments was less than the number of executable code. There was a rule: we had to have at least 50% of the code meaningful comments. 30 years passed and now we fight inline comments. Clean code purists evangelize not to have inline comments at all and have unit documentation (JavaDoc in case of Java) only on the interface. Anything else explaining the implementation has to be self explanatory from the code itself.

That time there were even tools that extracted inline comments into documentation partially including the executable code. Can you recall WEB and TANGLE? That time it seemed to be very exciting to have a language that can be compiled to TeX for documentation purposes and also to PASCAL so the code could be executed. After 30 years we can see that was a dead end street. We do not mix programming and documentation. We rather separate them.

What is the reason for the change of attitude? Computer scientists 30 years ago were “stupid”? Were they advocating something that was and is bad? Or was that good that time and it is good now? Is there something that radically changed in the world and we live in a different world?

I was thinking about this recently and came to the conclusion that the answer is: A bit of both. The word “stupid” is a bit harsh and rude, but stating that computer scientists did not know as much as they do today is agreeable. After all that is development. If the knowledge remained the same it would mean we are at the point where we were 30 years ago. We learned a lot of things related to computer science. Many of these things are related to human science, and should belong to the area of psychology or something alike. That is one side of the dish.

30 years ago comments were demanded. Today we say that comments are bad among other reasons because they become outdated and misleading. 30 years ago the mantra was to keep the comments maintained along with the code and keep it up to date. Easy to say, but people tend not to follow that advice. For a while you can push the mantra and you can try to force people to keep their comments up to date but that is as futile as forbidding sex for a teenager. It is like trying to command gravity to stop and walk home dry while the raindrops float above your head. Human works differently and you can not alter human mankind. What is the solution we seem learned in 30 years? Adapt practice to what human can and will do.

If comments get outdated and misleading then it is better not to have any. On the other hand we need something to compensate for the loss of the feature comments provided. What we aim now is readable code. And this is the other side of the scale. This is something that changed in the world. We have new programming languages and new tools. If you were required to create readable code in FORTRAN or COBOL so that there is no need for inline comments you would be in trouble. Thus there was the strong push to comment. Those days the comments compensated for the language shortage and the outcome average was better including the misleading comments than naked code.

Today we have Java, Scala, C#, Go, Swift, Ruby, Python. All modern languages (sorry for those I missed) that make it possible to express the behavior and implementation in a readable and concise format that does not need comments. We also use unit tests, something that was unknown 30 years ago, which is more a documentation of the implementation than test. We use code to document, and ever less documentation going from waterfall towards agile. I hope that this is a good direction for some time and I look curious to the future.

Reasons to stay up-to-date and your tasks to help the senses

When you work in an enterprise environment you face many times applications implemented using outdated technology. And most of the developers agree that it is bad. It is bad not only because nobody loves to work with outdated technology but also because it is not good for the enterprise. Outdated technology is never so flexible as the new one, always has more development, maintenance and lost opportunity cost. You certainly have hard time to find an eclipse plugin for the actual version that supports struts 1.0 When there is some bug in the system you are less lucky to find a solution on open source boards. New environments produce easier to use user interface and are more flexible to develop features to follow the ever changing business needs.

All these seem evident and still enterprise environments usually contain a huge load of outdated software. Why? The reason is that change needs demand and the demand many time is lacking. A very good model for corporate change is from Kotter and it says that the first step out of eight steps for change is “sense of urgency”. If there is no sense then there is no action. There may be a need, but if people do not feel the urgency they will not change.

I recall an old story when I was working for Digital Equipment Corp. and we were requested to do a USA export training. We did not feel the urgency no matter how well it was explained why it is important for the company. On a day when the deadline was only a few days ahead I, who have not done the online training yet, got an eMail from the country manager: “Dear Peter, This training is mandatory. You or your successor will do the training. Sincerely: Ferenc” At that point I sensed the urgency.

There are other examples, like global warming, environmental pollution or me being overweight, all that will some time cost something more than just jobs or money.

Why did I tell this story? Because the situation in enterprise IT is similar. There is urgency for updating the technology, but there is a lack of sense. We pollute our environment with outdated technology, we face ever increasing (warming up) maintenance costs, more bugs that are harder to fix and many times a fix just causing other problems.

Technology people are in the position to help the senses. Albeit not exactly the same way as our country manager was doing. Those that are aware of the urgency should make documentation, presentation or any other effective way of communication to deliver the knowledge to those that should have the sense (of urgency) and to raise awareness.

If you are a good developer you should be able to communicate this to the business people. You can convince them to update the technology or else you will face dramatic change in the economy of the company. It may cost jobs and it may cost the enterprise in the long run. That is a problem. Not a tragedy, but a problem. If the company is on the decline and the shareholders decide to squeeze the last drops out of it but are reluctant to invest, the decision not to upgrade to a newer technology may be absolutely reasonable. On the other hand, as a developer you may not want to work there. On the other hand if the company is not on decline but the shareholders still decide not to invest into technology then actually the company is on decline. It is just that they are not aware of it. And again as a developer you may not want to work there.

Best Interview Answer Ever

I am not absolutely sure that this one deserves the title, but it should run for the prize. I swear it is not just made up. It actually happened during a java technical interview where the candidate applied for a senior position.

Q: When you work in a group following agile methodology and scrum what is the velocity of a team?

A: This is 6.1


Get every new post delivered to your Inbox.

Join 1,084 other followers