Reducing Software Development Timescales

[Lemonhead]

What are you and your company really doing to reducing software development timescales? Increasing resources on a project to increase parallel working increases the problems of project management. Reuse is still not practiced widely. I hear other ideas about developing products with a view to keeping the product development cycles short by evolving them incrementally, i.e design for adaptation which I think is a slightly different take on design for reuse. In this approach a platform is designed from the outset with the view that adding and improving features will be the one of the main mechanisms for introducing new products. This approach demands excellent design(as does design for reuse). Obviously the approach used will depend on the nature of your business and product, but what is your company really aiming to do?

N e i l

[johnk]

My small software development firm (6 of us) has tried several approaches with less than full success. When we moved to multi-tier VB structures with reusuable modules we had to move to an entirely different project model.

Here are some of the issues for us:
- Design is now a much larger proportion of time, programming is much less, and testing about the same.
- Due to the nature of modules used by multiple other modules, a source control system was absolutely required.
- Our programming efficiency has definitely improved, quite substantially so. But this came after a full 2 years of opposite experience. Part of our improvement comes from our own program generators - and several are now available commercially.
- Reusable modules are at the very heart of our reduced project times. However, our experience is that you have to build your own, they must be built to serve your own ways of creating applications.

Changing to objects and multi-tier **** near killed us. But now I'm really happy we did it. With the claimed solution to deployment and reliability problems by Win2000 I am expecting next year to be our best ever.

Good luck.

John Kisner
J.L.Kisner & Co., Inc.
Greenville, SC, USA
864-233-6941

[Lemonhead]

I'm surprised and disappointed with the response to this question - doesn't anyone have anything to say?

N e i l

[Dave Smith]

The most obvious thing to do to reduce timelines is to eliminate slippage (let's be honest, our line of work is not known for meeting schedules ;) One problem is that lots of software developers simply have no idea how to effectively schedule. I'm still learning, myself, but I think I've come across some useful ideas:

1) Junior SW developers need to be coached on HOW to plan a schedule and meet it. A couple of years ago, I could be intimidated into any impossible schedule that came out of my CEO's mouth. It's very hard to say "no" to your boss' boss ;)

2) Some stress and schedule pressure is good in a competitive commercial environment, but constantly slipping schedules & constant pressure can lead to finger pointing, bad morale, and burnout. Such conditions can cause a vicious cycle of low productivity.

3) The most important aspect to improving software development timelines is to have team members who genuinely care about the team's mission, and therefore are willing to change their non-productive behaviors for the betterment of the team. Easier said than done. You can lead a horse to water...

4) An organization needs to encourage bad news to flow. There needs to be an internal corporate environment of no risk in quickly floating bad news upwards. A smart organization can learn and grow from bad news, instead of always shooting the messenger.

Dave Smith

[johnk]

Since my prior response I've given some more thought.

In my shop it is not a matter of individuals being more efficient while attending to their assigned tasks, it is the distractions and unexpected obstacles which cause schedules to be slipped. While not yet doing that well, we are making some progress in keeping to schedules. Here are some thoughts:

1. We spend more time in the design phase and produce more detail in the design document. Where possible we avoid estimating completion dates until the detail design is completed and agreed to by the requestor.

2. We have worked to standardize the development environment for programmers where practical. We have even written VB code generators for for the top 2 tiers of our 3 tier structure and a common use module for our data access 3rd tier. Your technology may be much different, but the key is to standardize the repetitive parts of programs. Programmers who feel their creativity is invaded will soon appreciate the reduction in detail as well as the opportunity to focus on jucier parts of the programs.

Like you, I'd like to see some discussion on this issue.


John Kisner
J.L.Kisner & Co., Inc.
Greenville, SC, USA
864-233-6941

[Tomaz Stih]

Neil,

i am really glad someone brought this question up. Though majority of my projects are solo they are getting quite sophisticated (the latest one will be some 30KCLOC+ of 3t VC++, when finished) and I also did some consulting from that field so, here goes my bag of practical tricks.

- when your project is more then 5-7 KLOC introduce some form of configuration management even if it only means integrating documentation generation from source code and copying latest libs, docs and binaries to /doc, /lib, /bin directories, into your build process,

- use automation tools, create your own,

- reuse on all levels, not just classes but dialogs shapes (UI standards), graphics, terminology, concepts; patterns are not limited to design,

- not being a slave of latest technologies can help your team gain in depth knowledge and get to know the technology they use very well, standard C++ and STL are great mean to acieve that; remember - the issues in software development are dominated by business objectives, not by technology,

- take special care of the domain level and get your best people to work on it since it will suffer most changes and it has to be the most resistant and upgradable part of your product,

- introduce metrics to measure productivity and do some statistics at the end of your project, if all your projects are some kind of database applications then you could for example divide them to functional points (i.e. an entry dialog with up to 20 fields is n points, a report m point), this will not increase productivity but you will be able to plan based on facts and this will increase your reliability (and quality);

- standardize on all levels, for example: your programmers should not study how to structure the req. spec. document but instead go to company intranet and have IEEE std. template prepared, same is true for the about dialog,

- specialize members of your team instead of having everybody doing everything,

- have new members introduced into collective thinking by providing them guidelines (intranet), cult books (Meyers, Musser, Lakos...), sites (codeguru...),

- very important: introduce brainstorming sessions for the technical members of your team, where they can share design ideas and knowledge, a lot of companies have meetings only on project level without technical details,

- nothing demotivates software engineers more then incompetent "theoretical" team leaders,
introduce software engineering culture and quality as values and keep "the less important technical part" and "implementation detail" terminology for the management meetings.

Regards,
Tomaz