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 know this may not be exactly a coder question, but I feel it is still related to programming because I'm sure many developers have come across this before and might have some insight on how to resolve this or have advice. There is an actually programming question though.
My issue as a developer.
I work in a small company, roughly 15 people, 5 of which are developers include myself, the rest are tech support and management. Problem I'm having is, when we get a SOW (Statement of Work), our clients give us a rough description of the project they are requesting, which usually is a 1-3 page brief description, usually including a Visio document, now as a programming, I'm responsible for going over the document and relaying a time-line on how long it should take me to complete the project.
Unfortunately, there have been times, not only me, where we under-estimate the project because we didn't fully get into it till we actually developed it, which ends up slapping ourselves in the face, because my boss is upset because he is being hounded by the client, who is now upset because we missed our promised deadline.
My question is, how do you guys handle organizing basic project description when you need to give deadlines on more concept, and do you have any ideas on how to organize it.
I'm thinking of going to my boss and suggesting, instead of always pushing a estimated deadline to our clients which expect us to hit that, we should write up a detailed document that is more step-by-step (more like what to do) on how to develop the application they want, it may take a lot more time, but least if the project is moved to someone else it is laid out for them, and when I usually get back to it 4 months later, I don't have to refresh up again, I can just follow the steps I wrote.
What do you guys think? Ideas? Or better ways to handle this?
If you switch your development to using an iterative methodology (Agile, XP, Scrum, etc), then the customer will see results much earlier than any deadline you feel you have to promise - usually every 1 or 2 weeks.
The moment they see what you've developed, I can pretty much guarantee that they'll make changes to their initial requirements as they now have a visual representation of the product and it may not be quite what they were thinking of. Some of their changes might be quite radical, so best to get the feedback as early as possible.
In all the projects where i've insisted we do this, the customer was delighted - they saw the results early, could influence the project outcome, and we hit their end deadline. Unexpectedly, a whole load of features got left behind and - guess what - the customer did not mind at all as they got the top features they wanted and put the project/product straight into production as they'd had lots of time to refine it to suit their business, so they were already familiar with it.
It takes a lot of effort to get management, sales, creative, etc, to all buy-in to an iterative style, so you may need to implement a hybrid solution int he mean time, but in my experience, it is well worth it.
If a complete shift to iterative is not possible, split your project into tangible milestones and deliver on those milestones. As others have said, inflate your estimates. My previous manager doubled my estimates and the sales team doubled his too.
Inflate your project deadlines. It's something that most programmers should do (and I quote the VP of Freeverse, the company that I work at):
It is a well-known fact among people
who work in the software industry that
the last 5% of development always takes the longest.
If possible try to divide the higher level tasks as much as possible so that you can get a better approximation of how many man hours that sub-task would take.
Also, adding hidden buffers to your task execution helps in covering some of the unseen contingencies.
cheers
If you mock up (balsamiq or whatever) with your customer, you will get more details. Armed with those details and some experience, your estimates will be more accurate. And then double it and add 4 (hours,days,weeks,months)
First, unless you systematically under-estimate, your boss should not get upset. It's his job to answer to the client, and he should know that by definition, an estimate is NOT the future. Statistically, sometimes you should deliver earlier, sometimes later.
Personally, I think that the frame of "how long will it take" is not exactly the right discussion to have. Software development is a risky business, and change/surprises happen all the time. One approach which helps is to focus less on the "right" number, and more on the volatility. Look at the project, and consider the places where you are pretty clear on how long it will take (you have done it before and understand it well), and look at the places where you have uncertainty (unclear requirements, new technology), and for these, think about how bad it could go, and why. That will help you get not one number, but rather boundaries: what you think is reasonable, a worst-case scenario, maybe a best case scenario (which the client should never see :) ) - and convey that information to your boss, so that he can manage accordingly.
Additionally, this will allow you to identify the danger points of the project, and you can then prototype accordingly - look into the uncertainty points as early as possible, so that you can tighten up the timeline fast, and have early warnings for your boss and the client.
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
If you are the lead programmer at a company and you need to complete a project that would require skills/knowledge that no one at the company currently has, what do you do?
I am not talking about something simple you can ask for help on stack-overflow for but for complex problems that you do not feel comfortable tackling and would take a significant amount of learning to be ready.
So at the point whats the best step to take?
Be honest with your management team, make sure they know. Don't ever try to mislead people about the scope of your knowledge - it doesn't impress them and only causes you problems.
Work with your team to evaluate your options - it may be possible to change technologies, or perhaps someone else in the organization can help mentor or support you. Changing course earlier on is easier and less expensive than later.
Adjust your project timeline to take into account the potential risk and delays caused by working beyond your core strengths. If you don't have enough knowledge to estimate the risk, be very conservative in the confidence factor of your estimates and timeline.
Look for an expert in the domain/technology and see if you can engage them either as a consultant or advisor on your project. Nothing makes a bigger difference than prior experience in a domain.
Take some time to try to create a simpe prototype or proof-of-concept in the domain/technology you will be working on. Look for possible issues that could emerge. Sometimes unexpected problems surface when you try to create a simple prototype - this can help steer the effort when working on the real thing.
See if the scope of your project can be scaled back. If you are already "behind the curve" the best way to improve your odds of success is tackling something smaller, rather than larger.
Seek out advise from people you trust. Especially people whose expertise and knowledge has some bearing on the problem or technology you're taking on. They may be able to give your more specific advise or ideas.
You have to take it outside the company to someone (person or consultancy) that can complete it. This means a contractor/consultant that will be with you for a temporary period of time. If possible have them work in house with your and your team and make part of their responsibility to train you.
You may have to explain to management that without this, the project could fail and will probably be late and over budget. Don't worry about outsourcing some projects - you and your team will still have lots of work.
Temporarily hire someone who has the expertise you're missing, and make sure they're prpared to transfer their knowledge to others in your team as well as work on the problem at hand. Be prepared to pay serious money; but if the problem really is complex, chances are you'd take much longer, get a much worse result, and pay more overall if you try to figure out out without any help.
First, +1 to Borgwardt, Oded, Bushkin. Great answers here. Now my two cents...
Your path forward should consider whether this is a skill/technology i.e. "capability" that your company needs to have internally. Depending on this, take the advice of either #Oded (Outsource) or #Michael Borgwardt (hire a contractor to do some knowledge transfer), or spend a lot of time (if you have it) and develop the capability on your own. For example, suppose you're going to interface with some purchased package that spits out magic numbers in some binary format. Hire a contractor to write the interface. Suppose your VP of fulfillment wants you to interface with a FedEx web service, and nobody at your company knows SOAP. And you know that more SOAP is coming, for all suppliers and partners. You'll need SOAP skills in-house, so get some training, do a prototype, and maybe bring in some outside help.
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 5 years ago.
Improve this question
We are a small team (3 developers) and one of our main clients is about to submit a bunch of new feature requests and a follow on project to us to get estimates on cost and delivery times. Our last project with them was a 'success' in that they are coming back to us but I know we could have done a much better job (we used waterfall... testing was an after thought and as a result unit-testing code coverage is significantly lower than we feel comfortable with, not to mention the never-ending 'we are ALMOST done' problem).
I have just finished reading 'Art of Unit Testing' and 'Working Effectively with Legacy Code' and I have used TDD on a pet project of mine outside of work and now I can never go back to waterfall and testing after the fact.
What I want to know is are there are good 'easy to digest' videos for non-developers that clearly show the benefits of TDD along with Agile practices in a business sense? I'd be super happy if there are any sub 10 minutes videos but I'm also OK with longer videos (and I will reference them to a time index in it). If there are no good videos then a written source is next best thing.
I want nothing more than for them to be on board and really excited with the transition.
For me it is not an option to 'just do it' as there will definitely be a learning curve for the other two developers and without doubt the first number of iterations may be stressful and bumpy and that needs to be communicated to our client.
[I have answered my own question below with a number of videos I found since asking the question... they are not perfect for my use but definately my plan B if no-one else knows of a better one]
Technical debt kills velocity. Thus, I like to include "No increased technical debt" in the Definition of Done. Without this, you can't achieve sustainable pace. This is illustrated by the picture below (borrowed from the Technical Debt - How not to ignore it presentation from Henrik Kniberg):
alt text http://img27.imageshack.us/img27/329/screenshotkq.png
To me, all these things are obvious and you can even prove it with numbers (by measuring the velocity over time). Explain these concepts to your client, explain him that TDD is one of the techniques allowing to control technical debt. Then, let him choose (or choose for him).
How you run your project internally is your business. Don't involve them in this decision. They are not experts in software development processes. Ask them about business requirements and things they know about.
Sound like you are doing this to improve project quality. Do you think it will cost more to do TDD? Why work to convince them of something and then ask their approval? Did you ask if you could do waterfall on the last project?
Why would your client even notice the transition to TDD? Stressful, bumpy; how so?
Tell the client why you are upgrading to TDD. I'm sure the reasons are as compelling to them as they are to you. To me, TDD first of all means a much greater sense of reliability on what you produce.
Surely your client remembers all the regressions and manual testing from your last project?
I don't know of any specific illustrations for you (the web is full of articles and blogs, but I'm not aware of any videos), but you pretty much answered your own question...
we used waterfall... testing was an after thought and as a result unit-testing code coverage is significantly lower than we feel comfortable with, not to mention the never-ending 'we are ALMOST done' problem
You just need to be honest with your client. Explain to them what the project methodology you used on your last project cost them in terms of flexibility, maintainability, and your ability to confidently provide them with quality code. Explain to them how TDD addresses that, and explain that you anticipate a slower start due to using a new methodology.
Illustrate for them, as concretely as possible, what they will gain, and it should be an easy sell. I would, however, approach it more from the "this is what we're planning on doing" angle, rather than the "can we please do this?" angle. Give them the impression (without being dishonest) that you are already planning on going this way and any change to that plan will be an inconvenience to you and your team, and will likely cost them productivity.
I'm not aware of any videos, but explain to them that it took you N man-hours to redesign a certain feature on the last project due to original design not being correct taht was not caught until you started testing; and with TDD it would take M (<<N) man-hours since you would not spend the extra hours working based on a bad design/bug as happened last time.
Also, explain that the confidence level of having less buggy software will be raised by Y percent due to thought-out tests.
Then explain you estimate X hours for learning curve on the FIRST peoject, and ask them if the given benefits on ALL future projects will be worth it, when the initial time investment is depreciated across those.
Firstly, unit testing isn't unique to Agile methodologies; I've been around a while and have seen it used on waterfall projects. In fact, I heard of unit testing long before I heard of Agile!
Afraid I can't point you to any videos that will help convince a client to switch development methodologies. Google may help though; if not with videos, then maybe with studies, blogs, etc.
Anyway, one suggestion for improving the chances that the client will accept your reduced productivity during your learning curve is to reduce his costs somehow. E.g. if you're billing by the hour either charge less by the hour for time spent learning, or just don't bill for those learning hours.
I spent the time since asking this question looking for the best videos I could and I've come across a number that are very close to what I need. I will post them here so that others will find them if they are in a similar position to me.
I realise that I asked more about TDD - but these videos capture a good portion of the message I'm trying to drive home... especially 'Why does Agile Software Development Pay' and 'Scrum in under 10 minutes'... it is the process of being responsive to change, producing higher quality code, having fewer defects and faster development cycles.
Agile vs waterfall: A Tale of Two Teams (8:20)
Why does Agile Software Development Pay? (5:03)
Scrum Basics (5:50)
Scrum in under 10 minutes (7:59)
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 8 years ago.
Improve this question
I was asked to make a clone of this: http://www.bragster.com/
Ok, not a clone per se, but a site with similar functionality on a lower budget! How low might one ask? Under 10K, probably under 5K.
My question: how do I explain to a non-tech savvy friend, that this is not possible, in the nicest terms, and convince them not to go to rentacoder.com and try to pay someone to not do it for them.
Has something like this ever happened to you, and how did you deal with it?
people never want to hear "that's impossible" especially entrepeneurial types, it just makes them more dogged. so just show them what -is- possible for their 10k and let them come to their own conclusion.
So, while drawing on other sites for inspiration is fine, "recreate X" is not a scope, it generally means the client hasn't thought it through. For a start, you don't know which parts of that site are really standing out to the client.
So sit down with them and plan it properly, get them to lay out what they want from the ground up, without resorting to "however bragster/youtube/ebay do it".
Just bullet point it, really quick and dirty. you'll then have an idea of the true scope.
i want slick design
i want video uploads
i want video streaming
i want comments
ratings
sharing
competitions
blog
store
leaderboards
etc. etc.
then you can throw some numbers next to each one, and watch them add up to over 10k. this will illustrate your point, and help your friend/client far better than "Trust me don't bother it's impossible"
Extending Kyle's answer a bit - maybe try an analogy for their business.
For example, if they're involved in construction, ask them whether it would be possible to create a 1km bridge spanning a river for $500k (no idea what the actual cost would be).
The difficulty with IT is obviously that it's an intangible thing. Make an analogy that's tangible.
Find a site that looks like it cost $5,000 and send your friend a link to it.
Everyone knows a good website takes six to eight weeks to develop.
I was an a similar situation. A friend pitched me a business idea for a social networking site. I asked her, "sounds fun, but how exactly is this going to be competitive with all the sites that have well-established userbases?"
Granted, I wasn't expecting a good answer to that question, so maybe it wasn't incredibly nice. Still, she thought about it, and twigged that the idea wasn't going to make any money, and that she had underestimated the difficulty of the undertaking. I didn't have to tell her so in any condescending, didactic sort of way, so I didn't feel like too much of a jerk about it.
Come up with several metaphors that point out how out of place you think the request is, and use them repeatedly until the point is made. Brute force attacks for the win!
In general, it is not advisable to do rough estimations because the result will be wrong. You would be under estimating because of a lot of things.
In this case (and just because you are certain the task is impossible given the cost requirement) you could do a rough estimation where you divide the project in specific tasks and maybe milestones with time and resources required for each. Give this estimation to your friend and tell him that is a first-approach/very-rough-estimate/very-risky-because-of-lack-of-a-formal-analysis.
Other posts here in SO may provide some guidance to you: https://stackoverflow.com/questions/tagged/estimation
Shall I forward all the horror stories I get from people who used services like rentacoder? Yikes.
We all know that if they go that route, it's roughly equivalent to throwing the $5000 in the shredder. Maybe you can suggest they find a partner to start the business with who can do the coding. If they get someone jazzed about it, and offer them equity, a) they're not out the $5000 and b) they have at least a chance of getting code that doesn't suck.
Here in the bay area, at least, there are any number of hackathons and meetups where developers looking for projects go. If the idea is good, and the person promoting it is sufficiently enthusiastic and personable, someone will be interested.
check Clipshare, http://www.clip-share.com/
you need to "setup" an ffmpeg or another engine to encode videos, flix or another you want in the server, but its pretty easy to setup in general and cheap also.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I often work with sales and marketing types that cannot figure out how to use Excel, let alone understand the scope of their requests from a technical perspective. Of course, it would not be fair to expect them to, but that still leaves me with a problem.
What is the best way to show marketing and sales types that they have asked for something that requires a lot of complex programming and some patience?
Could you please share examples of problems and solutions?
Could you please recommend books on this subject?
Thanks!
Break the problem up into as many sub-divided tasks as possible. Provide a per-item estimate in hours beside each one.
When they think of a project as a whole, it seems simple. However, when they see each individual thing that must be done and the number of hours each item will require, it is putting it into terms business people can understand. Suddenly the software solution they want isn't a "black box" to them anymore and they now have some insight into the process.
If you are looking for books I would suggest Software Estimation - Demystifying the Black Art.
The computer will do what you told it to do, not what you want it to do.
Any form of abstractions needed be translated to exact details.
source http://c2.com/cgi/wiki?TeachMeToSmoke
Teacher: "It's hard to express ourselves clearly. You're a smoker, right?
Are you pretty good at it? [Student nods.]
Let's pretend I'm a man from Mars and you are going to teach me to smoke.
Do you have a fresh pack? Let's start with that.
[Takes pack.] OK, now tell me what to do."
Student: "Tear open the pack."
T: [Tears pack to shreds. Cigarettes fly everywhere.]
S: "No, no, tear off the top of the pack!"
T: "OK, sorry, do you have another pack? No? OK, let's just start with this cigarette. [Picks one up.]
S: "Put it in your mouth."
T: [Puts whole cigarette in mouth.]
S: "No, no, just put the end in your mouth!"
T: "Sorry." [Tears filter off, puts whole filter in mouth.]
S: "No, no, don't tear the cigarette, just hold it between your lips!"
T: "Oh, sorry, give me another one." [Places new cig sideways between lips.]
... and so on. You can play the game for a long time. It's hard to give clear instructions, even when you know the domain. Programming will endure for a long long time. -- RonJeffries
I had a friend who could do the Rubik's Cube in seconds.
That made me think of this way of explaining to my manager why did our latest project FAIL!
Olivier takes an average of 10 seconds to completely sort all colors of a 3x3 Rubik's Cube after looking at it for approximately 5 seconds.
If you ask him to make an estimate of how long it will take to sort it, you give him the cube, start the clock and after 5 seconds he will say:
"OK, as soon as I start I will be done in 10 seconds"
you smile and say: "Start!"
After 3 seconds you ask him to stop.. give him another Rubik's cube and say.. sort this one instead...
4 seconds after he starts the second Rubik's cube, how long do you think he will take to sort the first one again?
If you answered 7 seconds approximately, congratulations: You're upper management material!
(and Olivier would be rightly entitled to force you to eat the cubes)
I agree with Simucal in the sense that managers tend to do better when you break a problem into hours, rather than into programming tasks. For example, saying to your boss, "That should take about two hours to complete, but I have a few other things that I have to complete first, so I should have it to you by tomorrow." is a lot more useful than saying, "Well, first I have to design an interface to communicate between objects, and then create the classes to implement the interface, and so on." Managers understand what they can see, so anytime you can explain your task in terms of end-user effects, you will likely have more success.
With that said, don't let your manager intimidate you into making promises that you can't keep. You may know that all they want to hear is "I'll have it by the end of the day.", but if you know it can't be done, don't say that it can, hoping that if you have it to them sometime in the next couple days, that it will be "close enough". If you start factoring in time for designing and testing and give them appropriate estimates, eventually they will start to understand how long it takes to accomplish certain types of tasks, and stop expecting everything to be done by yesterday.
I've also noticed that tangible results along the way tend to put their nerves at rest (temporarily, at least). My boss starts demanding finished results when he starts to panic as to whether or not a task will be completed on time. However, when he is able to "see" the step-by-step progression, then he is more likely to understand that we are, in fact, making progress, even though it isn't in the finished product yet.
Also, as you start this process, try to look at things from their point of view, and understand that until you get to a point where you can spend the amount of time you think is necessary, you may have to find a happy medium. There came a point in my experience where I needed to develop a Cache object, and while I would have loved to take several weeks to design and implement a configurable and extensible Cache that could be widely distributed across multiple applications, I had to limit myself to the task at hand. Just make sure that if you decide to scale back or follow through with a short-sighted design, be sure that it is well-documented so you can go back and fix it when you have time (or so another developer can pick up on the train of thought that you were unable to finish). Also, don't sacrifice good coding standards and style, as this will also make your code easier to maintain and update properly in the future.
Good luck!
This one may be a good book for non-programmers to understand some of these issues and pitfalls of runaway requirements:
Dreaming in Code: Two Dozen Programmers, Three Years, 4,732 Bugs, and One Quest for Transcendent Software
In all seriousness, I think the best thing it to actually tell them that some things are complex and do require complex problem solving, analysis and design. There is a gap between what they do, and what the programmer does and its unfortunate that they will never understand the full implications. You sometimes just have to be firm and explain that it can take alot of time.
Perhaps a breakdown of the task into subtasks and giving them estimates may help.
Make sure you understand their issues too. People will often bring solutions to the table ("we need this feature") rather than start with root business needs. The more you understand the problem the more likely you are to be able to suggest a compromise.
On occassion I've been told a certain large feature is absolutely essential, but I've been able to deploy much simpler solutions that substantially addresses the problem. Sometimes these interim solutions have grown into vital features, just as often I've been able to remove them two releases later without anybody noticing.
In my experience, whenever I started to explain to sales people in the past why a task takes a certain amount of time, they quickly admit that they do not really want to know the technical details, and I am fine with that. I usually do not want them to explain to me why they still have not nailed down that big sale after n days either. To do work effectively, everybody has his own area of responsibility.
Just make sure that your relationship with the sales people that you provide estimates for is good and they trust in your ability to do proper and reasonable estimations and get the work done. IMHO there should be no need to explain and reason an estimation in every detail, but if there is, I would say the real problem lies elsewhere.
And I wholeheartedly agree with "It depends" above.