Board index » delphi » Lack of Emphasis on Small-Scale Software Development Tools

Lack of Emphasis on Small-Scale Software Development Tools


2006-12-07 11:12:20 PM
delphi140
A trend that I have noticed over the last decade or so has been the move
away from small-scale development (and small shops in general) toward
large-scale development by the major tool vendors. Delphi seems to be
last tool that was designed to empower small teams (it is most definitely a
“force multiplier?. Hopefully, CodeGear will not develop a full-blown
case of "enterprise disease" and forget about small shops. Software
developers in small shops are full life-cycle professionals who wear many
hats. They cannot afford to be bogged down by a development model that
rigidly separates specification from development, UI design from UI coding,
client design from middleware design, application design from database
design et. al. This model may fly in large shops where people tend to be
pigeonholed into hyper-specialized, factory-like roles; however, in small
shops where software development is practiced as a combination of art and
science, it falls flat on its face. This is not to say that small shops do
not use development processes. It merely highlights the fact that small
shops tend to use very fluid processes that often change from project to
project, and that small teams tend to pick the shortest path between points
“a?and “b?because they are not bogged down by corporate politics. Small
shops exist because they can turn small-scale software projects around
faster than the big boys without the associated management overhead costs.
 
 

Re:Lack of Emphasis on Small-Scale Software Development Tools

Mark V. writes:
Quote
A trend that I have noticed over the last decade or so has been the move
away from small-scale development (and small shops in general) toward
large-scale development by the major tool vendors. Delphi seems to be
last tool that was designed to empower small teams (it is most definitely a
“force multiplier?. Hopefully, CodeGear will not develop a full-blown
case of "enterprise disease" and forget about small shops. Software
developers in small shops are full life-cycle professionals who wear many
hats. They cannot afford to be bogged down by a development model that
rigidly separates specification from development, UI design from UI coding,
client design from middleware design, application design from database
design et. al. This model may fly in large shops where people tend to be
pigeonholed into hyper-specialized, factory-like roles; however, in small
shops where software development is practiced as a combination of art and
science, it falls flat on its face. This is not to say that small shops do
not use development processes. It merely highlights the fact that small
shops tend to use very fluid processes that often change from project to
project, and that small teams tend to pick the shortest path between points
“a?and “b?because they are not bogged down by corporate politics.
I fully second what you've just said except
Quote
Small
shops exist because they can turn small-scale software projects around
faster than the big boys without the associated management overhead
costs.
Small shops can also turn medium-scale, so called "mission critical"
projects but still the above fully apply.
Didier
 

Re:Lack of Emphasis on Small-Scale Software Development Tools

"Didier Gasser-Morlay" <XXXX@XXXXX.COM>writes
Quote

I fully second what you've just said except

>Small
>shops exist because they can turn small-scale software projects around
>faster than the big boys without the associated management overhead
costs.

Small shops can also turn medium-scale, so called "mission critical"
projects but still the above fully apply.

For a small company, an application that contains 10K lines of code (LOC)
can be mission-critical (10K LOC is considered by most to be small-scale);
hence, the term is relative.
 

Re:Lack of Emphasis on Small-Scale Software Development Tools

Mark, I am slightly confused by your post as you seem to mix process
and tools in your characterisation.
Personally, I think the BDS products (CodeGear) in general don't have
much of the bloat that you can find in some so-called enterprise
solutions, and I hope that trend continues.
I do agree, though, that tool vendors (such as the ALM part of
Borland) tend to focus on larger groups or organisations, and a lot of
the theories around software development process definitively are
geared towards large organisations with clearly defined roles.
I have worked in a small shop for years, and when asked to describe my
team members, I'd usually call them "Swiss Army Knives" - ie
required to fill - and capable of filling - multiple roles as
architects, designers, coders, testers, doc-writers, project managers
- you name it.
We also experienced a "pigeon-hole-approach" from some of the central
people that came and said that "you will now be CMM rated", and it was
a interesting experience to try to come up with good process documents
to at least bring us up a CMM level or two).
It made us rethink some of the ways we worked and we realized that we
would actually benefit greatly by a little more structure, and a
little more planning and documenting before jumping into the coding
sessions (practically moving us from post-it's to version controlled
documents).
In my experience, small shops or single-man projects have nearly as
much to gain from good software process as any larger team, but the
problem usually lies in scaling down the process so that your
productivity don't become stifled by a large amount of
"administrative" tasks.
Even if you are a one-man-show, having a structure to how you approach
a project will greatly reduce the time you spend on "but that wasn't
what we agreed on" or "we didn't plan for that" - discussions.
In the small shop, it is not about skimping on your process role
assignments, but about creating lightweight methods of working that
are more task-oriented than role-oriented.
By changing your process to be task-oriented, you ensure that you have
sufficient "flow-control", but allow you to scale from a 1-man to a
5-man project, still using the same methods of working, but without
having to "pigeonhole" your staff to specific roles.
When you change your way or working into something more structured,
you may have to re-educate your clients and f.x. say: "Hey look, in
case we all die in a car-accident - would you prefer that we have the
system documented? You do understand that we actually will need to
spend project time on that as well, adding a small overhead to the
project timeline?"
Everything is a question of cost - timewise or moneywise - but
spending a little time, may end up saving you a lot of time.
Not having a process, will _not_ save you time and money, that is for
sure.
Using a few good tools, such as requirement gathering, issue tracking,
and version control systems will also help the little guys - not only
the larger teams.
Lars F.
"Mark V." <XXXX@XXXXX.COM>writes:
Quote
A trend that I have noticed over the last decade or so has been the move
away from small-scale development (and small shops in general) toward
large-scale development by the major tool vendors. Delphi seems to be
last tool that was designed to empower small teams (it is most definitely a
“force multiplier?. Hopefully, CodeGear will not develop a full-blown
case of "enterprise disease" and forget about small shops. Software
developers in small shops are full life-cycle professionals who wear many
hats. They cannot afford to be bogged down by a development model that
rigidly separates specification from development, UI design from UI coding,
client design from middleware design, application design from database
design et. al. This model may fly in large shops where people tend to be
pigeonholed into hyper-specialized, factory-like roles; however, in small
shops where software development is practiced as a combination of art and
science, it falls flat on its face. This is not to say that small shops do
not use development processes. It merely highlights the fact that small
shops tend to use very fluid processes that often change from project to
project, and that small teams tend to pick the shortest path between points
“a?and “b?because they are not bogged down by corporate politics. Small
shops exist because they can turn small-scale software projects around
faster than the big boys without the associated management overhead costs.





 

Re:Lack of Emphasis on Small-Scale Software Development Tools

Agreed. I have spent my life in small shops and the best
companies were those with processess, however simple.
They helped us as developers to design better code. I
recently had a trial ISO9000 audit and the auditor was
impressed with my personal processes over the guy next to me
who had none. (we don't have company processes .... yet)
Pete
"Lars Fosdal" <Lars(q)Fosdal.com>writes
Quote
In my experience, small shops or single-man projects have
nearly as
much to gain from good software process as any larger
team, but the
problem usually lies in scaling down the process so that
your
productivity don't become stifled by a large amount of
"administrative" tasks.
 

Re:Lack of Emphasis on Small-Scale Software Development Tools

I cut my teeth in the DoD world twenty-seven years (I spent over a decade in
the MIL-SPEC world), so I am fully aware heavyweight processes with their
associated long development cycles and management overhead (the CMM is a
product of DoD software engineering research). After a decade of that
nonsense, I knew that there had to be a better way to develop software.
Over time, I developed a basic lightweight method that does not suffer from
management bloat yet leaves behind enough artifacts to allow non-original
team members to maintain a product. I have seen far too many organizations
focus on the process at the expense of the product, which is why I tailor
the process the project.
 

Re:Lack of Emphasis on Small-Scale Software Development Tools

GrandmasterB writes:
Quote
imo, Borland forgot about the smaller shops and individual companies
quite a while ago. I am just hoping codegear will re-discover them.
That's what we are all about -- Developers.
--
Nick Hodges
Delphi Product Manager - CodeGear
blogs.borland.com/nickhodges
 

Re:Lack of Emphasis on Small-Scale Software Development Tools

"Mark V." <XXXX@XXXXX.COM>writes
Quote
"force multiplier"). Hopefully, CodeGear will not develop a full-blown
case of "enterprise disease" and forget about small shops. Software
imo, Borland forgot about the smaller shops and individual companies quite a
while ago. I am just hoping codegear will re-discover them.
 

Re:Lack of Emphasis on Small-Scale Software Development Tools

"Nick Hodges (CodeGear)" <XXXX@XXXXX.COM>writes
Quote
GrandmasterB writes:
>imo, Borland forgot about the smaller shops and individual companies
>quite a while ago. I am just hoping codegear will re-discover them.
That's what we are all about -- Developers.
Thats what makes me so hopeful about the future of Delphi, Nick!
 

Re:Lack of Emphasis on Small-Scale Software Development Tools

GrandmasterB writes:
Quote
Thats what makes me so hopeful about the future of Delphi, Nick!
We have no choice. We really don't have any products that /aren't/
focused at developers. ;-)
--
Nick Hodges
Delphi Product Manager - CodeGear
blogs.borland.com/nickhodges