Everyone – devs, managers, quality assurance engineers, product owners – can hit a wall where they just don’t feel like doing anything. Here is what you do in that situation.
Originally posted on HBR Blog Network - Harvard Business Review:
There’s that project you’ve left on the backburner – the one with the deadline that’s growing uncomfortably near. And there’s the client whose phone call you really should return – the one that does nothing but complain and eat up your valuable time. Wait, weren’t you going to try to go to the gym more often this year?
Can you imagine how much less guilt, stress, and frustration you would feel if you could somehow just make yourself do the things you don’t want to do when you are actually supposed to do them? Not to mention how much happier and more effective you would be?
The good news (and its very good news) is that you can get better about not putting things off, if you use the right strategy. Figuring out which strategy to use depends on why you are procrastinating in the first place:
Reason #1 You…
View original 1,116 more words
If you are working with Enterprise software, you will likely encounter legacy code. In face, most of the code you encounter may be legacy code.
What is legacy code? One acceptable answer is simply “Code with out tests”. Another answer is any code that is old, brittle, and riddled with difficult to manage dependencies. In general you’ll find that testable code fixes dependency problems and doesn’t feel old or brittle.
As a enterprise developer, you are bound to find a pile of legacy code that you need to change. When you hit this wall, you will need to define a strategy to fix this code over time. An article titled Technical debt 101 – “A primer about technical debt, legacy code, big rewrites and ancient wisdom for non technical managers”. This article pretty accurately describes the issues we face in estimating how long it will take to fix large chunks of bad code and running into problems so large the only answer is “the big re-write”.
The conclusion of the article is as such: The big re-write is incredibly expensive, is near impossible to estimate the amount of work to do, and loses functionality and therefore won’t work in many situations. The solution is slowly making things better over time.
One popular way of doing this Branch by Abstraction. What does this mean in this context? It means that you take a class A, create an interface A, and an “implementation” of that interface A call AImpl. Finally, you must connect all references of the original class A to AImpl via Dependency Injection such as Spring or Guice. All of that gets you exactly back to where you were ahead of time. So why do all of this work? Because the next step is to create a B “implementation” that doesn’t suck. Once BImpl is tested, flip the switch in Spring/Guice to use BImpl instead of AImpl.
This is not easy. But it is an actionable strategy for fighting legacy code without the big re-write. Once you’ve done the first class or service, moving on to the second class or service will be much easier.
We all love visuals, so here is a slide show describing the concept.
So there it is – don’t do the big re-write. Find something worth changing and do so one bite at a time.
This is how things are supposed to work.
Go to http://www.mixest.com/
Register yourself as a user on this site. Forget about the music selection or if you like the songs or not, that’s not what I’m getting at here.
You registered on this site, and the music never stopped playing. The pause button never even moved.
Intuitive, Concise, Effortless . This is how a UI should be made.