Solo developer rant

[Mycroft Holmes]

As with everyone else, break it down to small deliverables, agree with the client what is going to be the focus of stage 1 and don't deviate. When some pillock comes up with a this would be nice/must have the first question should be is it in stage 1 if not then piss off. Make em write out their requirements/requests/wish list, don't allow them to simply bend your ear and get away with "but I discussed it with you". Writing it down also makes them think about the requirements in much greater detail. Show this thread to the boss, if he is at all reasonable this will establish that you are serious about solving their problem, not just making a buck. That attitude is essential to anyone in your line of work, been there do that!

Never underestimate the power of human stupidity RAH

[GuyThiebaut]

If you plan on sticking with what you are doing here is a suggestion: I have found myself in a similar position on a couple of occasions and the one thing that has helped me was to isolate myself from all work and queries not related to the project for a week. If you can get a room for yourself where you can have the code printed out and sprawled across the floor or a big desk that will help. Then you can concentrate on understanding the current problems and planning on how to refactor rewrite or fix them. It can take a bit to convince management of the value of having this isolation and in my experience taking myself off for a week to do this has helped on two occasions when I found myself getting interrupted or going around in circles trying to understand and fix an issue. Good luck with whatever you decide to do :)

“That which can be asserted without evidence, can be dismissed without evidence.”

― Christopher Hitchens

[Marc Clifton]

I see this all the time. A few years ago I was contracted by a company to convert their Clarion application to .NET. The inhouse devs were all Clarion programmers with no knowledge of the .NET framework and no knowledge of any .NET language. The database was non-normalized, and even worse, fields like (I'm making one up, but you get the idea) "sky_color" that obviously mean one thing had been hijacked to "season of the year" because "sky color" became obsolete and it was too nasty to go back into the Clarion code and fix it and the database, so instead of the label in app for "sky color" was changed to "season." The business logic was smeared across Clarion client code and PL/SQL, and, for an app that was responsible for records management of local and state government services, none of the business logic that had evolved over the years was documented. Oh, and I did mention that no one was using source control, so you could even see the evolution of the work? And it was a huge application with hundreds of screens and tables. And that was one app, which "integrated" via the data it manipulated with other apps. When I did an estimate (and a very optimistic one at that) of how long it would take to simply get a baseline document of "what and how" (gleaning the why was an impossible task) of the existing application, no new code, simply documenting what the current app did, I came up with a 3-5 man-year estimate. Actually, I didn't come up with the estimate, I led the senior management through the process. Quite simple actually: Q: "So, how many forms do you have?" A: X Q: (to devs): "So, how long do you think you need to document what this form is doing?" A: Oh, about a week for each form. Conclusion: "So, you're telling me it will take X weeks to simply baseline this product?" Result: Shocked looks by management. But the answers came from their own employees!!! And they never bothered to ask those questions until I came along. Then of course, was the realization that they couldn't normalize the database because of the interdependencies with other apps. So the idea of a "data bridge" was proposed, which would shuffle data automatically between the legacy DB instance and a normalized DB instance. That concept didn't even manage to taxi onto the runway, let alone take off, before... ...the whole project was killed, the company bought an upstart competitor (including their dev team) for a couple million dollars. Who knows where they are now? So, I hear your pain. As others

[H Brydon]

In my analysis, this is a perfect project to implement using Agile methods. Some of the most important features: - Involve the stakeholder continuously, and hold daily scrum meetings. - Look at the feature/bug list and completely fix/implement a bug/feature before moving on to the next. Don't try to fix everything at once and release a year later. You might get whacked in a month. - With an uncertain/unsophisticated stakeholder, the feature creep will be massive. This is what Agile was made for. - Continually produce and maintain the product in a constantly shippable state. You will get job security and better job satisfaction doing this.

-- Harvey

[Gideon A Brits]

"I am confident I can get the application done for them and have it perform well but not in the time allowed" You need to clearly communicate this. If your initial time estimate was wrong then apologize and move along. You are the supposed expert. As such do not ask, tell. '"it would be great if we could do that", blah, blah, blah'. Tell them they can have it but this will move the time frame by a month. Give them clear options, eg, we can do X but the outcomes would be Y and Z. Alternatively we can do A with outcomes Y and Q. Clear communication is the key here. If you are getting bullsh*t requirements then say so. Insist on getting the basic application functioning well first and then add additional features. Have a clear plan on how you are going to build the application and then stick to your guns. Simply point out that them controlling the development process did not work out previously and if they are going to keep on making changes and breathing down your neck for unrealistic deadlines this attempt will go the same way as the others. "Complex requirements and convoluted business logic that are difficult to provide a nice solution for." You can not cry about this one :-) To reduce this to simple logic is your job as the developer. If you can not do this then you are the 'code monkey' and need to get hold of a developer. Harsh, but true.

Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction. ~ Albert Einstein

