Solo developer rant

[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:

[A_WoodApple]

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)

[crazedDotNetDev]

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

[Lost User]

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.