I own a small software development company that developes Web software to other small and medium companies in Chile. The business process is very complex and it is hard to stablish where to put the efforts to make our company better, more efficient, and give better solutions.

I'm also a TI master's degree student and i'm making a paper about this subject, so any help would be great to help my company and my paper.

I have considered 3 areas for the problems:

1) Software development problems
2) Web development problems
3) Small and Medium companies problems

I don't know about you, but at least this "business formula" in Chile has not received very much support but it is getting better, but today my company is far from being self-sufficient.

UPDATE: Thanks guys for your support so far, i'm updating because i have somewhat enough information so i decided to go deeper within the subjects, wish i would like you to consider for your next answers/commentaries on the subject:

1) Software development problems (3)

1.1 Incomplete problem picture
1.2 Useless delivered software
1.3 Unrealistic or inadequate schedule

2) Web development problems (3)

2.1 Apparently non-viable implementation
2.2 Unefficient module construction design
2.3 Reduced result system inter-operability

3) Small and Medium companies problems (3)

3.1 Very specific, but narrowed requerired system characteristics
3.2 Developed system is not used
3.3 Positivist demand for activities in project execution

There are only 3 problems for category, to deliberately keep a thiner scope. Also, i have considered that it would have been apropiated to separate the third clasification on two, but won't be doing it just now:

3) Small and Medium software developement providers problems

4) Small and Medium software developement clients problems

In that case, i think i would have made the scope of the problem wider and it is not what i want to do now, until at least i'm very trough with the other two clasifications. What you think?

  • How small is small? How many developers, I mean. – biziclop Mar 10 '11 at 0:24

Recovering from the "hero coder" mentality is huge as the company grows. Many small companies want low overhead and don't want a lot of process. They can often achieve a lot very quickly from scratch with few people. Marketing makes crazy promises to customers because they have to and developers pull off feats of hacked-out brilliance at the last minute to save the company.

But then legacy costs and technical debt catch up as the company becomes more entrenched in their market. Progress becomes slower. Much slower. The code is abysmal. The developers are burnt out all the time and bitter. Promises made to customers stop being met. People play the blame game.

Transitioning out of the knee-jerk, fire-fighting, expecting feats of brilliance culture to one that maintains some semblance of sanity and planning can be a difficult and painful culture shock for small companies.

They say the fast beat the slow but eventually you're worn out from going so fast that you become slower then the slow. Everyone knows the tortoise ultimately beat the hare :)

  • +1 As you get more code out in the wild, support and updates will be come bigger issues. The 'hero coder' mentality will be an impediment beyond a certain point - you'll need predictable process that don't depend on the one person. See also 'bus factor'. – DaveE Mar 9 '11 at 18:58
  • Yup, the mentallity change is one of the things my clients need to understand and support so THEY can have the better service posible, for what they are paying. I'm going to answer the thread so you can see where i'm now. – Ron-Damon Mar 9 '11 at 19:20
  • I have 15+ years at my current (and only gig) and watching us grow from 5-6 to 12+ devs this answer is spot on. Can't up-vote it enough. – DevSolo Mar 9 '11 at 20:20
  • Wow, almost sounds like we're co-workers :-) – Kristof Claes Mar 9 '11 at 20:39

Regarding the Software Development, In the recent years companies that I have worked with followed Agile development for faster productivity and throughput. 15 minute Scrum meetings works wonders these days and I initially started off with the traditional Waterfall model for development.

Regarding the Small,Medium company issue I worked with 2 Start ups in the last year and main problem my company faced was in the reputation aspect because customers look for a good portfolio to see if the company would suit their requirement for the development of their product. We worked hard to build that reputation factor initially Once that issue is past the biggest challenge was to cope up with the current market standards and getting the company compliant with Industry standards.

Personally i felt i learned a whole lot working on Startup companies and it did provide me a solid base skillset wise. Regarding Web Development Issues i think there would be plenty of gurus here who would give more optimal solutions than I would come up with.

Always Remember Customer is always right !! :)

  • Yes, customer is always right!! Thanks for your answer, and yes... i have had very much learning experience too with startup companies. I thank you too for the comments regarding reputation and later market standards, i think that sort of vision was what i needed. – Ron-Damon Mar 8 '11 at 18:37
  • @Ron-Damon Glad to be of assistance. Good luck with your venture!! – Morpheus Mar 8 '11 at 18:57