[Fran Porretto]

Well, I can give you a hybrid horror / triumph story.

In early 1990, I was slapped with a task I'd have changed my name and gotten facial surgery to avoid. That I not bore anyone with unnecessary details, here's a summary:

• It involved an exotic communications device developed by another shop;
• The device was engineered to go into the backplane of a DEC VAX 8650;
• It was a microprogrammed device with three semi-cooperating processors;
• The documentation was exceedingly sketchy;
• It came with a primitive microassembler, a rudimentary microprogram, and no debugging tools;
• It was my mission (and I had no choice about accepting it) to interface that device to VAX/VMS, to write both a device driver and a proper microprogram for it, and to equip it with an API that would serve the needs of a legacy 80,000 line C program.

Inasmuch as there was no one else even remotely qualified to do that sort of work, I shrugged and bent to it. I assumed, as I was being given no help, no requirements, and no guidance apart from "make it all play together," that I would be left alone to do the job in some approximation of peace.

I was wrong. Boyoboyoboy, was I wrong.

The worst trial an engineer trying to concentrate can face is the demand for "status." Management above my head wanted daily status reports. That's right: daily. Mostly I was able to fend off my tormentors with a growl and an "I'm working on it," but now and then they'd press me for details. Early on, I developed an aversive tactic: I'd actually give them details: low-level technical details. Eventually, they realized that they hadn't a hope in hell of understanding what I was telling them, and the demands for "status" faded to nothing.

Then came the twin tortures of "We need it to do this" and "When do you think you'll be finished?" No one likes requirements changes in-stream, and as I'd received essentially no requirements up front, I resented them more than usual. But worse were the requests, eventually rising to demands, for a firm completion date.

As it developed, that legacy C program needed a lot of re-engineering, and it was as badly documented as my nightmare device. So the job expanded to embrace that item, as well...and I was still entirely on my own, without any assistance of any sort.

About eight months after the inception of the project, I was able to release a package of all the aforementioned items, tailored to work together as if they'd be

[3n1g]

Oh man I know this feeling all too well. Besides a few details, this is my latest job right here. The first you need to do is build up user confidence, it makes life A LOT more easy for you, as they are more patient for the results because they will know you deliver, and not yell death at the first sign of trouble. Also, release early, release often. Even if it's not 100% perfect, if it's usable without messing up something else, then show it to the users. It gives them something that they can see and play around, while it gives you the time to finish and perfect it while they are playing with it.

[DarioDiaz]

Apart from the other valuable advices that you have received, be sure of being calm down when deciding what to do. Everybody has days when a project seems more than we can manage and the future looks darker that it is in fact. You seem to be having one of that days So, that days it is better to walf for a walk or something similar, and free your mind. Next day sit in from of the project specificactions, cut them down to achievable parts and create a realistic schedule. Remember, sometimes things look better with the light of a new day :)

[EinA]

Been going 5 years on an upgrading project I estimated as 3 months - talk about feature creep! As part owner of the company I have job security but hardly get any real time to work on the project as I am always called to do other things. Tried getting another programmer but that didn't work out. Tried subcontracting but that didn't work out. I can really sympathize with your items 2, 4 and 6 - I am now just concentrating on the parts of the system that the clients use most and will get to the rest one of these days.

[Stephen Dycus]

