Solo developer rant
-
I'm working as a solo developer for a small/medium business and I need to have a rant. I've been at the company for 5 months or so. A little background first, the company's original in-house application was built using MS Access and it was decided to replace it a number of years ago. Attempt 1: Someone was contracted to rewrite the application and to my knowledge it wasn't going well and the company decided to end or not extend the contract and the application was left unfinished with no source code available. Attempt 2: Another developer was contracted later and had previously developed similar software that was to be leveraged and customised for the company. 3 years later (after 1 year estimation) a buggy, horribly unperformant, partially complete application was delivered. Company decides to not continue any longer with contractors. Attempt 3: I come in and inherit buggy mess from Attempt 2. Originally on the assumption I was to complete Attempt 2 and add some features but I find out that a lot of the source code has not been provided because it was previous contractors IP and that the source code I have is a mess. I ask company do they want to continue with the application as is or rip out what I can and repackage it into the long awaited application. We decide to rip it apart to remove the dependency on a closed source poorly supported code base. So I have been contracted for a year to do this and have to deal with: 1. Maintaining compatible UI "feel" and data from original Access legacy application which has poor data integrity and in need of normalisation. 2. Trying to pull code from Attempt #2. 3. A huge feature list and constant feedback like from users like "we really need this" or "it would be great if we could do that", blah, blah, blah. 4. A manager with no understanding of software development or even computers breathing down my neck. 5. Complex requirements and convoluted business logic that are difficult to provide a nice solution for. 6. No other developer to bounce ideas off or cry on their shoulder. :(( I'm losing motivation fast. It is becoming such a huge task and it has been very difficult for me to provide delivery estimates given the legacy system and data, failed attempts, tight time frame and requirements communication. At the start I was too optimistic and was dealing with too many unknowns and now I'm behind on where I want to be, I know that, they know that and I get the feeling they are getting ready to cut me off as well. When I started I could see the w
I've been in similar situations, it's not fun. Given their experiences with this project so far, management is not going to be inclined to cut much slack and are likely skeptical of anything a programmer tells them. That's not your fault, but it's your problem. You walked into an unfair situation, you need to recognize that, and try to deal with it instead of getting upset about it. Another thing you need to realize is that the problem is likely not all on the programming side. If management has gone through two programmers already and have virtually nothing to show for it, then there are likely problems on the management end. It probably isn't just that the other programmers were unable to do the job, it's likely that management was standing in the way in some fashion. Look for warning signs: are requirements changed frequently, almost on a whim? Do senior managers helicopter in and throw out some ill-informed decisions based on superficial knowledge of what is going on, and then fly away? Are requirements such as business logic delivered in a timely and accurate manner? Important: do they really understand how the application works or should work (that's not a given)? Of course, when challenged on progress you can't tell management that it's them not you, even if you can clearly see that's the case. You're going to have to deal with the problem in a diplomatic way, and the key to this is communication. Be very clear and honest with management about where things are and what the challenges are and what a realistic timetable looks like. DO NOT agree to unrealistic timelines to appease impatient managers, you will be held to them. Give them the bad news about how long it's going to take, be sure to be realistic and pad some time for the usual unforeseen issues. They won't like hearing it, but they may at least be inclined to believe you about the challenges because they'll know you aren't just blowing smoke. They're likely tired of hearing programmers make promises that aren't kept, be honest and do it NOW, before it's a crisis. You're the third programmer they've brought in and they should be smart enough to know that they can't keep doing that and need to work with you to get the project to completion. If communication doesn't bring management around to seeing the situation that you're in and accepting how long the project is going to take to do well, start planning an exit strategy, it's not going to end well. If they listen to you, keep up the communication about what's going on
-
Would love to do that right now, but I'm broke, need to tough it out and see if things improve.
In that case, you have a year (7 months more) of drawing a salary before you have to admit that you bit off too much. That should be enough time to find your next gig. Seriously, the company obviously doesn't know diddly about managing a software project, since they've already failed 3 times (original and 2 contracts). You could give them an honest estimate of the project cost and schedule, but they'll probably cancel once they know it costs money to have good software. After all, three people (including yourself) have come in and told the company they can do the job for little money. They just couldn't deliver. Guess which part of that they remember. It seems clear that the company also has no clear idea what they want the software to do, so even if by some herculean feat you delivered, they'd probably not be satisfied. You can simulate progress by building the UI components first. With luck, seeing the UI will generate so much contraversy in the company that you can blame change orders for the failure to meet schedule goals. Consultants manage their contracts this way all the time, stretching the contract out until they have enough time to deliver the underlying functionality they originally promised. If you're a good talker, maybe you can help them see why the project is going to cost more and take longer than you promised and they wished. But if you didn't start off managing expectations, that may be hard now. You're going to have to decide, do I want a paycheck or do I want my professional pride. Doing the "right thing" will get the project cancelled. Doing the consultant thing may eventually result in getting the project completed, but it will be over budget and late, and there will be hard feelings. Either way it's going to be not-so-fun.
-
I'm working as a solo developer for a small/medium business and I need to have a rant. I've been at the company for 5 months or so. A little background first, the company's original in-house application was built using MS Access and it was decided to replace it a number of years ago. Attempt 1: Someone was contracted to rewrite the application and to my knowledge it wasn't going well and the company decided to end or not extend the contract and the application was left unfinished with no source code available. Attempt 2: Another developer was contracted later and had previously developed similar software that was to be leveraged and customised for the company. 3 years later (after 1 year estimation) a buggy, horribly unperformant, partially complete application was delivered. Company decides to not continue any longer with contractors. Attempt 3: I come in and inherit buggy mess from Attempt 2. Originally on the assumption I was to complete Attempt 2 and add some features but I find out that a lot of the source code has not been provided because it was previous contractors IP and that the source code I have is a mess. I ask company do they want to continue with the application as is or rip out what I can and repackage it into the long awaited application. We decide to rip it apart to remove the dependency on a closed source poorly supported code base. So I have been contracted for a year to do this and have to deal with: 1. Maintaining compatible UI "feel" and data from original Access legacy application which has poor data integrity and in need of normalisation. 2. Trying to pull code from Attempt #2. 3. A huge feature list and constant feedback like from users like "we really need this" or "it would be great if we could do that", blah, blah, blah. 4. A manager with no understanding of software development or even computers breathing down my neck. 5. Complex requirements and convoluted business logic that are difficult to provide a nice solution for. 6. No other developer to bounce ideas off or cry on their shoulder. :(( I'm losing motivation fast. It is becoming such a huge task and it has been very difficult for me to provide delivery estimates given the legacy system and data, failed attempts, tight time frame and requirements communication. At the start I was too optimistic and was dealing with too many unknowns and now I'm behind on where I want to be, I know that, they know that and I get the feeling they are getting ready to cut me off as well. When I started I could see the w
Well, if the previous two developers weren't able to finish this thing in a year, I highly doubt that you can (not because you're incompetent, but because probably is a unreasonable timeframe for this project), that should have been a warning sign. Anyway as you're already in the wolf's mouth, the best you can do is: 1.- Break the project apart in small projects with timely deriverables (say a deliverable in a month). 2.- Be open with your manager, and any upper manager that have a stake on this project, about delivery times. 3.- Calculate your times with enough padding so you can workout any trouble you find, also by the time you deliver them something, you should be already working in the next feature/subproject 4.- If anyone ask you for a change, be sure that you give them a realistic timeframe, and if they want it now, tell them that either you can't deliver, or that this will push the timeframe, be sure that any change is asked in written form (even email does it), never ever agree verbally with anyone about a feature or timeframe. 5.- Stick to your guns, this may seem rude, but if you bend to their will you will be hopelessly lost. My two cents.
CEO at: - Rafaga Systems - Para Facturas - Modern Components for the moment...
-
+1 Completely agree. My first day at my current job was my first day as a software developer (at least professionally.) I had to start a project entirely from scratch, by my self, using some technology I didn't even know at the time, and try to keep up with the other platform's team that had 2 developers, one of which worked at fidelity for 20+ years, with a head-start and a similar project to pull code from.... I was panicing for a little over a month. XD Eventually I calmed down and took it one feature at a time, focusing on small tasks instead of stressing the bigger picture. It's now a solid product. :)
-
I'm working as a solo developer for a small/medium business and I need to have a rant. I've been at the company for 5 months or so. A little background first, the company's original in-house application was built using MS Access and it was decided to replace it a number of years ago. Attempt 1: Someone was contracted to rewrite the application and to my knowledge it wasn't going well and the company decided to end or not extend the contract and the application was left unfinished with no source code available. Attempt 2: Another developer was contracted later and had previously developed similar software that was to be leveraged and customised for the company. 3 years later (after 1 year estimation) a buggy, horribly unperformant, partially complete application was delivered. Company decides to not continue any longer with contractors. Attempt 3: I come in and inherit buggy mess from Attempt 2. Originally on the assumption I was to complete Attempt 2 and add some features but I find out that a lot of the source code has not been provided because it was previous contractors IP and that the source code I have is a mess. I ask company do they want to continue with the application as is or rip out what I can and repackage it into the long awaited application. We decide to rip it apart to remove the dependency on a closed source poorly supported code base. So I have been contracted for a year to do this and have to deal with: 1. Maintaining compatible UI "feel" and data from original Access legacy application which has poor data integrity and in need of normalisation. 2. Trying to pull code from Attempt #2. 3. A huge feature list and constant feedback like from users like "we really need this" or "it would be great if we could do that", blah, blah, blah. 4. A manager with no understanding of software development or even computers breathing down my neck. 5. Complex requirements and convoluted business logic that are difficult to provide a nice solution for. 6. No other developer to bounce ideas off or cry on their shoulder. :(( I'm losing motivation fast. It is becoming such a huge task and it has been very difficult for me to provide delivery estimates given the legacy system and data, failed attempts, tight time frame and requirements communication. At the start I was too optimistic and was dealing with too many unknowns and now I'm behind on where I want to be, I know that, they know that and I get the feeling they are getting ready to cut me off as well. When I started I could see the w
Welcome to the world of in-house development. (Where I have been most of the last 15 years) Replacing something built with Access? :wtf: (Not sure I have seen anything nice done this way.) How big is the user base? <50 ? <100 ? What Environment does it run in? (Local network only?) I am guessing that what the company wants is really a "solution" and could care less if it's really an "application" or not. You may look at Filemaker Pro. It may do what you need it to. I am certain you could put together a useable system in < 3 months. It has some drawbacks, like having to buy a server app, server to run it on, and lics for all workstations using it. (and one copy of the advanced version so you can develop the solution.) It also does not scale incredibility well or handle truly HUGE data sets but is often more than adequate for small to mid size companies. It allows for rapid development of both the data structure and the user interface. In many ways Filemaker Pro is incredible and I can produce a solution in hours what would take others days/weeks/months. The result is a "solution" not an "application". (not something you can put on a disk and sell as an application... well, are limited ways but not really useful)
-
Would love to do that right now, but I'm broke, need to tough it out and see if things improve.
I partly agree with both Maxxx and SeattleC++. I’ve bounce in and out of team settings, but lately I’ve preferred coding solo. I’ve absolutely been on these kinds of death march projects. I’ve misestimated while clueless managers micro-manage. It’s not fun. I’ll only add a few pointers. 1. GET SLEEP and eat as healthy as you can. This isn’t always obvious, but will be devastating if you don’t. Experience: I once coded for 24+ hours… this doesn’t include the 1.5 hour drive to/from the client. I actually spend something like 16 hours coding and 8 hours fixing a single mistake. 2. Give yourself too many options. Always keep an updated resume and actively talk to head-hunters even if you’re not looking for a job. You’ll sleep better at night. 3. Divide and conquer the code. If possible, get into a very small push cycle. My last solo gig I setup a weekly promotion cycle where I pushed a useable feature to production at the end of every week. Monday rolled around and I sat with my manager/users to see what was important that week and started coding. This also has the benefit allowing users to see progress. Go with the saying “high performance covers a multitude of sins.” Show your performance through a steady stream of new features. 4. It sounds very much like management has become dejected with developers. Unfortunately that happens when they’ve been burned too many times. Not all battles can be won. It might be that this job is too big to do solo, yet they are unwilling to hire more coders or extend deadlines. More pain might be unavoidable… for them and you. Life sucks sometimes, so build yourself the career equivalent of a bomb shelter.
- great coders make code look easy
-
I'm working as a solo developer for a small/medium business and I need to have a rant. I've been at the company for 5 months or so. A little background first, the company's original in-house application was built using MS Access and it was decided to replace it a number of years ago. Attempt 1: Someone was contracted to rewrite the application and to my knowledge it wasn't going well and the company decided to end or not extend the contract and the application was left unfinished with no source code available. Attempt 2: Another developer was contracted later and had previously developed similar software that was to be leveraged and customised for the company. 3 years later (after 1 year estimation) a buggy, horribly unperformant, partially complete application was delivered. Company decides to not continue any longer with contractors. Attempt 3: I come in and inherit buggy mess from Attempt 2. Originally on the assumption I was to complete Attempt 2 and add some features but I find out that a lot of the source code has not been provided because it was previous contractors IP and that the source code I have is a mess. I ask company do they want to continue with the application as is or rip out what I can and repackage it into the long awaited application. We decide to rip it apart to remove the dependency on a closed source poorly supported code base. So I have been contracted for a year to do this and have to deal with: 1. Maintaining compatible UI "feel" and data from original Access legacy application which has poor data integrity and in need of normalisation. 2. Trying to pull code from Attempt #2. 3. A huge feature list and constant feedback like from users like "we really need this" or "it would be great if we could do that", blah, blah, blah. 4. A manager with no understanding of software development or even computers breathing down my neck. 5. Complex requirements and convoluted business logic that are difficult to provide a nice solution for. 6. No other developer to bounce ideas off or cry on their shoulder. :(( I'm losing motivation fast. It is becoming such a huge task and it has been very difficult for me to provide delivery estimates given the legacy system and data, failed attempts, tight time frame and requirements communication. At the start I was too optimistic and was dealing with too many unknowns and now I'm behind on where I want to be, I know that, they know that and I get the feeling they are getting ready to cut me off as well. When I started I could see the w
Wow. This is my ideal situation: the one-man IT department. Ran with one for 7 years. Currently on one that is into year 3 (and "phase 2" - the cloud). The key is: "deliver fast and often". This means breaking the (original) problem into small and useful pieces that you can crank out in a few weeks; that the user can put to use immediately; and that keeps their interest and enthusiasm high and creates the all-important feedback cycle. If you can't produce something in a matter of weeks that the user can use (even if it's only a data entry screen or a report), then the problem is not being partitioned properly. (The "task" is not huge; the application may be "hugh", but individual tasks are or should be small and manageable). Once you gain their confidence, the work keeps coming.
-
I'm working as a solo developer for a small/medium business and I need to have a rant. I've been at the company for 5 months or so. A little background first, the company's original in-house application was built using MS Access and it was decided to replace it a number of years ago. Attempt 1: Someone was contracted to rewrite the application and to my knowledge it wasn't going well and the company decided to end or not extend the contract and the application was left unfinished with no source code available. Attempt 2: Another developer was contracted later and had previously developed similar software that was to be leveraged and customised for the company. 3 years later (after 1 year estimation) a buggy, horribly unperformant, partially complete application was delivered. Company decides to not continue any longer with contractors. Attempt 3: I come in and inherit buggy mess from Attempt 2. Originally on the assumption I was to complete Attempt 2 and add some features but I find out that a lot of the source code has not been provided because it was previous contractors IP and that the source code I have is a mess. I ask company do they want to continue with the application as is or rip out what I can and repackage it into the long awaited application. We decide to rip it apart to remove the dependency on a closed source poorly supported code base. So I have been contracted for a year to do this and have to deal with: 1. Maintaining compatible UI "feel" and data from original Access legacy application which has poor data integrity and in need of normalisation. 2. Trying to pull code from Attempt #2. 3. A huge feature list and constant feedback like from users like "we really need this" or "it would be great if we could do that", blah, blah, blah. 4. A manager with no understanding of software development or even computers breathing down my neck. 5. Complex requirements and convoluted business logic that are difficult to provide a nice solution for. 6. No other developer to bounce ideas off or cry on their shoulder. :(( I'm losing motivation fast. It is becoming such a huge task and it has been very difficult for me to provide delivery estimates given the legacy system and data, failed attempts, tight time frame and requirements communication. At the start I was too optimistic and was dealing with too many unknowns and now I'm behind on where I want to be, I know that, they know that and I get the feeling they are getting ready to cut me off as well. When I started I could see the w
What I usually do when I am approached (interviewed?) for jobs such as this is to make it clear up front that a certain amount of time will be necessary, a month or so, give or take a little, to become familiar with the problem. I usually tell them that this is will benefit both myself AND them, so that I have enough understanding of the problem to find a good solution, and so that I don't screw up what they already have. Businesses don't really like it when something unexpected happens to software that they use everyday (in your case, maybe it doesn't work too well, but that's another story). This includes reading all the code, becoming familiar with the database and how it is being used when you arrive on the scene, spending time with the people that use the stuff (you can usually learn more from them than anyone with the money in their pockets). But that's just me, and I learned that through hard knocks. I won't try to analyze your situation, but consider the following: Is it worth it to approach the manager/management/owner or whatever and admit that the problem is actually more difficult than imagined when you first encountered descriptions of it prior to or during the time that you were hired? This is not so unusual in situations such as yours. You've been there for five months. That should be enough time to have armed yourself with examples of code, database, and business models that require more effort than you (and, perhaps your predecessors) were lead to believe. Do you have good analytical skills that you can portray in simple English? Do your analytical skills include diagramming old systems (yes, reverse engineering, I suppose), with projections into possible new ways of doing things that would satisfy the business model as you see it? Pictures are an excellent way of removing fog with management, especially if you can walk managers through the problem, how you think previous attempts failed (and maybe even added more fog), and what the steps might be to get through the fog, see the trees in the swamp, and reach dry land. You've been there five months. Taking a few hours now to diagram what you have learned and how you see it resolve might be a good way to go. Delaying some sort of direct communication with management is never a good idea. The worst that can happen is that they will tell you to go away. The best - that they'll listen, especially if you can present the evidence in such a way that it plants a few seeds in their heads, which is always a useful goal. If they a
-
Well previous devs failed to deliver 3 years after first estimating 1 year, so hope I'm not here that long :~. Thing that irks me is that manager is on my case about running about 2 months behind when the previous guys never delivered anything of real value after 3 years. Good advice though I probably need to communicate this better.
I have worked under both good and bad managers, run my own shop and have been around the block a few times as well. :) One of the things I've learned over time is the power of a gantt chart. Sometimes the manager is also learning and the use of a tool like a gantt chart often provides an opportunity for both of you to reach an 'agreement of expectations'. If the gantt chart is reasonably accurate and the time necessary to complete the task is within reason, then the manager - having had regard to the gantt chart and knowing the constraints should be able to 'ease off a bit'... hopefully. But the point is, that you should consider breaking down each big task into smaller tasks and using a gantt chart 'map it out'. Provided each of you can reach a reasonable 'set of expectations' it can be dealt with. The gantt chart is of course only a tool 'used to find mutual expectations of delivery', there are other tools. Hope this helps.
M Hamilton
-
I'm working as a solo developer for a small/medium business and I need to have a rant. I've been at the company for 5 months or so. A little background first, the company's original in-house application was built using MS Access and it was decided to replace it a number of years ago. Attempt 1: Someone was contracted to rewrite the application and to my knowledge it wasn't going well and the company decided to end or not extend the contract and the application was left unfinished with no source code available. Attempt 2: Another developer was contracted later and had previously developed similar software that was to be leveraged and customised for the company. 3 years later (after 1 year estimation) a buggy, horribly unperformant, partially complete application was delivered. Company decides to not continue any longer with contractors. Attempt 3: I come in and inherit buggy mess from Attempt 2. Originally on the assumption I was to complete Attempt 2 and add some features but I find out that a lot of the source code has not been provided because it was previous contractors IP and that the source code I have is a mess. I ask company do they want to continue with the application as is or rip out what I can and repackage it into the long awaited application. We decide to rip it apart to remove the dependency on a closed source poorly supported code base. So I have been contracted for a year to do this and have to deal with: 1. Maintaining compatible UI "feel" and data from original Access legacy application which has poor data integrity and in need of normalisation. 2. Trying to pull code from Attempt #2. 3. A huge feature list and constant feedback like from users like "we really need this" or "it would be great if we could do that", blah, blah, blah. 4. A manager with no understanding of software development or even computers breathing down my neck. 5. Complex requirements and convoluted business logic that are difficult to provide a nice solution for. 6. No other developer to bounce ideas off or cry on their shoulder. :(( I'm losing motivation fast. It is becoming such a huge task and it has been very difficult for me to provide delivery estimates given the legacy system and data, failed attempts, tight time frame and requirements communication. At the start I was too optimistic and was dealing with too many unknowns and now I'm behind on where I want to be, I know that, they know that and I get the feeling they are getting ready to cut me off as well. When I started I could see the w
I have worked under both good and bad managers, run my own shop and have been around the block a few times as well. :) One of the things I've learned over time is the power of a gantt chart. Sometimes the manager is also learning and the use of a tool like the gantt chart often provides an opportunity for both of you to reach an 'agreement of expectations'. If the gantt chart is reasonably accurate and the time necessary to complete the task is within reason, then the manager - having had regard to the gantt chart and knowing the constraints should be able to 'ease off a bit'... hopefully. But the point is, that you should consider breaking down each big task into smaller tasks and using a gantt chart 'map it out'. Provided each of you can reach a reasonable 'set of expectations' it can be dealt with. The gantt chart is of course only a tool 'used to find mutual expectations of delivery', there are other tools. Hope this helps.
M Hamilton
-
I'm working as a solo developer for a small/medium business and I need to have a rant. I've been at the company for 5 months or so. A little background first, the company's original in-house application was built using MS Access and it was decided to replace it a number of years ago. Attempt 1: Someone was contracted to rewrite the application and to my knowledge it wasn't going well and the company decided to end or not extend the contract and the application was left unfinished with no source code available. Attempt 2: Another developer was contracted later and had previously developed similar software that was to be leveraged and customised for the company. 3 years later (after 1 year estimation) a buggy, horribly unperformant, partially complete application was delivered. Company decides to not continue any longer with contractors. Attempt 3: I come in and inherit buggy mess from Attempt 2. Originally on the assumption I was to complete Attempt 2 and add some features but I find out that a lot of the source code has not been provided because it was previous contractors IP and that the source code I have is a mess. I ask company do they want to continue with the application as is or rip out what I can and repackage it into the long awaited application. We decide to rip it apart to remove the dependency on a closed source poorly supported code base. So I have been contracted for a year to do this and have to deal with: 1. Maintaining compatible UI "feel" and data from original Access legacy application which has poor data integrity and in need of normalisation. 2. Trying to pull code from Attempt #2. 3. A huge feature list and constant feedback like from users like "we really need this" or "it would be great if we could do that", blah, blah, blah. 4. A manager with no understanding of software development or even computers breathing down my neck. 5. Complex requirements and convoluted business logic that are difficult to provide a nice solution for. 6. No other developer to bounce ideas off or cry on their shoulder. :(( I'm losing motivation fast. It is becoming such a huge task and it has been very difficult for me to provide delivery estimates given the legacy system and data, failed attempts, tight time frame and requirements communication. At the start I was too optimistic and was dealing with too many unknowns and now I'm behind on where I want to be, I know that, they know that and I get the feeling they are getting ready to cut me off as well. When I started I could see the w
When I was reading your story I could almost question: "Did I write this?". Seriously, I've been there and done that. It is very difficult to to work on a scenario with so much constraints, but there are ways to build your room of freedom. When you can't change the database that is a mess and have to stick with that old UI style, focus on business rules. In the realm of the Business Layer you are free. Focus on developing a beautiful 100% independent business rules layer. The business rules layer shouldn't know about UI or the database. When you get data, you translate the data into those beautifully crafted objects you designed. It will make your job a lot easier and it will help improve your estimates as you stumble into the troubles into translating data into objects. But don't go looking for a better job just yet. Actually I think this job is very good to teach you a number of lessons, including working in unfavorable environments, which you will often stumble into during your career. Having that experience is very important for your growth and will help you deal with similar stressful situations in the future. Hang in there and you will get off it stronger, learn to go until the end on even the most dreadful scenarios. One last tip: You need to agree with the requirements and freeze them (or at least get them close to freezing point) or else you will just go crazy. Develop a flexible business layer so it will be easily adaptable in the future. Create a list of wants (could simply be simple excel sheet of requirements) and sort them for future release and if they are simple enough you can do it in this first phase. You have to be clear to your stakeholders on this matter. You need to tell them that you need to focus on having the application migrated "as is" so later the new requirements and features have a better chance of success.
To alcohol! The cause of, and solution to, all of life's problems - Homer Simpson ---- Our heads are round so our thoughts can change direction - Francis Picabia
-
I'm working as a solo developer for a small/medium business and I need to have a rant. I've been at the company for 5 months or so. A little background first, the company's original in-house application was built using MS Access and it was decided to replace it a number of years ago. Attempt 1: Someone was contracted to rewrite the application and to my knowledge it wasn't going well and the company decided to end or not extend the contract and the application was left unfinished with no source code available. Attempt 2: Another developer was contracted later and had previously developed similar software that was to be leveraged and customised for the company. 3 years later (after 1 year estimation) a buggy, horribly unperformant, partially complete application was delivered. Company decides to not continue any longer with contractors. Attempt 3: I come in and inherit buggy mess from Attempt 2. Originally on the assumption I was to complete Attempt 2 and add some features but I find out that a lot of the source code has not been provided because it was previous contractors IP and that the source code I have is a mess. I ask company do they want to continue with the application as is or rip out what I can and repackage it into the long awaited application. We decide to rip it apart to remove the dependency on a closed source poorly supported code base. So I have been contracted for a year to do this and have to deal with: 1. Maintaining compatible UI "feel" and data from original Access legacy application which has poor data integrity and in need of normalisation. 2. Trying to pull code from Attempt #2. 3. A huge feature list and constant feedback like from users like "we really need this" or "it would be great if we could do that", blah, blah, blah. 4. A manager with no understanding of software development or even computers breathing down my neck. 5. Complex requirements and convoluted business logic that are difficult to provide a nice solution for. 6. No other developer to bounce ideas off or cry on their shoulder. :(( I'm losing motivation fast. It is becoming such a huge task and it has been very difficult for me to provide delivery estimates given the legacy system and data, failed attempts, tight time frame and requirements communication. At the start I was too optimistic and was dealing with too many unknowns and now I'm behind on where I want to be, I know that, they know that and I get the feeling they are getting ready to cut me off as well. When I started I could see the w
This is what caught my attention: A huge feature list and constant feedback like from users like "we really need this" or "it would be great if we could do that", blah, blah, blah. I would break-down their feature list into cost/time objects that I could honestly deliver within the time specified for each feature. Then, make a projection as to the completion date (giving some room for any unforeseen circumstances that would add time to completion). Present that to them and let them pick which of the objects they want to complete, they would already know how much time they would have to wait for deliverables. But the most important thing, I think is the scope creep. You have to make them understand that each feature will add time to the completion date (not to mention cost, as someone here posted, don't have their post visible at the moment). I did a website about 7 years ago where the scope was firm and the quote was based on the scope. But then, the whole purpose of the site changed and I agreed to stay on, but was expected to complete it within the same time as the original purpose along with the "constant feedback, 'we really need this' or 'it would be great if we could do that', blah, blah, blah.". As well as the many websites they would ask me to look at. Each week they would like the look of one website or another. I did however, complete the project and we still have a business relation. Thanks to my caving and giving them what they wanted. Was I ever glad to finish that one! That's when I decided to never cave or deviate from the initial scope/expectations and schedule without the mutual understanding that the impact would involve time and money.