Have you thought of just taking a baseline of how are things now and try to rank how well are the various parts of the company working? This would require breaking down the company as a whole into various pieces to get some data of how are things going and documenting processes and stuff but this could be quite useful just to see what is being done and then look for holes to see what isn't being done.

Creating a vision of where you want to be is also a good idea here though this requires thinking both at high level and low level details. High level would be to be a world-class organization or grow to be 5X our current size in the next 10 years. Low level would be setting sales targets for the next year that are more tangible and limiting in a sense.

I got these ideas from looking at some ITIL stuff in the "Continual Service Improvement" section.

Now that you have given more details, I can attempt to give more of an answer as you do realize that "software development problems" is beyond broad and has millions of possible interpretations right? "I want to duplicate Google and Facebook combined with no budget, no people and only 30 seconds," is the kind of problem that I know I don't have a way to successfully achieve that and I doubt anyone else would have an answer though I could be wrong. I'll just take the first couple of groups as those I do know enough to try to answer to some extent.

1) Software development problems (3)

1.1 Incomplete problem picture 1.2 Useless delivered software 1.3 Unrealistic or inadequate schedule

The problem picture will always be incomplete. Looking at this question even, is there enough here to really answer the question in a comprehensive manner? I don't think so, but that is my perspective. The scheduling issue has usually stemmed from either poor requirements gathering where the requirements were vague and hard to give reasonable estimates as to how long it would take or the people doing the work hadn't done it before and estimates are again incorrect due to lack of experience. This isn't an easy thing to overcome though I'd say good luck on trying to get there.

2) Web development problems (3)

2.1 Apparently non-viable implementation 2.2 Unefficient module construction design 2.3 Reduced result system inter-operability

Which kind of non-viable are you meaning here: That something couldn't be done,e.g. sorting in O(1) complexity, or that what was done won't scale sufficiently to be a viable implementation in the long run? These are very different issues where the former is more a question of educating the requester that the request is not possible to fulfill and I could give you proof of it.

As for the second point, welcome to the world of creative solutions where most things can be made better sometime in the future. However, another factor here is what metric defines efficiency here as there are simple things like speed or space of execution but also more vague things like maintainability, scalability, reliability, and so forth.

The third one I don't quite understand what you mean there so there is a communication problem there. Was that part of the requirement or not? That's my initial retort but really there has to be some dialogue there to know what is really being requested, why is it being requested and what constraints are there for a solution.

If you are wanting to know the biggest software development issues for small to medium businesses I would wonder how would you measure the size of the problem. Is it the percent of companies reporting this issue? Is it the scope of the issue? How is an issue defined here really? I'm tempted to think this is a can of worms but maybe this is useful to do a little brain dump here and see where this goes in the end.

  • Yeah, but my problem is not what to do to detect the problems, what i need are current "main problems" within the 3 areas that i stated. Even so, i'm considering only 3 problems per area, because i want to keep lightweight and very concrete the activities that should be recommended to my company, other similar companies and my clients wich all area small to medium size enterprises (therefore they have little specialized personal, areas, time and resources). – Ron-Damon Mar 9 '11 at 18:06
  • Well, first of all let me thank you, as this is precisely the type of conversation that i needed. – Ron-Damon Mar 10 '11 at 1:20
  • So, allow me to clear some things too before i give you more feedback: i'm doing this question because 1) my company is a software development provider of the aforementioned type and i want to stablish more formal parameters to our work, and 2) my master's degree tesis is about these subjects, so i really need to dig deeper and make it a very heavy brain fryer. My tesis is this: "Framework for Web development systems on small and medium companies", so i need to go trough. Can't answer any more now but i'll check your answer later, as i want to be very detailed to comment about it too. – Ron-Damon Mar 10 '11 at 1:30

The transition from small to medium or large is the hardest part. Small tends to have little or no process and "Hero coding" as someone else said. Then to become a larger company, financial help is often sought and the company becomes partially bought by a venture capital firm who then starts to institiute process that is aimed at the bottom line only. All the perks of the small business go away. Employees start being treated like interchangable parts.

Worse is the code base that was adequate for a small company is often completely inadaquate as an Enterprise application because it was not designed for performance with large sets of data from day one (Database specialists, we don't need those! Oops turned out we did).

As the company get larger in part by getting larger clients, the need to prove to those clients that good processes are in place becomes greater. Thus you suddenly have to deal with configuration management, QA testing and developers losing their rights to production and project management software. All of which is hard for the orignal developers to deal with.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.