1 & 2 : Looks like you've got some work to do. Try not to freak out and just focus on what they *really* want for a workable prototype (they want everything done; you need to decide what's critical.) 3 : Prioritize the list. Work on getting a solid prototype out first, cutting features that the buggy version may have already had. All they are going to care about is seeing progress. If you don't have *something* to show them every now and then, due to you trying to tackle the whole project at once, then they are going to wonder if you're doing anything at all. 4 : This is why you need to have *something* to show him. He doesn't understand the scope or complexity of what you're doing so try to appease him by showing off what you have working and explain how it's *better* than the previous version (in simple terms; ex. "Fixed some bugs, it's a lot faster, and look at this new feature.") 5 : That's programming though, solving problems. Research the business til you understand it or you'll never be able to provide a decent solution. Find someone nice in the company to explain it to you if you can. 6 : We're here, you also have stack overflow, or you could make a blog and try to get people collaborating in the comments. Obviously, not everything you do can be shared outside the company, but if you abstract the problem, then you should be fine.

[John McKay]

Hah legacy Access applications seem to be everywhere, my last job was eerily similar, I feel your pain! Good luck!

[Gary Huck]

Many of us have had similar experiences; seems to often come with the work. I could tell you horror stories but I don't think it will make you feel better :) Can you break apart some piece[s] and dole that out to another coder to meet deadlines? You have my sympathy esp on #4 ...

[Stephen Dycus]

+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. :)

[agolddog]

Understand that the previous developers' inabilities have nothing to do with you. The manager looks at your promises and sees them two months behind. Period, full stop. He/she doesn't care about what happened in the past with anybody else; you've said you could do this much in some time frame and didn't. I think it's fair for you to go to them with reasons why things are getting behind; it sounds as if it's a huge, complex project with many layers to peel back. Tell them what you've uncovered by digging into the application, have a plan of action for fixing it, and discuss a re-schedule. And, as others have pointed out, bite off smaller chunks which give you a deliverable every once in a while. I've found the "continuous stream of candy" keep sthe business people engaged and interested in a long-term project much better than the "we'll go away for X months and drop something on you at that time." Best of luck. I bet you'll look back on this (assuming some level of success) and be glad you went through it, with your improved skills on analyzing others' code and refactoring into something useful.

[ptmaker]

As many other developers here have said.. We feel your pain, been there.. That being said a few things. - Be credible.. Don't promise things you cannot deliver. If you don't think demands can be met in the timeline you must tell them. Don't let fear cloud your judgement. - Demo "something". Let them know they are getting something in return other than another failure. The manager clearly has no experience with this type of project management and you will have to find a way to manage the project while making it transparent that progress is being made. - Accept some of the painful truths and move on. The longer you stew on them the more stressed you will make yourself and the less productive you will be. (I have had several projects where I thought the end would never come and when it did it would be a massive failure. Once I got a foothold in those projects it turned out to not be so bad and I learned massive amounts from them). - As others have stated there are many groups on the web (as you have found here) to get some support. Something else you might consider is to search for user groups in your area that meet. I have joined a few and it is nice to get opinions of developers who work on completely different systems and learn some new things along the way. Don't let this project consume you. Wish you good luck in your project. Hope you find your foothold.

[Slow Eddie]

I have been working as a solo developer for 10 years or so. I think your mistake was in failing to get a written job specification that clearly delineated what you are contracting to do. I ALWAYS explain project creep to the client and include a clause in the agreement that it will cost extra and take longer. Having said that I realize that hindsight is 20-20. So, do the best you can, say "No" any time project creep tries to set in, and learn from the experience. Do not be afraid to buy and use tools. If you are going from Access to SQL server I would recommend CodeSmith tools.:cool: Finally, the fact that the client had been through so many other developers and attempts should have been a hint that they have unrealistic expectations and would be difficult to work with... Sometimes the best thing to do is to turn the job down.

Whatever doesn't kill you will only make you stronger...

[StatementTerminator]

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

[SeattleC]

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.

[RafagaX]

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...

[DarioDiaz]

You went throught the tunnel and now you are a better professional! :thumbsup: