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.
Myself and a friend have created a startup, but we are both software developers. We are quickly realizing that we are going to have to deal with and understand, all of the intricacies of business.
Are there any resources that can help us avoid common problems encountered by the non-business-savvy? How do you balance creating your product with maintaining realistic goals to reduce time-to-market.
It's like you need to take off your programmer hat and put on the business hat, and vice versa.
My software business was in a very, very small niche market centered on computer aided design of the magnetic layer in hard disk drives (www.micromagnetica.com - please note that I am in the process of closing down my business as the number of potential customers has shrunk to the point of making the business not viable. The web site reflects this point). I have been in business for 10 years and have done pretty well. My competition was a series of commercial and open source programs (mostly university or government sponsored), so, although the market was small, I was able to create a unique product that sold well.
Pitfalls:
Putting your needs above the customer - Customer comes first - always listen to your customer's needs and make sure your development follows their needs rather than yours. Every programmer has a list of things they want to learn or do. Don't use this list a guide for your development unless it solves an issue or helps create functionality that the customer wants/needs. This one point can make or break your company.
Not clarifying your business idea - Put together a business plan - it will help clarify what you are doing. Read the book, "The Art of the Start", by Guy Kawasaki to get the business perspective of starting a business. If you need money then you can use this to help secure financing from either angel investors or venture capitalists. Otherwise, it will help clarify what you are doing.
Not marketing yourself - Do this the following:
(a) Find a good name for your company and secure your domain name. Even though a bad choice for company name won't kill you (my first company was called "Euxine Technologies" and it doesn't get much worse than that), but my product sold itself and was not encumbered by the name.
(b) Put together a web site as soon as possible with a good description of your product. Google will eventually find you and traffic will start flowing to your site.
(c) As soon as you have a working prototype create a mechanism where potential enthusiastic customers can download it and start helping you find bugs. You can make this the full version with a limited time or a limited version with no time limit. I have done both and both work. Make sure that users know it is a beta (or alpha) version of the software. The most important part of creating the beta user relationship is they will ask for features that you did not think about and this could take development along an otherwise unforeseen (and lucrative) path. This will also give you a way to keep your hand on the pulse of potential users.
(d) If your product is applicable to a particular industry go to relevant conferences
(either get a booth or make contact with potential customers) and sell your product through demonstrations, flyers, and the distribution of free limited versions of your software on CD.
Not Branding yourself - come up with a logo that you will use to identify you and your product. This logo will show up on your web, your business stationary, and business cards.
Not Managing your money - initially there is going to be a long spell before the money starts coming in. Be very frugal with your seed money. The money will not start coming in the moment your deem the software is ready to sell. There could be a time-lag of at least a couple of months between when people show interest in your software and when the sale comes in. This will depend on how much your software costs. The more costly the software the longer the time-lag.
Once you start making sales, there will be seasonal variations in how much money comes in. Always try and keep at least 6 months worth of money in the bank to cover salary and operating costs.
Not knowing who your customers are - Once you start selling software, make sure you know who your customers are - they might be different from what you thought they were. When I started my software company, I thought my customers would be all R&D engineers who were doing research in magnetic layers. After a while it became clear that most of my users were the subset of this group that couldn't program, but understood the physics behind the software.
Not acting in a professional manner - When interacting with customers be professional - act and dress in a professional manner.
Creating a product because the technology is cool, rather than because there's a market.
Creating a product because you want it, rather than because there's a market.
Creating a website that lists the features of your product, rather than the benefits.
Assuming that advertising on Google AdWords will work for you.
"Build it and they will come."
The #1 rule of StartUp Club: Every startup should have both nerds and businessmen.
Most computer nerds don't know anything about how to run a business or market and sell a product. There should be at least one businessman at your top level (but watch them like a hawk, lest they steal away with the fruits of your labor :-).
Not understand/knowing who you are competing with.
Not understanding/knowing your target market.
Not including your customers in the design phase.
Not spending enough time gathering product requirements.
Spending too much time gathering product requirements (analysis paralysis).
Not enough marketing.
Have a strong team so you can trust the people you hire to do their job.
Be prepared to do whatever it takes to succeed (ethically of course).
Not having a direction (business plan).
Not having goals or having unreachable goals.
Not understanding cash flow. There are a vast number of profitable businesses who do not succeed because of clash flow issues. Just because you sold a 1000 units doesn't mean you can afford to pay your staff and or other expenses. As I have heard it before "Cash is king!"
These are just some things that might get in your way. I would recommend not only worying about the business side, but worry about what are reasons software projects fail. There are numerous books about how to collect requirements, produce quality code, testing code (e.g. TDD), project methodolgies (e.g. XP, Agile, ...), and many more topics.
Your startup will likely fail if you can't deliver a product or if you can't deliver a product that doesn't solve the problem.
Finally, it is hard to judge success if you don't define what it means to succeed. Is it staying in business, doubling your revenue in 1 year, breaking the $250,000 mark, or doubling your staff size. You need to define what it means to succeed not only in your business, but with each product you create.
Do your homework. If you are in the US, the small business association is a good place to find resources.
Trying to be all things to all people.
Often in trying to create a product that appeals the everyone, the product becomes so general that really no one can get excited about it.
In my opinion, it's better to target your product to a niche community of people with a very specific need and then fill that need better than anyone else.
Here's a common pitfall, but it's not restricted to just small companies: Lack of diversity in the management. The kind of diversity that's important is diversity of experience. I've seen a couple small companies that suffered from this pitfall. They can often go along for a while making good decisions. The problem is that it's almost impossible for them to tell when they're making bad decisions. This doesn't necessarily mean that they'll fail, it just weakens them to varying degrees.
Company Development - in the software industry you can make a lot of money (respectively to other trades) in a very short-time. most people tend to get greedy and want more money so the accept more projects and hire lots of people - but they don't develop their infrastructure, their communication-lines, their responsibilities, their developers etc. Because it costs money and you don't have a direct benefit from it and you lose your cool "flat-hierarchy-everyone-is-a-boss"-image (which is not the case anyhow)
I myself witnessed two promising start-ups fail because the grew way too fast.
So keep an eye on that one.
Shiny! Don't let developers chase the latest shiny thing on the internet that catches their attention. Keep developers focused on the core strategic needs of the company instead of steering your product in different directions as their interest is caught by other things.
There's a blog full of tips at OnStartups. A few recent, relevant posts: learn from the underpants gnomes: have a business model, and here are some marketing tips. The author is a developer-entrepreneur himself, which sounds like exactly your perspective.
Update: Dharmesh just set up a StackOverflow-powered site for just this sort of question: http://answers.onstartups.com/
Make sure you know your target users and their needs.
I worked in a really cool startup where we thought we had a great product, but we were unable to generate that great user story to really demonstrate how our product filled some need for them. This shortcoming prevented them from "connecting" with our product in an exciting way.
In my opinion, the disconnect was due to the fact that we didn't know our target users and understand their problems as well as we should have.
Sales Sales and More Sales. Plus a willingness to release before the code is "perfect" and release features incrementally. There is actually a pretty good Hanselminutes about this very topic and this very site (http://www.hanselminutes.com/default.aspx?showID=152)
Not having some people on the team with different ideas/backgrounds/personalities.
If everyone is always agreeing with each other all the time, and there isn't any friction, you aren't going to get anything done. Oh, you might be alright for a while, but if everyone thinks the same way, when you get stuck (and you will), you will stay stuck. When you're on a roll, a curveball is a distraction; when you're stuck in a rut, or up against a wall, a curveball can get you moving in a different direction. It might be the wrong direction, but at least it's a direction.
Not having enough knowledge and experience in marketing. Although selling a good product is easy.
The problem is what I call IBM OS 2- geniuses build a very good product but the product is not marketed well nor tailored to effectively massage the ears of buyers. I despise some things about business workers like short-term thinkings, perfering quick-and-dirty developers over slow-but-great developers and other issues- but they are the ones who make money and drive software into customers' hands. If a start-up does not have developers who can function effectively work with business issues- then it need to go get someone who can. Failure to do so make is what made Windows 95 a hit and IBM's OS 2 a dinosaur.
Not having a specific market in mind when developing a product. A couple of places where I worked tried to do anything and everything which lead to not enough effort on one market to get profitable first so the business could still be running.
Micro ISV links has some links that were shown in a top secret presentation I attended a little while back that may also be useful.
Related
I have recently completed my bachelor's degree in Computer Engineer. I have had one small internship till now.
I have little coding experience.
After searching for months (Does not mean I am desperate for the job-Just wanted to clarify so that your answer is not based on it), I have been offered a job at a start-up to design and develop their web application for user interaction and management. I am the sole technical hire and will be the only person responsible for the development of the platform. The founders, though highly educated, do not have any sort of technical background.
It seems like an interesting opportunity but I am wondering if it too much responsibility too early?
I know this is not a standard programming question but I think this is a programming ability understanding type of question.
I would highly value your insight on this subject.
Thank you.
Just looked at your LinkedIn profile. Looks like you have great entry-level programmer qualifications.
Being the sole technical member of the team, with limited industry experience may be a great opportunity for growth.
However, the flip side argument is that you may be losing out on opportunities to grow with adequate mentorship. In all reality, the college/university CS/CE curriculum does not typically prepare you to handle real-world problems that senior-level software engineers address daily. In a company where you are NOT the sole technical staff member, you will have the opportunity to collaborate with and learn from experienced pros. In my opinion, that is a huge factor in selecting your first job.
So ... assuming this startup grows quickly ... are you qualified to:
Make day-to-day technical decisions regarding scaling, security, and prioritization of product features?
Interview, hire and evaluate the performance of additional technical personnel?
Develop the full-stack of a web application including setting up and administering server, database, APIs and associated frameworks, client side technologies?
If you are uncomfortable with any of the above (which is a very limited set of questions) you probably aren't yet ready. It takes a long time before any of us are. Before I took my first leadership position in a startup, I had over 10 years of experience in multiple industries and with several technologies. But that's me ... you have to make this decision for yourself.
Depends on the type of the company. If there's going to be interaction between the users and the site a lot and it just doesn't serve the purpose of providing information, then you'll have to handle things on the server side as well to provide proper response and you need to be quite good with your stack and as a fresher, it isn't quite recommended to be a sole performer in the technical section of an entire firm.
Since you tell, web application, I assume the user does have to interact. I wouldn't go for it if I were you. But you haven't told about the level of expertise you possess in your skill set. So, can't say whether or not you'll be able to handle it.
and this is just my opinion btw.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
Lately I have seen our development team getting dangerously close to the 'second system syndrome' type ideas while we are planning the next version of our product. While I'm all for making improvements and undoing some of the mistakes of our past, I would hate to see us stuck in an endless loop of rewriting and never launching anything.
Is there a good design / development method that lends itself to building a better version 2.0 while avoiding second system scenarios?
I have experience the second system syndrome from both sides as a customer/sponsor and part of a development team.
A root cause for problems is when the team latches on to an Utopian vision of version 2, such as the desire to make the new software "flexible". In this scenario everything is abstracted to the nth degree. For example, instead of data objects that represent real-world entities a generic "item" object is created that can represent anything. One flawed idea is that we can build in so much flexibility into the software to anticipate future needs, that non-programmers will be able to just configure new capabilities. Often one goal such as "flexibility" overshadows the effort to a point that the resulting software doesn't work.
A balanced practical consideration of usability, performance, scalability, features, maintainability, and flexibility goals can bring the team back to earth. "It would be great if..." should be prohibited from the vocabulary of the team. The Scrum backlog is a good tool and the team should be heard saying often... "Let's backlog that...we don't need that for version 2."
"I would hate to see us stuck in an endless loop of rewriting and never launching anything."
Which is why people use Scrum.
Define a backlog of things to build.
Prioritize, so that things which lead to a release are first. Things which should be fixed are second.
Execute sprints to get to the release. Execute a release sprint.
Get someone who has written at least three systems to lead the project.
Try to focus on short delivery cycles, i.e. force yourself to deliver something tangible and useful to the users every few weeks or month. Prioritise the tasks based on their value to the customer. This way you always have a usable, functional application with satisfied users, while under the hood you can refactor the architecture in small steps if you wish (and if you can justify the need for it - that is, towards management / the customers, not just teammates!).
It helps a lot if you have a stable build process with a good suite of automatic (unit / integration) tests.
Agile development methods like Scrum do this, and they are warmly recommended. But of course it is not always easy or even possible to adapt such a method in your team. Even if you can't, you can still take elements of it and apply it to your project's benefit (maybe without even mentioning the words "agile" or "Scrum" publicly ;-)
Make sure you document the requirements as well as possible. While obviously you need to also manage what gets into the requirements to avoid over-designing, having a fixed scope helps prevent developers from running off with ideas or gold-plating what needs to be done and it helps keep management or clients from introducing scope creep. Define all requirements and how scope changes will be addressed.
I'm all for short development cycles (make sure you're writing tests) and agile methodology, but neither of those is a shield against second syndrome system. In some ways it's easier to keep adding on feature after feature if you're working in short sprints without stopping to look at the overall picture. Use agile practices to build the simplest thing that works, then keep adding your other requirements as simply as possible. Remember YAGNI, because when you build a system a second time, that's when you're most likely to build something you're sure you'll need at some point, something that will make the system "extensible" so there never has to be a third build. It's the best of intentions, but the road to hell and all that.
You can't get close to second system syndrome. Either you're in it, or you're away from it. You'll know when you're in it, but only after wasting a lot of resources.
Tips are: know about it (so basically we got that covered already). It's invaluable information to know what a "second system" is, and even more to have some experience with that. I think we all have some experience with that, hopefully benign.
That knowledge will often make you think twice and you'll find a solution without venturing into second-system limbo.
PS: Also know how to use your current system, that includes, maybe documented solutions, and other documentation.
Focusing on the system architecture should help e.g.
Having documented interfaces which support "loose coupling" between sub-systems
Having documented design decisions (avoid re-hashing previously beaten paths)
Hence, without going for an all out swap, the current system can be "upgraded" with more appropriate interfaces to help future growth.
Another good way to focus: assign a $$$ figure to each feature and prioritize accordingly ;-)
Anyhow, just my 2cents
I up-voted S. Lott's answer and would like to add some more suggestions:
Deliver a working product to your customer as frequently as possible. Iterations lasting between a few weeks and 2 months are ideal. Agile methodologies, such as Scrum, lend themselves well to this.
Use FogBugz for feature and bug tracking. Its features are very practical for agile projects. FogBugz allows easy prioritization according to releases and priorities. If your team enters their estimated levels of effort for each task, you can also use this to calculate reasonable ship dates.
Prioritize which features you will develop according to the 80/20 rule (20 percent of the features will be used 80 percent of the time) and the most bang for the buck. This helps keep the system as simple as possible, helps prevent feature bloat, and saves development and testing time.
Give similar thought to both new features and bugs when you determine the priority of an issue. One point of the Joel Test is "Do you fix bugs before writing new code?". In most shops this doesn't happen, but do not make debugging the system an afterthought. Also, keep a working copy of the old system to compare against when bugs are found on the new system.
Also factor in the level of effort required to maintain, and if necessary rewrite, existing code. If you have not already done this, give the team some time to code review whole files that they find troublesome to change. If the system's code was difficult to maintain the first time, this will only get worse and cause your team to spend more time on new features down the road.
It can never be avoided at its entirety. But being cautious could alleviate the problem.
You should formulate some thumb rule based on the vital parameters (scarcest resource) that define the success of the system. For example, reducing potential number of bugs might directly decrease operational cost (potential service calls to support center). But this might not be the case in every other systems. Another example, scarce use of CPU, memory and other resources might be beneficial in some cases but there could be environments where they could be available in abundant.
So simply to avoid "temptations", identify the scarcest resource (time, effort, money$ etc) and consider implementing only those that exceed threshold value.[f(s1,s2...) > threshold]
Despite the iterative development, I would emphasize on how technical debts are handled.
Links that are related to this:
Tech Debts: Effort Vs Time
Tech Debt Quadrant
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
I work as a lone developer in a very small company. My work is quite chaotic and I'm looking for ways to make it more organized.
One problem is that my projects have practically no management. Rarely anyone asks me what I'm doing, or if I have any problems. At some point there was talk about weekly status meetings, but that's some time ago. Seems that if I'd want something like that, I would have to arrange those myself.. Sometimes I'm a bit lost on what I should do next because I don't have tasks or a clear schedule defined.
From books and articles I have found many things that might be helpful. Like having a good coding standard (there exists only a rough style guide which is somewhat outdated in my opinion), code inspections, TDD, unit testing, bug database... But in a small company it seems there are no resources or time for anything that's not essential. The fact that I work in the embedded domain seems to make things only more complicated.
I feel there's also a custom of cutting corners and doing quick hacks on short notice. This leads to unfinished and unprofessional products and bugs waiting to emerge at a later date. I would imagine they are also a pain to maintain. So, I'm about to inherit a challenging code base, doing new development that requires learning a lot of new things and I guess trying to build a process for it all at the same time. It might be rewarding in the end, but as not too experienced I'm not sure if I can pull it off.
In a small shop like this the environment is far from optimal for programming. There's many other things needed to be done occasionally like customer support, answering the phone, signing parcels, hardware testing, assembly and whatever miscellaneous tasks might appear. So you get the idea about the resources. It's not all bad (sometimes it's enlightening to solve some customer problems) and I believe it can be improved, but it's the other things that I'm really concerned.
Is it possible to have a development process in a place like this?
Would it help to have some sort of management? What kind of?
Is it possible to make quality products with small resources?
How do I convince myself and others that the company which has worked successfully for decades needs to change? What would be essential?
Maybe there's someone working in a similar shop?
Use Source Control for EVERYTHING
Develop specifications and get signoff before starting - there will be resistance, but explain it's for their own good.
Unit tests! It hurts because you just want to get it done, but this will save you in the long run.
Use bug tracking - Bugzilla or FogBugz if you can afford it.
My advice is not to be extreme. From my experience, pure agile or pure traditional will not work. Before you use any process, know what it mean to solve.
I personally use a variation of Agile RUP. I do some upfront effort such as investigate the actual needs, do high-level design with possible extension. And ask customer to sign-off some major high-level requirements.
If you work in small group, detail design or specification may not worth. Of course, if there is some libraries that are shared by many, it will be worth the trouble.
Deciding what to invest in up-front depending on its risk (likelihood and effect).
Moreover, many SW best practice is really 'best' like version control, automatic testing (to me I only used it way to early detect regression as I do not believe in TDD as driven force of the development). I suggest you read 'Pragmatic Programmer' it presents many of those techines.
As to answer you questions:
(1). Is it possible to have a development process in a place like this?
Yes, but as I say, trailer it to fit your organization.
(2). Would it help to have some sort of management? What kind of?
Management helps but no control freak. Plan what to do when: integrate, resolve conflict, dead line of some mile stone. And roughly keep them on schedule (I particularly like Scrum's sprint).
(3). Is it possible to make quality products with small resources?
Definitely as soon as the size of the work, the time to develop and the size of the team is balance. If you definition of Quality is the same with me. To me, Quality means: solve the problem it set out to in an efficient and reliable fashion.
(4). How do I convince myself and others that the company which has worked successfully for decades needs to change? What would be essential?
Point out the problems. If there are none, why change? If you want to change, you should be able to identify the problem OR potential problems. Point out the problem.
Some big one are:
Without any process, it is harder for new recruited to blend in as they must learn from observing other how to deal with things.
Without process, it is harder to work in stress.
Without schedule, it is hard to determine the progress.
Without automatic testing, it will takes more time to identify problems and regression.
Without version control, it will be harder to roll-back mistake and separation of work to each team members will be mess.
Just my though.
You need to work with the owner and setup short medium and long term goals. You will want to let them know progress even if only through email.
You will need to enforce some order on your workday or you will never get anything done (those long term goals).
Divide your day up into chunks when you can code, when you are working on hacks to keep it togther, when answering emails etc.
Definitely setup a bug tracker. This can help keep your email clean. You can even setup an email address to forward bugs to be categorized later. This is good because the bug reporters will eventually tire of the bug tracker and want to just email you the bugs anyway.
edit
And as lod3n said, source control, but you are using that already right???!!?!
Been there, done that.
The book Planning Extreme Programming helped a lot. I used 3x5 cards stuck on a wall. This kept my boss informed of my progress, helped with estimates and planning, and kept me on track. The Planning Game gives good ammo if your boss's expectations are unrealistic.
Unit testing, as others have stated, helps even if you're a sole developer. I find the TDD style valuable.
lod3n is absolutely right about Source Control.
I've gone with XP-style iterations before; you may want to establish a backlog of items (even something simple like a spreadsheet or 3x5 cards) as well.
Avoid deathmarches. Stick to 40 hours in the sense of not working overtime 2 weeks in a row. Spend extra time outside of work learning new skills - not just technologies, but principles and best practices.
Have a bug tracking system, both for defects and new features. Don't rely on your memory.
Continuous integration and an automated build can help even a single developer.
Can't emphasize the recommendation for source control enough.
I've decided I don't need unit tests because I can have automated functional/integration tests instead: because with incremental development there's no need to test before integration.
as crazy as this sounds I use scrum just because I like the concepts of sprints, and backlogs. It makes it easier to set realistic goals. Of course the idea of scrum master and team is all you but if you are working on outside projects where it is possible that you may pick up an extra team member with your backlogs it will be easy to distribute work. Maybe I just like backlogs. With scrum you will need to get someone to be the product manager to talk about the features of the product. Version control is a must at probably should be implemented b4 even worrying about a software development process. I have worked in a company that started from 2 developers and went to 12 in a year. We started with no version control and low coding standards. The changes you will need to make will be gradual so don't worry about rushing to do a 180. Set a goal to change one thing a month and find supporters of your changes to make things go smooth.
As well as the recommedations of others I'd say that if you are tight on resources but have more say over how things get done you should make good use of off the shelf and open source products and libraries. This leverages the efforts of others, saving you time, ensures your code base doesn't become too esoteric and adds to your skillset so you don't end up being an expert in something that's useless everywhere else.
First, lets make a distinction between a development process and best practices. Best practices like source control, defect tracking, unit testing, etc. are an given.
Then there is the actual development processes. I would always recommend having a process, no matter small or large the team is. The trick is finding the right process. You have a process now - it is just an ad-hoc process that doesn't seem to be working out too well for for you. Rarely can you take a textbook development process and directly apply it. What you need to do is tailor the process to your companies needs and culture. Look at as many development paradigms as you can and try to find something that is a good fit and them start molding it to your needs. You may have to try and fail with a number of different processes. Perhaps the Personal Software Process will be a good starting process, maybe an agile process, a variant of RUP? You have a lot of options, start trying them out.
You are also going to have to work with the rest of your organization - they need to be a part of the process. You may be the lone developer, but a development process involves more than the developer, it involves ever person that has a say or impact in the product.
This may not be a specific answer, but my point is that you will need some kind of process. So start researching them and trying them out and molding them to your needs until you have something that works.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 5 years ago.
Improve this question
I have a challenge I need some input on.
I am currently recruiting programmers for a new development department. I am looking for people that are brilliant at their work – so brilliant that they might “lack” some other things that I normally would require them to have (e.g. speaking Norwegian and (to be honest) – social skills in order to be able to meet the customer (I’ve worked with several of them before :) )).
My issue is in regards to communication between the client (customer) and the development team.
Background: We have a strategy of becoming our customers extended development department over the next two years. E.g. they consider us as their own department just sitting somewhere else. While we are on our way towards this target, we will have to make money on smaller projects. The work is there, so I am not afraid that we will not manage to stay alive.
But – we all know that good communication with the customer is one of the key elements on providing the customer with what they actually want (we are scrumming by the way) instead of something else. How do I manage to do this with people that do not speak the language, or again, does not even have the skills to communicate with the customer (you all know someone very bright that is going into deep technical issues with a customer that hardly knows the difference between Firefox & Opera)?
I have landed on a solution where I will be the interface towards the customer, the customer will join in on planning sessions, etc., and where the team will still do the demo. But in regards to continuous communication (daily) between the dev team and the customer, I will be the one doing the comms.
I know that this is not the optimal solution – being a middle man a lot of information can disappear between the customer, me and the team. Have anyone been in a similar situation?
Create a wiki. Create a page for your customer which contains pictures, business information, things to look out for, etc.
Have everyone contribute to the wiki, including the customer.
As time goes on, this page (or pages if you split the information on numerous pages) will allow
new developers to understand the customer faster
see the possible problems that may arise
your developers would contribute to the wiki since they have a tangible documentation where everyone can see how much they have contributed to the customer.
make the customer feel as if he is part of the development process
since the wiki is, by effect, a collaboration document, a common language will appear between everyone. It might not be the same as speaking your customer's language, but it will be a combination of your customer's and developer's language.
We've had a somewhat similar situation when we did "Beta programs" for select customers. When the customers had questions, they could only turn to the developers at that stage of the project because e.g. the helpdesk was not yet familiar with the new features.
We also used a "middle man" for doingt the communication with the customer and then passing it on to the developers, and this has worked quite well for us. What were the advantages? The customer alsways knew exactly whom to contact, the communication was consistent, some on the simpler questions could be answered without the need to "bug" the development team at all while some more difficult questions could be "boiled down" from a superfluous explanation to the real problem before handing the question over to the developers, both giving the developers more time to concentrate on what they do best.
Of course, if you want this to work, you'll have to make sure you pass on information between development and the customer in a timely manner, but I think it can be worth the effort (and in fact, our developers prefer it that way).
Communication skills are arguably more important than technical skills. A programmer that doesn't communicate well may well cause enough disruption to negate what they bring to the table technically.
Having said that, you still have to realize that not everyone is the best person to be "customer facing". You might designate one or more members of the team as liasons to your customers, and have the communication go through them when possible.
The developers should be shielded from the customers. Developers are usually hardcore technical people who eat C++ templates at breakfast. The customers are often very non-technical. A customer asking a badly formulated question on some trivial issue to the developer usually irritates the developer a lot causing at least a temporary loss of productivity. So it's better to have special paid people that work in between.
Don't underestimate the value of being in the same place. If communication skills are lacking, being able to point and say "look at this" can be far quicker and more effective than trying to explain everything in a meeting or email. But from "they consider us as their own department just sitting somewhere else" this doesn't sound like it is an option for you.
Generally I expect that at least some of your developers will be open to learning proper communication with the customer. Involve those developers with the communication (even if it's painful at first). English is a pretty universal language and your customer will probably be able and willing to speak it.
Shield the developers that DON'T want to communicate or learn to communicate with the customers. They may damage your relationship with the customer and you will damage your relationship with your employee.
Be careful about allowing written contact between the customer and your developers. Written communication often gets interpreted wrong, especially when written by people who do not have much experience writing carefully balanced e-mails, memos or letters.
As you build your relationship with your customer, you'll get to know eachother's personalities, and communication will be smoother.
Ten years ago when I first encountered the CMM for software I was, I suppose like many, struck by how accurately it seemed to describe the chaotic "level one" state of software development in many businesses, particularly with its reference to reliance on heroes. It also seemed to provide realistic guidance for an organisation to progress up the levels improving their processes.
But while it seemed to provide a good model and realistic guidance for improvement, I never really witnessed an adherence to CMM having a significant positive impact on any organisation I have worked for, or with. I know of one large software consultancy that claims CMM level 5 - the highest level - when I can see first hand that their processes are as chaotic, and the quality of their software products as varied, as other, non-CMM businesses.
So I'm wondering, has anyone seen a real, tangible benefit from adherence to process improvement according to CMM?
And if you have seen improvement, do you think that the improvement was specifically attributable to CMM, or would an alternative approach (such as six-sigma) have been equally or more beneficial?
Does anyone still believe?
As an aside, for those who haven't yet seen it, check out this funny-because-its-true parody
At the heart of the matter lies this problem, neatly described by the CMM guidance itself...
“...Sound judgment is necessary to use the CMM correctly and with insight. Intelligence, experience and knowledge must shape an appropriate interpretation of the CMM in a specific environment. That interpretation should be based on the business needs and objectives of the organization and the projects. A rote, checklist-oriented application of the CMM has the potential to harm an organization rather than help it...”
From Page 14, section 1.6 of The Capability Maturity Model, Guidelines for Improving the Software Process by the Carnegie Mellon University Software Engineering Institute, ISBN 0-201-54664-7.
I found it to be bloated, documentation exercise that was used mainly as a contract-acquiring/maintaining vehicle. Once we had the contract, then it was an exercise in getting around the process.
As a developer, I got nothing out of it but lost MONTHS of my professional life fiddle-farting around with CMMI.
The same goes for 6 Sigma, which I branded "Common Sense in a Box". I didn't need to be trained how to figure out what the problem was to a process - it was generally quite evident.
For me, small teams and agile mechanisms work much better. Short cycles, lots of communication. That might not work in all environments, but it definitely works in mine.
Just my two cents.
For a typical CMM level 1 programming shop, making the effort to get to level 2 is worthwhile; this means that you need to think about you processes and write them down. Naturally, this will meet resistance from cowboy programmers who feel limited by standards, documentation, and test cases.
The effort to get from level 2 ("there is a process") to level 3 ("everyone has the same process") normally gets bogged down in inter-departmental warfare, so it's probably not worth starting.
If you see CMM run. And run fast.
CMM and CMMI both offer some benefits if your organization takes the lessions it tries to teach at heart. The problem is that getting to the higher levels is very difficult and expensive, and the only time I have seen an organization go through the effort is because their customers won't let them bid on contracts until they are at a certain level.
This has the effect of the organization doing everything they can to "just get the number" without actually caring about it improving their process.
The higher end? No. CMM-5 shops do not impress me.
The lower end? Yes. CMM-1 organizations scare me.
CMM can help a new/novice team measure themselves and do the self improvement thing.
CMMI isn't really about improving your software, it is about documenting what you have done. You can almost estimate a company's CMMI level by the weight of the documentation it produces.
Background: I have studied CMMI in my Software Engineering graduate program and have worked on a team that followed its guidelines.
My experience is that the CMM is so vague that its very easy to fulfill. Also, when they come to certify you, they look at the project that your organization chooses. Where I used to work, this was the project with no real deadline, plenty of money, and lots of time to spend on every nook and cranny of process. Many of the other projects continued with little to no code/design review sometimes without versioning software.
I think the emphasis on CMM certification is unfortunate. Companies know how to work the system, and do. Instead of focussing on real process improvement that meets their bottom line, they focus on getting a certification and working the system. I honestly think most organizations would rather spend time on the former instead of wasting so much time on the latter.
Really what matters is having conscientious people who want to make good development decisions and know that they will need help making those decisions. There is no substitute for quality programmers who know that programming is an ongoing group activity where they are just as likely to make a mistake as anyone else.
I have been doing a lot of interviewing for small teams doing iterative development. Personally, if I see CMM on a resume it is a big red flag that signals interest in process over results.
All formal methods exist to sell books/training courses/certification, and for no other reason. That's why there are so many formal methods. Once you realise this, you are free :-)
Yourdon still believes. But he might also still believe the world is going to end with Y2K.
This is not something I would personally put a lot of faith in or want to be yoked with in the future. But often ours is not to reason why...
P.S. Though a bit off-topic, I would like to mention that faked CMMI certifications are very common as well as real certifications obtained through bribery.
CMM doesn't really speak to the quality of the software, but more towards the documentation and repeatability of the process. In other words, it is possible to have an orderly and repeatable development process, but still create crappy software. As long as the process is properly documented, it is possible to achieve CMM Level 5.
At the end of the day CMM is another tool that can be used or misused. If the end goal is to improve software quality, it is possible to use CMM to improve the development process and improve software quality. If achieving a certain CMM level is the goal, then most likely software quality will suffer.
The Model is losing it's credibility, first because the companies adopt the model not looking for a maturer software development model, but to be appraised to a CCMI level.
And the other problem, the one that I think leads to the lost credibility is that as a contractor, you have no guarantee that the project your CMMI appraisal supplier is selling you will be developed using the model practices. The CMMi label only states that the company have once developed projects that were evaluated as adherents to a specific CMMi Maturity level.
The problem is not just on CMMi but on the process developed by the companies. The CMMi does not describe the process itself, but just what the process should do. You have the same problem with PMBOK. Actually the problem is not just the PMBOK, but primarily the problem is the bad project managers that claim to follow the PMI statements.
At school, I was taught: CMM is a good Idea, but lacking certification (anyone can say they are level 5 / level 4) it ends up being a marketing tool for offshore shops. So, yeah, the idea is sound, but how do you prove adherence?
I used to. But now I find that CMM and CMMI don't really fit that well with agile approaches.
Oh sure you can squeeze things to get that square peg into the round hole, but when push comes to shove, you are still basing your approach on an ability to predict everything that is needed, and anticipating everything that will be encountered, when building a software system.
And we all know, how well that approach works in real life! (-:
cheers,
Rob
Agile is the next CMM and both are fragile. The field of process and quality consulting is a good business in any industry and like the engineering folks everyone needs new buzzwords to keep the money flowing.
CMM when it first came out of the SEI was a good concept based on solid academic work but it was soon picked up by the process consultants and is a worthless certification now, which is used by most CIOs to cover their ass (Nobody got fired for picking a CMM Level 5 company)
Agile is going to go down that route soon and then we can be sure to see the next silver bullet in the horizon soon :)
When I worked on commercial flight software, we used CMM and as our processes improved our ability to accurately predict completion times improved. But this was a cumbersome process, other approaches should work just as well.
Smaller projects are less dependant on process for success. The key metric is the Hero to Bystander Ratio. Any project with an HTBR of less than 0.2 is in serious trouble.
There are quite a few good ideas that can readily be adapted and adopted by any organisation for their own good, but getting a badge is a pain due to the requirement for all kinds of redundant documentation.
The problem is that CMMi is not a process but just a guide for whatever process you might choose to have and that in itself invites half-baked ideas flowing around.
Another point is that migration is a real pain when you are starting, but its the same as any other teething trouble, I guess.
The main issue with understanding the value of CMMi is understanding CMMi itself.
CMMi is a documented approach to Continuous Improvement for Software Production.
Understanding Continuous Improvement with SPC is difficult enough in manufacturing but add the intangible Software product and the difficulty is exponential.
I would recommend to anyone, or organization, new to CMMi: to document their current process then look at what outcomes (cost/benefit) can be measured independently of the process. In this way if any process, procedure of standard was changed would it yield a 'better' result. The prerequisite to this exercise is a documented, stable repeatable process since it is impossible to measure the benefit of any change within an ad-hoc environment as you are not comparing 'like for like'.
By focusing on the above concepts initially, the organization will begin to understand and embrace the essential value of the CMMi.
Legend has it that the US Department of Defense, which did a lot of contracting, found that many of its projects faced time and cost overruns, and even when they were delivered, the projects were not exactly what was ordered.
So they wanted a way to be sure that that a contractor would be able to deliver on time, within budget and close to what was required. Thus the capability maturity model was born.
The thesis is that if things are written down, then they survive attrition. But saying that write down everything would not be enough, it must be checked that they are written down correctly. Among other things.
Throughout all this, it never crossed their minds to consider the cost of doing all this. Because from the point of view of the DoD, if it gave out a project for $ 1 million to get something in a year, and ended up paying $ 10 million over 10 years and not getting what they wanted, and now if they instead had to pay $ 5 million for that same thing to get what they actually wanted in two years, they are still saving $ 5 million, and not to mention that they are actually getting something.
So if you are contractor to US DoD or something like that, go ahead and get CMM, because it would be a requirement. But if you are competing with the 1000s of software development shops on elance, to get projects with limited budgets, limited time and so on... CMM is not a good choice.
That said, feel free to read the CMMI Dev pdf (v 1.3 at time of writing). It makes a lot of good points. It deconstructs the organisation very nicely. And if you see any points which make you go 'aha! i have this problem', then by all means use that wisdom to resolve your problem. In our case, one small change we made was to ensure that we make a list of all the people who are allowed to give us requirements. If there was more than one person who was allowed to give us requirements, then any requirement coming from one source was circulated to the others, and they had to say 'okay' before we added it to the backlog. This small change made a big difference in how much we worked and reworked.
In short look at the process areas and compare them to your pain areas, and take the suggestions given by CMM. The way you implement it is your own. And you can always implement it in a way that does not take too much time or cost too much money. But I guess the same applies even to the relevant ISO/IEC standards.