Here are some questions you should ask before starting a rewrite or rebuild of an existing software application.
This is a list to get you started. Once you have this information it is an important baseline for you to think about how to move forward on your rewrite/rebuild/re-engineering effort.
What is the age of your application? (How long since the first line of code was written?)
a. 0-5 years
b. 6-10 years
c. 11-15 years
d. 16+ years
How many integration points do you have with outside systems?
a. 0 (lucky you!)
b. 1-4
c. 5-9
d. 10+
How many different types of people use the system?
a. 1-4
b. 5-9
c. 10+
Will you migrate data from the old system to the new?
Roughly how many man-years have gone in to the development of the system?
a. 0-10 years
b. 11-20 years
c. 20-40 years
d. 40+ years
What makes the current system great? What do your customers love? What differentiates you from your competitors?
How much time needs to be spent recreating supplemental materials for a new system? Things that fall into this category - training programs, user manuals, help pages, websites, wikis.
What are the business (not technical) drivers for recreating the system?
I have updated this blog to use the Tiles theme. I was looking to shake things up and I was impressed with the layout and animations. It provides a bit of visual interest, while staying true to a pretty straightforward blog site.
Having all the posts on a single page is different. And I do miss my old orange circuit board cover image, but I'll get over it.
I reference it again, because it is great and it makes a lot of good points.
One thing it says is that 'Code Doesn't Age'. Specifically, Joel says this:
The idea that new code is better than old is patently absurd.
This is true in many senses: code doesn't get rusty, code doesn't wear out after the millionth time it's used, and you can make a thousand copies and this does not effect the code's quality in any way. Also, as he says, old code has been tested, where new code has not.
However, code can age, and I want to talk a bit about that and what it means to you. How can this ageless thing age? Here's how:
Code Doesn't Stand Alone - unless you have a very, very simple program, it is connected to lots of libraries and (today) APIs. These things don't stay the same, nor are they supported forever. So, your code doesn't physically get old, but sometimes the things that it relies on break, or they get changed, or they are killed off. When this happens, your code just got old, very fast.
Code Runs on Something - it used to be hardware, and deep inside of a data center somewhere that is still true. But even when we're only talking about VMs, VMs have operating systems and supporting code and those things aren't supported forever either.
Code is Written by People - and people don't write COBOL anymore. Or at least most people don't. People also don't write VB or C++ as much as they used to. Sometimes perfectly good technologies fall out of favor and everyone learns something new making your product hard to support.
It used to be, most of what I'm describing happened over a long period of time. COBOL didn't go away overnight, that took decades. But with things being more and more interconnected via APIs, and with more changes coming quickly to platforms and other programs, the pace of change is increasing.
APIs change all the time, which is great (Hooray for new features and better performance!) and also challenging (I have to make the changes by when?).
Sometimes things come and go quickly or you make a bad choice. Silverlight anyone?
So, code doesn't physically age, but it is dependent on things around it. Those things can change or break. If that happens, the code has to be kept up or it has to be refactored or (sometimes) you need to rewrite an application entirely because the people who built the original are all retired.
The good news - you get to build something great with new technology that leverages all the awesome things your old project did, but is new and shiny and fun to code.
The bad news - all the things in that article are still true. So, you need to plan for them.
We're currently having some discussion about what to call this process (Rewrite? Rebuild? Re-engineer?) On the new Exadel website. I'm partial to Rebuild, but I think that Re-engineer is likely to win.
In my relentless pursuit of information on this topic, I'm compiling a list of articles related to it.
... wisdom is the knowledge of what we know and do not know.
-Plato
All things that we learn provide us with three things:
The knowledge we gain.
The actions and ideas that flow from that learning.
A redrawn border between what we do and don't know.
Each time we practice something we change the map in the same way: a skill improved is a skill added.
It is good to develop the ability to see this boundary for ourselves, so that we don't always need to have others point it out to us. This also takes practice.
I don't see this as either positive or negative. We know some things, others we don't. We can choose to use this awareness in whatever way we want: learn more, seek help from others who are knowledgeable, act on what we know, or ignore it.
It's up to us how to attack the challenge presented by the boundary of our ignorance. No judgement.
Does all this lead to wisdom? I leave this as an exercise for the reader.
Link to the translation of Plato where I found the quote. Translation by Benjamin Jowett.
People need to hear that they are doing well, and the recognition needs to be specific.
Probably the most important way to be mindful in your recognition is to start recognizing others - be present, pay attention, tell people when they are doing well.
If you don't provide feedback, the natural tendency of the mind is to assume the worst, see Negativity Bias.
How else can you be mindful?
Be specific. When you are specific you are engaged with that person and clearly present and speaking honestly about what you value in them.
Provide feedback quickly. Don't wait, do it in the present moment.
Recognition of small, but valuable contributions is important.
Consistent, frequent recognition is important - best to develop the habit of recognition.
Have a baseline of honest dialog with the person. If you have previously given them constructive criticism then the recognition will be more powerful and more easily accepted.
Recognize others to a broader audience - this may mean including YOUR superiors on the recognition email or it may mean sending a thank you note home so that a spouse or child could see it.
Number 5 is interesting and requires real ground work ahead of time. It doesn't always have to be criticism - it could be goal setting or something similar. You need an honest framework for conversations and something more than just 'you always do great at everything you do.' Sooner or later that is going to become hollow feedback.