 |
| Software Engineering Series |
Besides equating the programming process with a programmer’s capabilities, minimizing the importance of programming and programmers’ skills in the whole process (see previous post), there are several other misconceptions about programming that influence process' outcomes.
Having a deep knowledge of a programming
language allows programmers to easily approach other programming languages, however
each language has its own learning curve ranging from a few weeks to half of year
or more. The learning curve is dependent on the complexity of the languages
known and the language to be learned, same applying to frameworks and
architectures, the scenarios in which the languages are used, etc. One unrealistic
expectation is that the programmers are capablle of learning a new programming language or
framework overnight, this expectation pushing more pressure on programmers’
shoulders as they need to compensate in a short time for the knowledge gap. No, the programming
languages are not the same even if there’s high resemblance between them!
There’s lot of code available online, many
of the programming tasks involve writing similar code. This makes people assume
that programming can resume to copy-paste activities and, in extremis, that there’s no creativity into the act of programming. Beside the fact that using others’ code comes with certain copyright
limitations, copy-pasting code is in general a way of introducing bugs in software. One
can learn a lot from others’ code, though programmers' challenge resides in writing
better code, in reusing code while finding the right the level of abstraction.
Programming is not only about writing code.
It involves also problem-solving abilities, having a certain understanding about the business
processes, in which the conceptual creativity and ingenuity of design can prove
to be a good asset. Modelling and implementing processes help programmers gain
a unique perspective within a business.
For a programmer the learning process never
stops. The release cycle for the known tools becomes smaller, each
release bringing a new set of functionalities. Moreover, there are always new frameworks,
environments, architectures and methodologies to learn. There’s a considerable
amount of effort in expanding one's (necessary) knowledge, effort usually not planned in projects
or outside of them. Trainings help in the process, though they hardly scratch
the surface. Often the programmer is forced to fill the knowledge gap in his free time. This
adds up to the volume of overtime one must do on projects. On the long run it
becomes challenging to find the needed time for learning.
In resource planning there’s the tendency
to add or replace resources on projects, while neglecting the influence this
might have on a project and its timeline. Each new resource needs some time to accommodate
himself on the role, to understand project requirements, to take over the work
of another. Moreover, resources are replaced on project with a minimal or even
without the knowledge transfer necessary for the job ahead. Unfortunately, same behavior
occurs in consultancy as well, consultants being moved from one known functional area
into another unknown area, changing the resources like the engines of different types of car, expecting that everything will work as magic.
No comments:
Post a Comment