The name is a reminder that we reach for the impossible,
- because software is never complete. So please focus
+ because software is never complete. So please focus 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.
Well, several reasons brought me here.
Highest aim of CP is the conscience the code is produced with. As result you get
=item a superb overall user experience
=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 of the project go into one repository.
-=item Before implenenting a functionality that isn't just a lib call write a prototype.
-=item Before implementing a use case, write a prototype.
-=item These two types of prototypes stay in their respective dir/branch.
-=item After the prototype you write the docs, then the code and then the test.
-=item When implementing a feature, do also the docs, test, GUI and the configs.
+=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 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 desinged to deliver
+that high standard, without packing too much burden on the programer. Our
+development models knows several decoupled, well defined stages - so we only care
+about one goal at a time. Additionally we reduce duplicate work and duplicate data
+where possible and enforcing the quality of communication and self reflection.
+For instance all aspects of a feature are imlepement at once - when details are
+And Complete Programming is to a great deal caring about the outcome, meaning the overall user experience.
+That includes things like:
+ * does everything work smoothly
+ * does it look pleasent
+ * are there feature holes
+ * how long does it take to find a feature
+ * how good and coprehensive
+in our own mind things are easy.
+We want to create this awesome new program that is able of doing such and such
+and it will be exactly want we want. Only we are capable to do that.
+Just in practice things get hairy. Dirty overcomplex code nasty bugs,
+unloved pending peripheral work .. and so on. You probably been there done that
+Thats how it always starts right
+ since all the rest will be just about
+ practical work. But that fine because we love to program. Especially when its
+ creative and we feel productive - without all that life sucking overhead.
+ And of course the result should be perfect. Problem is, we don't get there by
+ just hacking away. Noone I met has that kind of self discipline. But a framework
+ of rules that still allows free dabbling and protects it from damaging a solid
+ code base would be still a sufficient amount of fun. And wouldn't it be nice if that
+ framework doesn't enforce but actually reduces duplicate work and helps us to
+ catch our errors early when fixing is much easier and less painful.
+ Sounds like I am still hiding something. Yes by hacking I didn't ment necessarily
+ Some maybe don't like to hear that becasue they only consider
+ writing documentation as something productive or enjoyable.
+ "Working software over comprehensive documentation" was one of the main points
+ in the agile manifesto.
+ there are aspects about Complete
+ Programming that at first sound aweful to many. Bu they actually aren't, just
+ changing habits maybe will need a little discipline but the results might be
+ Like in art trends or other social dynamics, extreme programming
+ acknowledges the shortcomings of the previously popular waterfall methods.
+ But while running in the opposite direction it created new ones or left several
+ unfixed. Meanwhile sensible people tried to do the right thing anyway and dind't
+ followed any recipe slavishly.
+ * documentation (user, programmer, comments)
-First step: should be writing down the approximate feature set, save and commit it.
-Its now part of the documentation and also serves as the todo.
+As said here is not much planning involved because of reasons already stated.
+Nontheless there are severel things to be decided at start.
-Second step: think what what technologies, languages, libs, os, other tools
-you should select and procede as in step one.
-Spend some minutes on fallback alternatives or areas you might expand into.
-Also consider now what kind of team could solve that task.
+ * general vision of the program with use cases
+ * on which technology to rely (with fallback alternatives)
+ * what team we need (especially in corporate setting)
+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 important thing during that phase is to adapt complete programming.
+First you might commit this text as part part of the developers documentation,
+that should reflect briefly all the processes involved. Than you alter details,
+since you program maybe has no GUI, or config, or you will need more branches.
+Maybe will tweak the role of tests becasue by all means these are not the ten
+commandments. And please give us a feedback when your tweaks seem to work well.
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
Coprogrammer will understand you far better, you spot practical design flaws
much faster and you will feel better, because you did already something productive.
-Rough drafts are all you need in all three cases.
-But as soon your are just somewhat sure about more details write them down, commit.
+2 tapes: functional and use case
- * documentation (user, programmer, comments)
see more in L<lib/Kephra/Versioning.pod>