=head1 Complete Programming
This document describes the method the Kephra editor is developed with.
Its highest aim is to have at all times a usable program with the
highest quality at all levels while still allowing programming be fun.
The name is a reminder that we reach for the impossible,
because software is never complete. So please focus, enjoy and relax.
I strongly dislike strict rules imposed on me and make fun of people that
produce theories with three letter acronyms that try to be the answer to everything.
But now I am standing here, trying to "sell" you yet another programming methodology.
That IS irony, isn't it? At least I use only two letters beause this is more important.
=head3 Basic Ideas
Well, several reasons brought me here.
1) I always wanted a sane balance between the old bureaucratic waterfall method,
and the modern extreme or agile programming, which is a bit too shortsighted,
and accumulates additional work as the project grows.
It should be possible to combine sound planning, practicability and quick results.
2) The awesome powers of prototypes are known but still not fully used.
3) Documentation coverage and depth matters a great deal and writing it
would also help the developer.
4) Writing tests is no silver bullet and is used for several competing purposes.
5) All methodologies I know of overlook several aspects of the product.
That includes even "documentation driven development",
which gave important impulses for the creation of CP.
6) New tools like hg or git allow new workflows which solve pending problems.
=head3 Main Goal
Highest aim of CP is the conscience the code is produced with. As result you get
=item a superb overall user experience
=item quality code
=item transparent project planning and status
=item room for experiments and changes without trouble
=item Every action has a productive and lasting (yet changable) result.
=item All code, data and metadata forms one project and goes into one repository.
=item They are all equally important.
=item Don't plan new feature, document it and what is needed to implement it.
=item New low level functionalities are developed and optimized in a prototype.
=item User level features too.
=item When implementing a feature, envision and do all aspects at once.
=item Only after something went into the main programm a test is needed.
=item We rely heavily on branches and decentral version control systems.
Lets start with a small meditation, because Complete Programming (CP) relies on
embodying a mindset that is still a bit alien to some. In one word it is holistic -
meaning seeing the full (complete) picture. That includes the users view,
programmers view and project managers view. Maybe even the designers view.
That sounds demanding, but you do it already when you really care about something.
As a consequence we count an ugly icon, missing documentation or an badly
designed internal API equally as a bug as a crashing function. CP is designed
to deliver that high standard, without packing too much burden on the programer.
Firstly: all aspects of a feature are planned at once - so their in tune with
each other. And they are also imlepement together - when details are fresh in
your memory. And since that also includes comments and documentation, you will
later know what you have done and why, saving a lot of guesswork.
Secondly: we reduce duplicate work and duplicate data where possible. CP will
compel you to think about a problem several times, to ensure you unerstood its
implications. But every time you will produce a useful part of the project.
Every vital information goes into one well structured repository (again holistic!).
Your highten clarity and low duplication also improves the quality of communication,
that will mainly take place through your common work (repository).
And thirdly: as hinted, the development model knows several decoupled, well
defined stages that correlate with the natural flow of ideas into materialisation.
Any stage has only one goal that is set according to its possibilities and with
respect to its unavoidable limits. Thats one reason why work gets less heavy.
(Joyful labour is important to get the deeper focus we need to achieve quality.)
The other reason: some stages allow free minded hacking and bring back the fun
you missed for so long. (Play and work balanced - that is holistic too).
The next chapter describe each stage in detail.
As said here is not much planning involved because of reasons already stated.
Nontheless there are severel things to be decided at start.
* general vision of the program with use cases
* on which technology to rely (with fallback alternatives)
* what team we need (especially in corporate setting)
* small roadmap
Write that down (except point 3) by the rules given in the next chapter.
In CP that is already considered coding since you write documentation.
The development cycles have already began. So please don't overdo it,
since everything can be overwritten when other information become available.
You might protest that your boss (that needs to read the summary of that newly
proposed undertaking) requires a different style or format. Well you both are
also parts of the project have to form a complete whole. Documentation should
be written so clear that even business people can understand it and the manager
can make much better decisions when he knows what you actually do.
Duplication leads to unproductive work and enbles miscommunication.
Managers usually understand such arguments.
One last, but very important thing during that phase - adapt complete programming.
First you might commit this text as part of the developers documentation,
that should reflect briefly all the processes involved. Than you alter details,
because your program maybe has no GUI, or config, or you will need more branches.
Maybe want to tweak the role of tests - by all means these are not the ten
commandments. And please give us a feedback when your tweaks seem to work well.
As you saw, we start always by writing documentation, forwhy its usually better
to think before doing anything. And putting it down helps you reflect on it.
Knowing that it will be read by programmer or users should add pressure,
or let's say serious focus. But please dont overdue it. Just stick to things
you're sure about and are plannable right now and be sketchy with the rest.
Than start crafting placeholder code or prototypes that reflect what you just wrote.
Because we see code, docs and everything else as one entity, pursuing one goal.
With bad docs the program is much less usable and enjoyable, hence missing,
outdated or badly written docs are bugs and should be treated as such.
Many hate writing docs, because its a lot of work when doing it all at once.
And its even more work when it describes details you already forgot about or
were developed by others. But if you see it as part of the codebase and a
valuable tool for communicating with the back of your head and your coworkers,
it will become a time saver. And since you always make some kind of plan,
you have now to write it down only once, only with more conscience (see L<Main Goal>).
The perceived quality of the program increases hugely.
The reason why docs are considered in the "agile" field as less important,
("Working software over comprehensive documentation")
because they confuse it with overhead. In "complete programming" we mostly give
our managers highl level docs as written for the user. That means we have almost
no overhead and the docs have to be so good that even mangers an understand them.
To managers its also better when they know that you actually
types of documentation
easy to fork
2 tapes: functional and use case
put into code
just seperate starter
* documentation (user, programmer, comments)
* logic (main program)
* supply libs
Third Step: Imagine some rought logical structures the program is built upon.
Use UML only if you have to, better are empty classes / packages / module with
almost empty meths / subroutines. Inserts comments that say what goes where.
Coprogrammer will understand you far better, you spot practical design flaws
much faster and you will feel better, because you did already something productive.
write after code
and its stable
its after thought
see more in L<lib/Kephra/Versioning.pod>
parts to do