Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I recently started a career in software development after graduating a couple of years ago in CS. The current project I'm on is a large ongoing project that has it's origins in the 90s with a mix of C, C++, and Java. There are multiple platforms (UNIX, WIN, etc) being supported, older technologies in use like CVS, and some dated documentation in some areas.
The extent of my software development skills stem from going to university as I've had little real world experience. I felt like I had a decent foundation in CS but I cannot but help feel slightly overwhelmed by it all. I'm excited to be part of something so huge but at the same time I feel like it's a lot of information to absorb.
My coworkers have been great people and answer a lot of questions I. My employer hired me knowing that I am entry level.
I've tried poking around the source code and examining how everything gets built but it's on a scale I've never seen before.
How do more experienced people situate themselves when joining a large ongoing project? What are some common tasks you do when getting yourself up to speed?
Good question. I haven't had your exact experience, but in cases like this I like to think, "how do you eat a whale?" The answer is (predictably) "one bite at a time." Reasonable people won't expect you to grasp the whole thing immediately, but they will want to see progress. Perhaps there are some small areas of the larger project that are not too complex, without too many dependencies. Work toward understanding one of those and you're one 'bite' (and/or 'byte') closer to expertise on the whole project.
Being familiar with all existing documentation I would try to get the big picture. Literally.
generate a TreeMap of the source code
I would use GrandPerspective on Mac or WinDirStat on Windows. It will give you some insights about the structure of the project's files (sometimes it gives some hints about the code structure). Having this, you can ask your colleagues for some of the clusters, what they do, how they relate to each other.
learn how to build the project
This is important to have it compiling all the time if you are about to do any changes. Having tests executed at the build time is always a good thing, so ask for it also. Even better if there is some kind of continuous integration server in place. If there is, look at its configuration - figure out how the build is done. If there was no CI server, but you already got the knowledge how to build the project, create such a server on your local machine, and show it to your fellows - they should fell in love with it.
browse the source code with Structure101 or similar tool
This is useful especially for Java projects. This tool does great job. That will give you more details about the code structure, and sometimes about the system architecture. This experience may be sometimes hard, you may learn from this tool that a code is basically a Big Ball of Mud ;)
look for tests, and explore them
If you will be lucky there may be some JUnit, or CPPUnit tests. This is always good to try to understand what those tests are doing. It may be a good starting point to explore the code further.
My coworkers have been great people
and answer a lot of questions I. My
employer hired me knowing that I am
entry level.
You have little to worry about, you're employer knows what you are capable of and your co-workers seem eager to help you out - to be honest most developers love explaining things to others...
From what I've seen, it take truly 6+ years to become fully knowledgeable in a language, so don't expect to become a guru within a year... and even these so called gurus end up learning something new about their language everyday.
Learning a new system (large) will always take time.... the systems were usually not built in 2 weeks but over many years, so don't expect to understand it fully yet. You'll eventually discover what each part does piece by piece.
I know how you feel, because I felt like that once...
"I took a speed reading course and read 'War and Peace' in twenty minutes. It involves Russia." (Woody Allen)
I agree on what the others said before me. You need some tools that give you an overview on the code. I personally used inFusion (http://www.intooitus.com/inFusion) because it gives also other interesting data beside structure.
The method that has worked best for me is to grab a copy from source control, with the intention of throwing this version away...
Then try and refactor the code. It is even better if you can refactor the code that you know you will be working on at a later stage.
The reason this is effective is because:
refactoring gives you a goal for you to aim towards. Whereas "playing" an "breaking" the code is great - it is unfocused.
To refactor code you really have to understand the code.
Refactored code leaves code that has less concepts to retain in memory. If you don't understand a large codebase its not because you are a graduate - its because nobody can retain more than 7 (give or take a few) concepts at a time.
If you follow correct refactoring guidelines it means you will be writing tests. Although, make sure that you will be working on the modules that you are testing as writing tests can be very time consumning (although very rewarding)
Do invest in buying this book at some point:
http://www.amazon.co.uk/Refactoring-Improving-Design-Existing-Technology/dp/0201485672
But these links should get you started:
Signs that your code needs refactoring and what refacoring to use (From Refactoring - Martin Fowler)
http://industriallogic.com/papers/smellstorefactorings.pdf
A taxonomy of code smells:
http://www.soberit.hut.fi/mmantyla/BadCodeSmellsTaxonomy.htm
Good luck!!!
I agree to the first comment but I also Think that you have to learn and see the big picture in some way. You have to trace the main flow from code at least.
I was in the exact same situation several years ago when I joined a software project with 50+ ClearCase version control vobs, 5 million lines of code, and some of it dating back to the 1980's.
The first thing I did was look through every source controlled directory and made a quick summary of my best guess about what the software in that folder did and what language the code was. You can make a pretty good guess by looking at filenames and any comments or documents in those folders.
I then looked at the build scripts to see if they were readable enough to get an idea of dependencies between different parts of the code.
Finally - and I believe this was the most valuable - throw an IDE like Eclipse or NetBeans on top of the code and start reading through pieces of it. Having the ability to jump to the definition of any functions or classes using the IDE allows you to move around a massive software baseline with relative ease.
Overall, have some confidence - it is unlikely that anyone else on the project knows all of the code, so you don't need to either. Use what other people said to get a good idea of the overall project and interfaces and requirements (if they exist) and poke through the code to get an idea of the most commonly used classes and methods.
Say I find a Windows developer with 10+ years of experience, great skills in C/C++ and excellent references as a versatile coder who gets things done. Can I hire him for development on the Linux platform and expect him to be efficient in production within a couple of weeks? Or is the threshold too high when speaking in terms of development environment and all the common tools used in daily work? What are the main obstacles for this person to overcome?
Note, this is a general question, where I basically assume typical Windows and Linux environments (Visual Studio vs. Eclipse or EMACS, Add/Remove programs vs. apt-get, dialog wizards vs. commandline, and so on)
It really depends on a lot of factors.
A really good developer will be able to learn everything they need to know fairly quickly. The main language is the same.
However, depending on what you're developing on Linux, there may be some major learning curves to overcome.
A couple of examples:
The entire operating system APIs are different.
If you're using any large libraries, there will be a learning curve to the library.
If you're using more traditional unix build systems, there will (possibly) be a learning curve to using those vs. the normal "Windows way" of working in an IDE like Visual Studio.
I think expecting to have a perfect dev. in 2 weeks is probably a bit ambitious - but if they're good, they'll get productive quickly.
I was exactly such a developer not long ago (but I did have some *nix experience way back).
For me personally, I found the initial transition very easy. There are adequate tools for everything you need to do to at least get coding. The second phase was very difficult - finding exactly the right tools for what I was doing, and how to use those tools. I was dropped into this particular project alone, so I had no one but Google to ask, and it did take a long time to learn the keyboard shortcuts and whatnot of the new IDEs and compiler switches.
I felt, at the time, that if I had had someone to ask questions of, the whole thing would have taken a lot less time.
So long answer short: I think any good programmer won't have trouble with the easy stuff, but make sure the new dev is told frequently and in a friendly manner that everyone else is there to help answer questions.
I've attempted to switch to Linux/Unix many times. I can basically find my way around the box and do development [if I've got Mono]. Now, I can be equally as efficient in terms of basic user requirements on just about any box in a short amount of time, but if you expect me to be able to figure out all the installation, configuration and all the other stuff that comes with system maintenance in that short a period of time, I daresay I'd pull all my hair out before the two weeks was up. Invariably, someone will ask me to do something I have no idea to do in Linux/Unix and will end up switcing back to Windows because I can easily do it in a short time.
I'd say if they have other people to ask questions, sure, it's a piece of cake. If you expect them to kind of hit the ground running as a self starter, it's doubtful.
Great developers will be great on any platform. It may take him a little while, but if he is the "gets things done" sort, he should be able to get up to speed and make positive contributions to the project.
I think yes, but you might need to be patient for a longer ramp-up time. An idea: give him a Windows box with a Linux virtual machine running inside (or vice-versa), so if he runs into something he can't do quickly in Linux, he can switch over to Windows for that particular task until he becomes more proficient on the Linux side. This may mitigate some of the "separation anxiety" some windows users have when switching to Linux. Think of it as "Linux with training wheels."
Good programmers is good programmers, and they're hard to find. You can make it work if you want to.
Well if he really is a guru, I would say yes. Many studies show that a good programmer produces more that 10 times as much useful work in a day as an average programmer. A real guru probably produces 100 times as much.
So given a choice between a WIndows guru and an average Linux guy, I'd ttake the guru any day.
Why can't you hire a Linux guru instead?
That's funny how many people have come to declare "Yes sure he can".
Why nobody asks whether he would want to?
There is no doubt that Windows guru (if that is true) can handle the Linux stuff.
The only thing you should ask yourself is how much time do you have 4 the project, as you can't expect somebody that was never developing in Linux to be as fast as someone else who does that for some time.
If you can afford to let the man have some time to take a running stance, you should give him a go.
I think it depends. If you take away a man's Visual Studio, you are halving his productivity right there. If you are doing everything in emacs with commandline compilers, you've probably just lopped off another half of his productivity. Now, some of this will creep up over time as he becomes more familiar, but you can pretty much bet that this guru will never be as productive on Linux without the IDE.
If I can remember back into the Bronze Age, when I learned programming on Unix, the technique I used was to learn things as close to one at a time as I could. I didn't learn vi until I was already reasonably comfortable with C. Then I learned make, and then studied the Unix API. Eventually, it got to the point where I was just learning what I needed to know when I needed to know it, but it took months.
At least the guy you're talking about is proficient in C and C++. Get him a halfway decent IDE if he doesn't want to tackle vi or Emacs and make. The big question then is the APIs in use; they may take some time to internalize. And make sure you've got somebody to answer the simple little questions and do some of the smaller but potentially confusing things for a while.
By 'challenging development environment' I don't mean you're on a small boat that's rocking up and down and someone is holding a gun to your head. I mean, are the tools at your disposal making the problem difficult?
Development is typically a cycle of code, run, observe the result, repeat. In some environments this is a very quick and painless process, but in others it's very difficult. We end up using little tricks to help us observe the result and run the code faster.
I was thinking of this because I just started using SSIS (an ETL tool included with SQL Server 2005/8). It's been quite challenging for me to make progress, mainly because there's no guidance on what all the dialogs mean and also because the errors are very cryptic and most of the time don't really tell you what the problem is.
I think the easiest environment I've had to work in was VB6 because there you can edit code while the application is running and it will continue running with your new code! You don't even have to run it again. This can save you a lot of time. Surprisingly, in Netbeans with Java code, you can do the same. It steps out of the method and re-runs the method with the new code.
In SQL Server 2000 when there is an error in a trigger you get no stack trace, which can make it really tricky to locate where the problem occurred since an insert can have a cascading effect and trigger many triggers. In Oracle you get a very nice little stack trace with line numbers so resolving the problem is very easy.
Some of the things that I see really help in locating problems:
Good error messages when things go wrong.
Providing a stack trace when a problem occurs.
Debug environment where you can pause, then output the value of variables and step to follow the execution path.
A graphical debug environment that shows the code as it's running.
A screen that can show the current values of variables so you can print to them.
Ability to turn on debug logging on a production system.
What is the worst you've seen and what can be done to get around these limitations?
EDIT
I really didn't intend for this to be flame bait. I'm really just looking for ideas to improve systems so that if I'm creating something I'll think about these things and not contribute to people's problems. I'm also looking for creative ways around these limitations that I can use if I find myself in this position.
I was working on making modifications to Magento for a client. There is very little information on how the Magento system is organized. There are hundreds of folders and files, and there are at least a thousand view files. There was little support available from Magento forums, and I suspect the main reason for this lack of information is because the creators of Magento want you to pay them to become a certified Magento developer. Also, at that time last year there was no StackOverflow :)
My first task was to figure out how the database schema worked and which table stored some attributes I was looking for. There are over 300 tables in Magento, and I couldn't find out how the SQL queries were being done. So I had just one option...
I exported the entire database (300+ tables, and at least 20,000 lines of SQL code) into a .sql file using PhpMyAdmin, and I 'committed' this file into the subversion repositry. Then, I made some changes to the database using the Magento administration panel, and redownloaded the .sql file. Then, I ran a DIFF using TortioseSvn, and scrolled through the 20k+ lines file to find which lines had changed, LOL. As crazy as it sounds, it did work, and I was able to figure out which tables I needed to access.
My 2nd problem was, because of the crazy directory structure, I had to ftp to about 3 folders at the same time for trivial changes. So I had to keep 3 windows of my ftp program open, switch between them and ftp each time.
The 3rd problem was figuring out how the url mapping worked and where some of the code I wanted was being stored. Here, by sheer luck, I managed to find the Model class I was looking for.
Mostly by sheer luck and other similar crazy adventures I managed to work my way through and complete the project. Since then, StackOverflow was started and by a helpful answer to this bounty question I was able to finally get enough information about Magento that I can do future projects in a less crazy manner (hopefully).
Try keypunching your card deck in Fortran, complete with IBM JCL (Job Control Language), handing it in at the data center window, coming back the next morning and getting an inch-thick stack of printer paper with the hex dump of your crash, and a list of the charges to your account.
Grows hair on your fingernails.
I guess that was an improvement on the prior method of sitting at the console, toggling switches and reading the lights.
Occam on a 400x transputer network. As there was only one transputer that could output to console debugging was a nightmare. Had to build a test harness on a Sun network.
I took a class once, that was loosely based on SICP, except it was taught in Dylan rather than Scheme. Actually, it was in the old Dylan syntax, the prefix one that was based on Scheme. But because there were no interpreters for that old version of Dylan, the professor wrote one. In Java. As an applet. Which meant that it had no access to the filesystem; you had to write all of your code in a separate text editor, and then paste it into the Dylan interpreter. Oh, and it had no debugging facilities, of course. And being a Dylan interpreter written in Java, and this was back in 2000, it was ungodly slow.
Print statement debugging, lots of copying and pasting, and an awful lot of cursing at the interpreter were involved.
Back in the 90's, I was developing applications in Clipper, a compilable dBase-like language. I don't remember if it came with a debugger, we often used a 3rd-party debugger called 'Mr Debug' (really!). Although Clipper was fast, some of our more intensive routines were written in C. If you prayed to the correct gods and uttered the necessary incantations, you could use Microsoft's CodeView debugger to debug the C code. But usually not for more than a few minutes, as the program usually didn't like to spend much time running with CodeView (usually memory problems).
I had a series of makefile switches that I used to stub out the sections of code that I didn't need to debug at the time. My debugging environment was very sparse so there was as much free memory as possible for the program. I also think I drank a lot more back then...
Some years ago I reverse engineered game copy protections. Because the protections was written in C or C++ they were fairly easy to disassemble and understand what was going on. But in some cases it got hairy when the copy protection took a detour into the kernel to obfuscate what was happening. A few of them also started to use of custom made virtual machines to make the problem less understandable. I spent hours writing hooks and debuggers to be able to trace into them. The environment really offered a competetive and innovative mind. I had everything at my disposal save time. Misstakes caused reboots and very little feedback what went wrong. I realized thinking before acting is often a better solution.
Today I dispise debuggers. If the problem is in code visible to me I find it easiest to use verbose logging. (Sometimes the error is not understanding the interface/environment then debuggers are good.) I have also realized time is of an essance. You need to have a good working environment with possibility to test your code instantly. If you compiler takes 15 sec, your environment takes 20 sec to update or your caches takes 5 minutes to clear find another way to test your code. Progress keeps me motivated and without a good working environment I get bored, angry and frustrated.
The last job I had I was a Sitecore Developer. Bugfixing can be very painful if the bug only occurs on the client's system, and they do not have Visual Studio installed on the system, with the remote debugging off, and the problem only happens on the production server (not the staging server).
The worst in recent memory was developing SSRS reports using Dundas controls. We were doing quite a bit with the grids which required coding. The pain was the bugginess of the controls, and the lack of debugging support.
I never got around the limitations, but just worked through them.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 3 years ago.
Improve this question
Skunk Works Project: A project carried out by one part of a company without the knowledge of the remainder of the company.
Looking for stories about any skunk works projects you've worked on or initiated:
Was it successful?
Were you found out?
Were you punished or rewarded?
How did you fund it?
How did you staff it?
How long did it take to finish, compared to above-ground projects?
What was the cost, compared to above-ground projects?
Was it formally adopted?
Excellent question. Very important question.
Geoffrey Moore (Inside the Tornado, Crossing the Chasm, etc.) has written that, as he lectured around the world, he had one question he would ask every client (including those like GE, Motorola, etc.)
The question was:
"Can you give me even one example of a truly ground-breaking, paradigm shifting innovation that has ever come out of your company's research or product development process?"
At least at the point where I read the quote, not one example had been identified. And in most cases, such products or services had been conceived, designed, and largely developed by small groups of people who at best were ignored, but were often actively opposed by R&D.
Not sure if this qualifies as a "skunk works" project, but here's a great story from This American Life. It's Act Two of this March 2005 episode.
Amy O'Leary tells the story of a
software writer at Apple Computer
whose job contract ends, but he
refuses to go away. He continues to
show up at work every day, sneaking in
the front door, hiding out in empty
offices, and putting in long hours on
a project the company cancelled. There
were no meetings, no office politics,
no managers interfering with his work.
Soon, he had written a perfect piece
of software. His final problem is
figuring out how to secretly install
it in Apple's new computers without
anyone noticing. (12 minutes)
Great listening for anyone, but especially programmers in this case.
I have actually done a number of these "Secret" project type situations. Were they are not fully supported when started, and kept very secret. I'll discuss on of these along the lines of your questions.
Was it successful?
Yes, the system developed was put into place 3 years ago, and has been functioning ever since.
Were you found out?
Yes, it was discovered, and it was part of the overall plan.
Were you punished or rewarded?
With a working prototype we were rewarded, given the extra resources needed, and eventually the system was put into place for the entire company to use.
How did you fund it?
It was a development activity that was simply completed in down-time and personal time by various people.
How did you staff it?
See the above.
How long did it take to finish, compared to above-ground projects?
We did the entire thing in about 4 months, with dedicated resources a single person could have done it in about 2 months, or a team in about 3-4 weeks.
What was the cost compared to above-ground projects?
No cost, using down-time that was already "wasted" to be put to effective use. All existing infrastructure for the final incarnation was already there.
Was it formally adopted?
Yes, it is a solid part of the business plan now, and has been for over 3 years.
We are currently in this situation, although, admittedly, the project will not have high visibility aspects - even though everyone will be eventually using it.
As part of a preparation to rebuild most of our enterprise applications, we have started developing an application framework that will be the basis for all of the replacement applications. We already have "bench projects" and "proof of concept" time that everyone is aware that we use to evaluate concepts. How it is different this time, though, is that we are actively developing a full project.
Was it successful? - We have not rolled out the full framework yet, but since it is modular, have been rolling out pieces in the legacy applications. Most of these are focused on stability and reporting/logging concerns. So far, they have exceeded expectations, allowing us to react to issues more rapidly, as well as eliminating some previously recurring ones.
Were you found out? - Well, this project has become one of the worst kept secrets I have ever seen. While there are quite a few people who have heard the name of the project thrown around a bit, I don't think anyone outside of a few of my developers and the testing team really know what it is about.
Were you punished or rewarded? - We haven't considered either side of this, yet. Unless the framework would cause negative effects, I doubt we would be punished for it. However, even if it is a success, the reward will be that no one notices anything other than improved applications.
How did you fund it? - Like mentioned before, bench time between other projects and inclusion in "proof of concept" work. I have also been putting some of my own personal time into it on my commute, since it will lay the groundwork for how all of my developers interact with the applications in the future.
How did you staff it? - I started with a series of small proof of concepts within the legacy codebase as part of "maintaining" the applications. Going in and fixing a defect often involved analytical steps on what could be done to prevent things from happening or improve the experience in the future. These were eventually extracted and refactored in their own assemblies, which became the beginning of the framework. We are now placing "covert" projects into our iterations that help flesh out these ideas through my developers, and we are now extracting and refactoring their efforts based upon the success of the implementation.
How long did it take to finish, compared to above-ground projects? - Yet to be determined. Since this is not an official project, so far it has really cost nothing. Bench time and "proof of concept" work is standard inclusion. The fact that we are essentially creating something from this time instead of throwing it away is gravy.
What was the cost, compared to above-ground projects? - Once again, yet to be determined. I imagine that the up-front cost will be relatively small compared to larger projects. Considering that this is a framework to contain commonly used extensions and improve the ability and quality of the developer to work efficiently, it will probably pay for itself before it is finished due to time-saving, improved practices, and reduction in defects.
Was it formally adopted? - The developers have embraced the concept. My immediate management is chomping at the bit. My management peers are excited, if not a little confused on what it will do. The measurement will be the success of the applications that are built off of the framework - which is some ways away still.
I built a tool to validate schema changes to the target DB at work. prior to my tool we did it all by hand with fugly scripts that DBA's at client sites had to run. my tool started tracking the structure of the database to know if certain things would work out. I got frustrated with having to hand check all this stuff or suffer from the errors inevtiable in doing things by hand so I built my validator and here is its story...
Was it successful?
Yes
Were you found out?
yes. Part of the aspect of a skunk works project is that it has to surface eventually.
Were you punished or rewarded?
Punished initially - why not work on mainstream activities. But rewarded once the benefit was made evident and product errors were reduced. Then it was heralded- everyone loves a winner.
How did you fund it?
For the love of coding it up and making my life easier - so no direct funds needed. Unless was part of managements plan to have a secret project i cannot see how this would be otherwise.
How did you staff it?
I coded alone as a lone developer on a grassy knoll with my laptop.
How long did it take to finish, compared to above-ground projects?
Not comparable. my skunksworks effort was maybe a year of tinkering. If we had set out to do it directly i cant imagine it would have taken less than 2 months directly but I do not know since thats not how it morphed. Downtime to think and plan may have made it faster in the end compared direct planning upfront.
What was the cost, compared to above-ground projects?
Undetermined - As I mentioned, given that I had down time to think and plan it was able to evovle in the direction I wanted without schedule/result pressures. In a shorter or more resource involved project we probably would have made some mistakes in rushin to get to some M1, M2 etc. Besides if it didnt work out, its would have been as if it had never happened as I could have folded up the tents and gone quietly into the night.
Was it formally adopted?
My project is a key part of the product build at my work so I would say its entrenched.
Hmm... I did one of these today actually.
We've got no real backup system in place. At present I get the highly enjoyable task of backing up 100GB of SVN repositories using svn hotcopy and .tar.gz files, while trying to juggle them across two or three NFS shares with limited disk space to get to the server with the backup disk. That's in the best case - i.e. when I can be bothered to babysit the process for 2 hours.
Since that's bound to end in catastrophe sooner or later I did a git svn clone on the largest one straight onto the backup server, then cloned that to my own machine and kicked out the svn working copy I was using. I've gained about 1GB of free space on my machine, given the most important backups some redundancy, and reduced a 15 minute svn st to a 30 second git status. And will I get complained at for it? Probably...
Generally the answers here have been success stories, so I thought I'd share my recent experience sitting just outside such a project that did not go so well.
How did you fund it?
How did you staff it?
The project started when my manager identified a potential employee, lets call him Fred, who had a pet project in our field. We don't pay well, and they they agreed that Fred would be hired and would work almost full time on the project, which they would eventually introduce to the business.
So Fred's started work on the project, known only to Fred's team but not to management or other parts of the business. Fred is a developer, and the work was more-or-less pure development, plus contributions to an underlying open-source project.
Was it successful?
Not really. Fred was working on it alone, and I think would have spent 12-18 months on it. Progress reports to the team consisted of describing whatever bug he was fixing that week. Occasional attempts were made to interest one or two higher-ups in the organization, but they never really went anywhere. Fred was supposed to put together a plan to finish and roll out the project so it could be introduced to the organization, but there always seemed to be some reason it was never done.
Were you found out?
Word slowly filtered out as Fred an the manager tried to interest more people in what they were doing.
Eventually we got restructured, and our new director wanted to know what everyone was working on, and the project was revealed to him. However, it was apparently not explained very well, since the new director wound up asking me (and others in our team I am sure) what exactly Fred's project was?
Were you punished or rewarded?
Eventually the new director froze all funding for the project and Fred was reassigned to work on other projects. That's the current status as far as I know.
How long did it take to finish, compared to above-ground projects?
Was it formally adopted?
It was not finished and it was not adopted.
What was the cost, compared to above-ground projects?
The ostensible cost was Fred's time.
However, there were other costs.
First, Fred and his project became a it of a joke in our team, and later in the teams we work with. What was he doing? Why was he doing it? Why was there no progress? Fred's reputation suffered. "Fred's project" became an in-joke for a project that was going nowhere.
Second, the eventual revelation of such a long-running but hidden project reflected poorly on our manager, and by extension on our whole team.
Third, resentment grew. Why was this guy working on his pet project when there was so much real work to be done? We are a small but busy team and we could have used a developer on any number of other projects.
In the end, I think this project has had consequences for our team's standing and dynamic. I occasionally talk it over with team members, when we're away from the office. Initially (and at the time) we were very critical of Fred, who can be an irritating guy, and who does not take criticism well, and who promised something he couldn't deliver. More recently, we've been critical of our boss. This was not a good way to run a project, and it was obvious from very early on that Fred did not have the skillset to do this work on his own and he would not seek or take advice. It was unfair to Fred that he was put in that position and left in it for so long. Lately I have wondered if I should have raised my concerns more forcefully. Though we did push Fred and our manager on what the project was and where it was going, we did not take it any further than our team. Having said that, I cannot imagine a good outcome even if we had.
Finally, I'd like to say that Fred is a smart guy and the project was not a bad one. It could have been successful (some parts have since come out in competing projects -- inferior competitors that actually delivered).
If this project had been done above board, and Fred had been working with a decent project manager and had a good communicator on the team, it could well have found a champion and delivered something great. Either that or it could have been killed a lot sooner.
I did one of these. It's actually how I ended up programming.
I was responsible for maintaining a legacy, er... "database". I won't go into gory details but it was the usual evil application. The company pretty much ran on it, it would sometimes go down for days. At the time the IS director (a friend) was actively looking for replacements, talking to large consulting organizations, etc.etc. but management was committted/emotionally invested in the existing system. I volunteered (to the IS director) to try to rewrite is (well, more like he asked if anyone was interested in trying to deal with this mess and I volunteered because I was bored). We had no real programmers on staff, and I'd only written a few small ad-hoc things. I had no idea how little I knew.
Finished the thing in about 8 months or maybe a year (this was a while ago, don't remember exactly).
Was it successful?
yes, worked as advertised.
Were you found out?
It initially started as a sort of super-secret, cloak and dagger thing. Kind of silly in retrospect, but it made it more fun. About halfway through it just started to become more obvious that that was what I was doing, and as it turned out the idea was supported. Writing this thing eventually became my job.
Were you punished or rewarded?
Rewarded
How did you fund it? / How did you staff it?
The success of it was pretty much due to the support of my boss, who made sure I had the time and resources I needed to do it.
Was it formally adopted?
Yes, we eventually ran the company on it.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
What successful conversion/rewrite have you done of software you were involved with? What where the languages and framework involved in the process? How large was the software in question? Finally what is the top one or two thing you learned from being involved with the process.
This is related to this question
I'm going for "most abstruse" here:
Ported an 8080 simulator written in
FORTRAN 77 from a DECSystem-10 running TOPS-10 to an
IBM 4381 mainframe running VM/CMS.
I rewrote 20,000 lines of Perl to use "use strict" in every file. I had to add "my" everywhere it was needed and I had to fix the bugs that were uncovered during the process.
The biggest thing I learned from doing this is, "It always takes longer than you think."
I had to get it done all at once overnight so that the other coders would not be writing new, unfixed code at the same time. I thought it would go quickly, but it didn't, and I was still hacking on it at 6 AM the next morning.
I did get it complete and checked in before everyone else started work though!
I rewrote a large java web application to an ASP.Net application for a realty company for various reasons.
The biggest thing I learned is that, no matter how trivial the feature the original system had, if it's not in the second system, the client thinks the rewrite is a failure. Expectation management is everything when writing the new system.
This is the biggest reason rewrites are so hard: it seems so easy to the client ("Just re-do what I already have and add a few things.").
The coolest one for me, I think, was the port of MAME to the iPod. It was a great learning experience with embedded hardware, and I got to work with a lot of great people. Official site.
I am doing a rewrite of an Inhouse Project managment system to a more standard MVC model. Its in the LAMP stack (PHP) and i am close to the 1st milestone.
The things i have learned from that currently is how simple the program feels at the beginning and i tried to not add complexity until i have to.
Example is that i programmed all the functionality first (like i was an admin user) and then when that is sorted out, add the complexity of having restrictions (user levels etc)
I ported/redesigned/rewrote a 30,000-line MS-DOS C++ program into a similar-length but much more fully-featured and usable Java Swing program.
I learned never to take another job involving C++ or Java.
I ported a client server Powerbuilder app, a couple of hundred screens worth, into an ASP.NET app (C#).
Due to performance and maintainability issues, I had over the previous year moved a ton of embedded SQL out of Powerbuilder scripts and into stored procedures.
Although this would make a lot of you wince, having a lot of business logic in the database, it mean the Powerbuilder app was relatively "light" and when we built the .Net front end, it could take advantage of the SQL codebase and have a lot of functionality already built and tested.
Not saying I'd recommend building apps that way, but it certainly worked to our advantage in this instance.
We had a code generation tool in our application framework that was used to read in text-based data files, About 20 other applications made use of it.
We wanted to make use of XML data files instead of structured text-based files. The original code was quite outdated and difficult to maintain. We replaced this tool by a combination of XSLT scripts and a utility library. For the utility library we could make use of some code in the old tool.
The result was that all 20 applications could now make use of either the obsolete text based file format or the new XML based format. We also delivered a conversion-generation tool that converted old data files to new XML data files.
After bringing out one or two release we have now decided that we will no longer support the old text based format and everybody is able to convert their data to XML.
We did hardly have to do manual conversions,
Converted the main company app from pre-standard C++ to standard C++. We had a multimillion dollar sale contingent on making it work on AIX, and after looking at it we decided that converting to standard C++ was going to be just as easy as converting to IBM's traditional C++.
I don't know the line count, but the source code ran to hundreds of megabytes.
We used standard Unix tools to do this, including vi and the assorted compilers.
It took a few months. Most of the fixes were simple ones, caught by the compiler and almost mechanically fixed. Some of them were much more complicated.
I think my main takeaway was: Don't get too awfully clever with code in a language that hasn't been standardized yet, or is likely to have things change in unexpected ways. We had to do a lot of digging in some of the ingenious adaptations/abuses of C++ streams.
Ten years ago I managed a team that converted a CAD system from DOS into Windows. The DOS version used home-brew libraries for graphics drawing, the Windows version used MFC. The software was about 70.000 lines of C code at the time of the conversion. The most important thing we learned in the process is the power of abstraction. All device-specific non-portable routines were isolated in a few files. It was therefore relatively easy to substitute the calls to the DOS-based library that would draw by directly accessing the frame buffer with Windows API calls. Similarly, for input we just substituted the event loop that checked for keyboard and mouse events, with the corresponding Windows event loop. We continued our policy of isolating the non-portable (this time Windows) code from the rest of the system, but we have not yet found this particularly useful. Perhaps one day we will port the system to Mac OS X and be thankful again.
Several. But I mention one.
It was a performance modeling tool. Part delphi 1, part turbo pascal. It needed a rewrite else it was not going to survive. So we started as a team of 2, but only me survived to the end. And I was ready before the deadline ;-).
Several things we did:
Make it multimodel. The original had lots of globals. I removed them all and multi model was easy to adapt.
Extended error messages. Click on a message and get the help.
Lots of graphs and diagrams. All clickable to drill down.
Simulation. Change parameters over time and see how long the current configuration was enough.
We really made this one clean and it paid back heavily in the end. Such a big learning experience.
Re-wrote a system for a company that processes legal invoices - the original system was a VB monstrosity that had no idea of good OO principles - everything was mixed together. The HTML did SQL, and the SQL wrote HTML. A large part of it was a custom rules engine that used something like XML for the rules.
Two teams did the re-write, which took about 9 months. One team did the web front end and the backend workflow, while the other team (that I was on) re-wrote the rules engine. The new system was written in C#, and was done test-first. Adding new rules to the system when we were done was dirt simple, and it was all testable. Along the way we did things like convert the company from VSS to SVN, implement continuous integration, automate the deployment, and teach the other developers how to do TDD and other Scrum/XP practices.
Managing expectations was crucial through the project. Having a customer that was savvy about software was very helpful.
Having a mix of large scale (end-to-end) tests along with comprehensive unit and integration tests helped tons.
Converted vBulletin which is written in PHP into C#/Asp.NET. I'm pretty familiar with both languages, but PHP is the hands down the winner for building that software. The biggest pain in the rear was needing to do a C# equivalent of PHP's eval() for calling the templates.
It was my first challenge in trying to do a conversion. I learned that I need more experience with C# and that writing it from scratch is just the easier route sometimes.
I converted a dynamical build-process completely written in Perl to a C#/.Net solution using a workflow-engine a co-worker had developed (which was still in beta - so I had to do some refinements). That gave me the oppertunity to add fail-safe and fail-over functionality to the build process.
Before you ask - no - the microsoft workflow-foundation could not be used since you cannot dynamically change a process during its runtime.
What I learned:
to hate the Perl-developer
process-optimization using a wf-engine
fail-safe and fail-over strategies
some C# tweaks ;)
In the end it covered about 5k - 6k (including the wf-engine) LoC origin from 3 200 LoC Perl-files. But it was fun - and far better in the end ;)
Converting theoretically portable C code into theoretically portable C code across architectures to support a hardware change that saves the company X dollars per unit.
The size varies - this is a common need, and I've done small and large projects.
I learned to write more portable C code. Elegance is great, but when it comes right down to it the compiler takes care of performance, and the code should be as simple and portable as possible.
Ported a simulation written in Fortran 77 (despite being written in the 90s) to C/Java because the original only worked on small data sets. I learned to love big O notation after several times of explaining why just moving the entire data table into memory at the start of the program was not going to scale.
Migrating the B-2 Stealth Bomber mission software from JOVIAL to C. 100% fully automated conversion. Seriously!
Main lesson: using configurable automated conversion tools is a huge win.
See DMS Software Reengineering Toolkit.