├── Construction.md ├── Elaboration.md ├── Inception.md ├── Overview.md ├── README.md ├── Resources ├── AUPLifecycle.png ├── Construction2.jpg ├── Elaboration2.jpg ├── Inception2.jpg ├── LeanCanvas.png └── Transition2.jpg ├── ToolTrap.md └── Transition.md /Construction.md: -------------------------------------------------------------------------------- 1 | # III. Construction Phase 2 | 3 | ![](https://github.com/nopara73/ForeverAloneProgramming/blob/master/Resources/Construction2.jpg) 4 | The goal is to build a working software. 5 | 6 | # Time requirements 7 | At this point you should already know how much time this phase will consume, because previously you created a detailed schedule. 8 | 9 | # Workflow 10 | 11 | ## 1. (ProjectManagement) Prepare the project environment 12 | 13 | Ask for access to everything you might need to have. It is not ucommon that you have to wait for other people to take some action or for some processes to complete, so you probably will not have everything you need to build the product, but make the first steps to acquire them. 14 | 15 | ## 2. (Testing) Prepare your testing environment 16 | 17 | You are in the middle of developing a cross-platform application on Windows. You are not sure that one disk IO related function is going to give you the same results on Linux, but you did not set up a virtual machine in front, you said "I'll just set up a VM after I'm ready and test it." But now you are only 70% sure that function will work well. But meh, setting up a VM ideally takes half a day and it's always a hassle and I'm in the middle of something anyway. 18 | Now this is the situation you want to avoid. Do not be lazy and start preparing your testing environment now! 19 | 20 | After this step you might gain some new insight, if so, do not be rest and go adjust your test and cost models and your schedule. 21 | 22 | ## 3. (Implementation) Proof of concepts 23 | 24 | Sometimes you know what is possible. Sometimes you are just guessing what is possible. Sometimes you know exactly the thing what you want to do is possible, but are not sure if it is feasible. You are not sure you are able to create it under the timeframe it still worth it. 25 | 26 | Proof of concept work is very rewarding and can save you a lot of time in the long run. You do not need to do proof of concepts for every feature - just the ones you are not already confident you can do. If you have a project that needs to encrypt data in Java and send it to a web service written in C# that will decrypt it and you have not done this before you could do a very simple PoC that: 27 | 28 | Encrypts 'hello world' using Java. You can then copy that encrypted text into a little C# console app that decrypts it. If you can get that to come out as 'hello world' again - you have proven the concept and have a couple of functions that you can use and extend upon in your project later. This will remove the stress from the later stages of the project. You don't want to get to 80% project completion only to find out that you can't find a library that can encrypt a string in a format that you can decrypt it in later and end up having to write one yourself at such a late stage in the game. Better to do the trickiest things up front. 29 | 30 | |([Pragmatic Thinking](https://pragprog.com/book/ahptl/pragmatic-thinking-and-learning)) Stuck on a tricky problem?| 31 | |---| 32 | |1. Add sensory experience to engage more of your brain. Try fiddling with a paper clip [or with a ring or with your fingers] or some sort of tactile puzzle.| 33 | |2. Talk to an egg, a cat or if you can catch one a real human being. Try to explain the problem.| 34 | |3. If the egg does not understand you, you can try asking the oracle: [Oblique strategies](http://www.oblicard.com/) is a set of cards created by Brian Eno and Peter Schmidt used to break deadlocks in creative situations. | 35 | |4. If everything else fails, turn off your left-brain and let your right-brain work on it for a while. Step away from the computer and do something else, something routine, like go for a thinking walk. Bear the problem in mind, but do not actively think about it. You want your left brain to get bored with the routine, mundane task and tune out. Leaving the right brain free to present its findings.| 36 | 37 | |([Pragmatic Thinking](https://pragprog.com/book/ahptl/pragmatic-thinking-and-learning)) Stuck on a tricky document?| 38 | |---| 39 | |Every now and then you will encounter some documents those are essential for the success of your project. It might be some academic paper, some theory in a blog post, a stackoverflow answer, what have you. The point is you find it very difficult to understand. You also could not acquire that information from a more digestable source. Here you could try to apply some techniques, like SQ3R, combine it with a mind map.| 40 | 41 | Now get your architechture model and identify those parts what you feel problematic. You are going to implement proof of concepts for those hard parts. By knowing this adjust your schedule. 42 | Go on, study these subjects and create proof of concepts for them one by one. 43 | What you are doing here is called learning by synthesis. You are gaining new insights after every prototype you create. 44 | After every one of them evolve your architechture, test and cost models and schedule. 45 | 46 | ## 4. (Implementation) Code 47 | 48 | Finally we arrived to the point where we can do what we are really good at. Coding. Coding a well-defined architechture **without the distraction** of worrying about not being able to deliver the product. At this point we (think we) know exactly what our product will and will not do. At this point basically we only have to put the lego pieces together. 49 | 50 | Do not be distracted as you progress by any new features you think of - put them in the 'nice to have' list you made earlier and move on. You have to focus on the key deliverables at this stage. Once those are done you may well go back and see which of your 'nice to have' features you have time to add - but only when the key ones are delivered. 51 | 52 | It is also easy to get side-tracked by the introduction of new frameworks and ways to do what you have already committed to code. If you stopped every time a new release of a framework you are using came out and went back to upgrade what you have already done - or worse, abandon it and use a new one altogether - you will forever be in a game of catch up you can never win. 53 | 54 | Once you have picked a technology and framework set and started using it - stick to it until the project is completed. You can always go back to it and upgrade at a future date. Delivery of key features is more important than using the very latest release of something - your users will not really care what was used to deliver the solution - just that it was delivered and was delivered in a timely manner. 55 | 56 | |Tip| 57 | |---| 58 | |Here you have a unique opportunity to simultaneously boost both the quality and the speed of development of your product. Newbies code mainly with reasoning, experts code more with instinct. Newbies with the left brain, experts code with both brain. Of course this is a huge oversimplification, but meh, you get the point. The left brain is verbal/analytic/logical/synchronous/... and slow. The right is non-verbal/synthetic/intuitive/asynchronous/... and fast. This is the very section where you are the closest to be able to call yourself an expert (you have already figured out and implemented the hard parts). As an expert you can speed up your coding by utilizing more of your right brain, but it also enables you to not get stucked with the details, so you will be able to keep the big picture in mind, as a result build a well-balanced product. 59 | So how can we utilize more of our brain power, especially the right one? My method is **caffeine and lyiricless music, like [this battle tested playlist](https://www.youtube.com/watch?v=0r6C3z3TEKw&list=RD0r6C3z3TEKw#t=9). Also depending on how much you are willing to sacrifice amphetamine and methamphetamine can help a lot. Cocaine might work, too, but I am not sure. Check out [this discussion](https://www.quora.com/Would-coding-under-the-effects-of-cocaine-make-you-more-productive-Has-anybody-tried-it), might give you an idea. 60 | An other method could be pair programming. The one who codes is the left brain, lost in the details and the one who sits behind is the right brain, who keeps the context in mind, who's looking for patterns, who's thinking out of the box. Also note, the pairs should have the same level of expertise.| 61 | 62 | ## 5. (ProjectManagement) - Does your product satisfy the requirements? 63 | 64 | If so you can archive that document and your architecture modelling documents already, don't let them distract you anymore. 65 | 66 | It is worth checking this every few days or before you start a new piece of work and ask yourself 'am I still working on things that I set out at the start as my key requirements?'. If you find yourself being distracted because some little issue led you down a rabbit hole then you must pull your attention back to the task at hand. 67 | 68 | Developers are natural problem solvers. One minute you are writing code to save a file to disk and notice an odd way in which the date format you chose for the filename was being written out and three hours later you are deep in the code writing your own solution for a universal decimalised time protocol! If you find yourself doing things like this often it is worth setting an alarm every 30 minutes - 'look up and think!'. Maybe you didn't even need to use a date/time in the filename - you could have used something else and you just lost 3 hours because you are inquisitive. Break that habit if you can. 69 | 70 | ## 6. (Testing <-> Implementation) Pre-production testing <-> Bug fixing 71 | 72 | This section is self-explanatory. Test the product and fix the bugs you find. 73 | 74 | As developers we often test the app to see if it follows the logic we wrote into it. Our users may not know what our intention was with something we have added and so it is often useful to get friends or family to try using the app as well. Do not instruct them as they use it - just let them open it and see what they do. What seems obvious to you (because you wrote it) may not be obvious to everyone else. Remember - you will not be there to sit and explain how to use the app to everyone who downloads it. Observe people unfamiliar with it using it. 75 | 76 | ## 7. (ProjectManagement) Reach agreement on milestones 77 | 78 | |Template| 79 | |---| 80 | |[Milestones](https://docs.google.com/spreadsheets/d/1Du0ZyJNEk_0sKSfAKMe3H6vMxC6S8520Nag32If0BRY/edit?usp=sharing)| 81 | 82 | # [Next: IV. Transition Phase](https://github.com/nopara73/ForeverAloneProgramming/blob/master/Transition.md) 83 | -------------------------------------------------------------------------------- /Elaboration.md: -------------------------------------------------------------------------------- 1 | # II. Elaboration Phase 2 | 3 | ![](https://github.com/nopara73/ForeverAloneProgramming/blob/master/Resources/Elaboration2.jpg) 4 | The goal is to ensure that the team can actually develop a system that satisfies the requirements. 5 | 6 | # Time requirements 7 | This phase usually takes 1-7 days to me. 8 | 9 | # Workflow 10 | 11 | ## 1. (Modelling) Brainstorming 12 | 13 | **Try to see your project from a different perspective and keep collecting your ideas.** It is time to utilize our right brain again. 14 | There are advanced brainstorming techniques you might want to consider. If not, just do something unusual, make it fun, walk on the treadmill, smoke some marihuana, walk your dog, take a trip to Taiwan, whatever works for you, just keep some paper and pencil with you to collect your ideas about your project. 15 | For the smallest projects just do a quick minddump into a .txt. 16 | 17 | ### Idea triggers 18 | 19 | 1. Your own brain: Write down anything that crosses your mind. 20 | 2. High level requirements 21 | 3. Lean canvas 22 | 4. ChatGPT 23 | 5. External resources (Google) 24 | 25 | |Tip| 26 | |---| 27 | |Try to do some of the brainstorming away from the computer. When you sit at a computer it is tempting to open up a code editor and start to turn an idea into code. Before long you are deep in code and looking at one the one idea and broken the process of generating ideas. If you weren't writing code you might have had an even better idea if you had carried on thinking about it. For this reason it is often best to force yourself to leave your computer. Take a notebook out to a coffee shop, get some big pieces of A3 and some colored pens or a whiteboard and don't stop until you have ran out of ideas. | 28 | 29 | It is a lot easier to rub an idea off a whiteboard because you have just had a better one than it is to throw away hours of coding work when you realise the path you are taking is not the best one. 30 | 31 | When you finished you can archive the canvas, it would only be a distraction later. 32 | 33 | |Quote| 34 | |---| 35 | |Write drunk, edit sober.| 36 | |Not Hemingway| 37 | 38 | ## 2. (Modelling) Evolve the requirements 39 | You already have a high level understanding and consensus on what the system should and should not do. Bring your higher level requirements model to a lower level with the help of your previous brainstorming efforts. 40 | 41 | ## 3. (Modelling) Construct the architechture 42 | Outline an architechture that satisfies the requirements. The requirements and the brainstorming will be your help here. Chances are you will want to make some modifications on your requirements after this. That is fine, but do not overdo it. 43 | 44 | |Tip| 45 | |---| 46 | |To capture insight from your previous brainstorming efforts create a mindmap that helps you model your architechture. It should not be a formal document, like your architechture models, so whenever you finished creating your architechture, you can discard it.| 47 | 48 | ## 4. (Testing) Define tests in a high level! 49 | 50 | Your tests makes you confident the product you built is working correctly. 51 | The requirements and your brainstorming efforts will be enough hept to wrap up this part. 52 | 53 | ## 5. (ProjectManagement) Create a detailed schedule 54 | Based on the detailed requirements, tests and your previous brainstorming efforts evolve your high level schedule into a detailed one and add some extra time for ~not~ expected complications. 55 | 56 | You can now archive your brainstorming efforts and your detailed requirements document, because they are now be included in this document. 57 | 58 | ## 6. (ProjectManagement) Adjust costs 59 | With the help of the detailed schedule and detailed requirements you are now able to better calculate costs. 60 | 61 | ## 7. (ProjectManagement) Reach agreement on milestones 62 | |Template| 63 | |---| 64 | |[Milestones](https://docs.google.com/spreadsheets/d/1Du0ZyJNEk_0sKSfAKMe3H6vMxC6S8520Nag32If0BRY/edit?usp=sharing)| 65 | 66 | # [Next: III. Construction Phase](https://github.com/nopara73/ForeverAloneProgramming/blob/master/Construction.md) 67 | -------------------------------------------------------------------------------- /Inception.md: -------------------------------------------------------------------------------- 1 | # I. Inception Phase 2 | 3 | ![](https://github.com/nopara73/ForeverAloneProgramming/blob/master/Resources/Inception2.jpg) 4 | The goal is to identify the initial scope of the project. 5 | 6 | # Time requirements 7 | This phase usually takes 1 hour to 3 days to me depending on the communication overhead and the nature of the project. 8 | 9 | # Workflow 10 | Modelling, Implementation, Testing, Deployment, Project Management: the AUP terminology calls them **disciplines**, so do I. 11 | This document only includes the most relevant disciplines under each and every **phase**, but you may find yourself need to work on the other ones, which is fine. 12 | 13 | ## 1. (ProjectManagement) Gain general understanding over your project 14 | |Template| 15 | |---| 16 | |[Lean Canvas](https://docs.google.com/spreadsheets/d/1HTz5RHYRFxHEfB-0ZlRJPw5l_qQaYGIj4VRbATSVy0c/edit?usp=sharing)| 17 | 18 | First fill out a Lean Canvas. It forces you to think about the relevant questions you would otherwise skip. **Be superfical.** Feel free to leave some sections empty, do not get lost in details. Later it will be used as a reminder, not as a recipe. Also it will be soon discarded. 19 | 20 | ![](https://github.com/nopara73/ForeverAloneProgramming/blob/master/Resources/LeanCanvas.png) 21 | 22 | |Stop| 23 | |---| 24 | |**Do you have the freedom to choose what project you are going to work on?** If the answer is yes, take a step back and reconsider the one you currently have in mind. This is the perfect time to open that old folder where you have collected the milliondollar ideas you had during the years, but you have never actually bothered to review them. Look them up, quickly select 3 [to 7](http://phys.org/news/2009-11-brain-magic.html) with your right brain (instinctive decision making) and complete this first step for every one of your selected ideas. (Scratch lean canvases.) Finally choose the winner.| 25 | 26 | ## 2. (ProjectManagement) Setup project directory structure 27 | 28 | |Template| 29 | |---| 30 | |[Project Directory](https://drive.google.com/folderview?id=0B2Y-ddI1xJy7ZjY1SzE0Sk5MaGM&usp=sharing)| 31 | 32 | I organize the directory structure of my projects by disciplines. In every discipline folder I have an `_Archived` folder for those items I do not actively need anymore, therefore they would only be distractions. 33 | Now grab your lean canvas and put it in the ProjectManagement folder. 34 | 35 | Update: These days I just use GitHub and not following the disclipine folder structure too closely. 36 | 37 | ## 3. (Modelling) Define high level requirements 38 | What the system will and will not do? I usually just list these in a text file. 39 | 40 | ## 4. (ProjectManagement) Estimate cost and schedule 41 | 42 | At this point it is fine to give a gut feeling estimation on how long every phase will take. 43 | You can get a more accurate estimation for the Construction (and Deployment) phase by giving a time estimation to every high level requirements you defined. 44 | Regarding the costs, try to identify the main ones. But remember the motto of this phase: do not get lost in details. 45 | 46 | ## 5. (ProjectManagement) Determine project feasibility 47 | 48 | > (AUP) Your project must make sense from technical, operational, and business perspectives. In other words, you should be able to build it, once it's deployed you should be able to run it, and it should make economic sense to do these things. If your project isn't feasible, it should be cancelled. 49 | 50 | ## 6. (ProjectManagement) Reach agreement on milestones 51 | |Template| 52 | |---| 53 | |[Milestones](https://docs.google.com/spreadsheets/d/1Du0ZyJNEk_0sKSfAKMe3H6vMxC6S8520Nag32If0BRY/edit?usp=sharing)| 54 | 55 | To exit any phase participants must agree the project completed the current phase's milestones. 56 | This should not be taken lightly. Do you find it catastrophic when your whole project changes nearing its end, because the customer "made a little modification"? Well, agreement on the milestones will not eliminate this risk, but certainly will lower the chance of it happening. 57 | Keep in mind, not only the stakeholders have to agree, the participants, too. You do not want to end up like this guy: 58 | 59 | https://www.youtube.com/watch?v=BKorP55Aqvg 62 | 63 | 64 | # [Next: II. Elaboration Phase](https://github.com/nopara73/ForeverAloneProgramming/blob/master/Elaboration.md) 65 | -------------------------------------------------------------------------------- /Overview.md: -------------------------------------------------------------------------------- 1 | > [The Agile Unified Process (AUP)](http://www.ambysoft.com/unifiedprocess/agileUP.html#Overview) is a simplified version of the Rational Unified Process (RUP). It describes a simple, easy to understand approach to developing business application software using agile techniques and concepts yet still remaining true to the RUP. 2 | 3 | I have stolen the skeleton of AUP. This crime was an organic process, I had been using AUP for so long, at so many projects that one day I realized I am no longer doing it anymore. This is how Forever Alone Programming borned. 4 | 5 | # Overview 6 | ![](https://github.com/nopara73/ForeverAloneProgramming/blob/master/Resources/AUPLifecycle.png) 7 | 8 | This graph depicts the simplified lifecycle of AUP. 9 | Start your software at the Inception phase and "finish" it with the Transition phase. During each and every phase pay sufficent attention to the other dimension, which determines the type of work you do: Modelling, Implementation, Testing, Deployment, Project Management. The amount of attention you ideally pay on these is indicated by the colored lines of the graph. 10 | 11 | ## [Phases](http://www.ambysoft.com/unifiedprocess/agileUP.html#Serial) 12 | 1. [Inception](https://github.com/nopara73/ForeverAloneProgramming/blob/master/Inception.md): The goal is to identify the initial scope of the project. 13 | 2. [Elaboration](https://github.com/nopara73/ForeverAloneProgramming/blob/master/Elaboration.md): The goal is to ensure that the team can actually develop a system that satisfies the requirements. 14 | 3. [Construction](https://github.com/nopara73/ForeverAloneProgramming/blob/master/Construction.md): The goal is to build working software. 15 | 4. [Transition](https://github.com/nopara73/ForeverAloneProgramming/blob/master/Transition.md): The goal is to validate and deploy your system into your production environment. 16 | 17 | # [Next: I. Inception Phase](https://github.com/nopara73/ForeverAloneProgramming/blob/master/Inception.md) 18 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Forever Alone Programming 2 | 3 | Software Development Methodology for Solo Programmers and Small Teams 4 | 5 | ## Table Of Contents 6 | 7 | [Overview](https://github.com/nopara73/ForeverAloneProgramming/blob/master/Overview.md) 8 |    [1. Inception](https://github.com/nopara73/ForeverAloneProgramming/blob/master/Inception.md) 9 |    [2. Elaboration](https://github.com/nopara73/ForeverAloneProgramming/blob/master/Elaboration.md) 10 |    [3. Construction](https://github.com/nopara73/ForeverAloneProgramming/blob/master/Construction.md) 11 |    [4. Transition](https://github.com/nopara73/ForeverAloneProgramming/blob/master/Transition.md) 12 | [Beware the Tool Trap](https://github.com/nopara73/ForeverAloneProgramming/blob/master/ToolTrap.md) 13 | 14 | ## Motivation 15 | I had been struggling to find any lean software development methodology that can work for solo programmers. 16 | Whenever I researched the topic it was not uncommon to find testimonies like ["I held a progress meeting with myself over a one-man burn down chart every morning"](http://programmers.stackexchange.com/questions/59713/best-development-methodology-for-one-person). 17 | 18 | |Quote| 19 | |---| 20 | |I know something's coming. Something big. Like a train, and all I want is to jump on board, but it's getting faster and faster and I'm terrified that I'm gonna miss it. 21 | Ryan, Halt and Catch Fire| 22 | 23 | [Programming motherfucker](http://programming-motherfucker.com/), [cowboy programming](https://en.wikipedia.org/wiki/Cowboy_coding) are what developers naturally [choose](https://www.youtube.com/watch?v=x4vXGJ19Izw) when they finally find the time to work on a hobby project that they are enthusiastic about. This of course if you are not the [very best](https://www.youtube.com/watch?v=zGkcnUy3l-c) expert with lots of [stamina](https://www.youtube.com/watch?v=QueWMFokFRw) will probably lead you to unfinished projects and frustration. Sadly I was never able to fully get the hang of the today popular [agile methodologies](https://en.wikipedia.org/wiki/Agile_software_development), no matter how much I tried. So I went back in time to university, where the infamous, traditional [Rational Unified Process](https://en.wikipedia.org/wiki/Rational_Unified_Process) had been forced down our throats, way before we ever acquired any software development experience. Despite the bad timing, I liked it. This gave me the first insight to what is going on in an office. Several years ago this thread of thoughts led me to [Agile Unified Process](http://www.ambysoft.com/unifiedprocess/agileUP.html) (AUP) and started to use it in my solo projects. 24 | 25 | |Tip| 26 | |---| 27 | |If nobody supervises you, you have to supervise yourself.| 28 | 29 | Time flew, things changed, books were read, experience was gained and I found myself using a reduced, lean, flexible and completely raped version of AUP. 30 | Now, the time has finally came to armor myself with a guide on this development process. 31 | 32 | ## Disclaimer: 33 | I am not an expert on the topic, I just outline a practical roadmap that works better for me, than anything else I tried before. 34 | 35 | ## Before you start 36 | 37 | ### Ask yourself: "Is FAP right for me?" 38 | - If you do not enjoy autonomy on what project you do and how you do your project, it is not for you. I mean you should not be a slave in a master-slave relationship with any person or company, you should at least be a partner. 39 | -"I give you $1,000 to build this website for me." - FAP is not for you. 40 | -"I have $1,000, would you like to build a website with me?" - FAP is for you. 41 | - If you have more than a couple of people working for you, it is not the best way to go either. 42 | - If you have no experience in the skills your project is expected to be built upon, you would find this method confusing and I do not think is suitable for you. 43 | - The other side of the scale is excluding too. If you are the absolute expert on the field, do not bother with FAP, you have already developed practices those are more suitable for you. 44 | 45 | ### Read: [Beware the Tool Trap](https://github.com/nopara73/ForeverAloneProgramming/blob/master/ToolTrap.md) 46 | 47 | |Tip| 48 | |---| 49 | |Are you sharing my obsession with books, online talks and similar educational and inspiring material? If so, chances are they leave a guilty feeling in you, because you fail to apply the information in practice. The reason is because they are not instantly applicable. You have to apply them at the right time, the right place, in proper context. If you are anything like me and the most important part of your life is when you are working on something you care about, **consider forking this repo to have your own version and improve upon it** every time you gain a new insight. And the guilty feeling will evaporate.| 50 | 51 | # [Next: Overview](https://github.com/nopara73/ForeverAloneProgramming/blob/master/Overview.md) 52 | -------------------------------------------------------------------------------- /Resources/AUPLifecycle.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/nopara73/ForeverAloneProgramming/c8a20bfe8c7137439b51e16b69d515a72e6066f6/Resources/AUPLifecycle.png -------------------------------------------------------------------------------- /Resources/Construction2.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/nopara73/ForeverAloneProgramming/c8a20bfe8c7137439b51e16b69d515a72e6066f6/Resources/Construction2.jpg -------------------------------------------------------------------------------- /Resources/Elaboration2.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/nopara73/ForeverAloneProgramming/c8a20bfe8c7137439b51e16b69d515a72e6066f6/Resources/Elaboration2.jpg -------------------------------------------------------------------------------- /Resources/Inception2.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/nopara73/ForeverAloneProgramming/c8a20bfe8c7137439b51e16b69d515a72e6066f6/Resources/Inception2.jpg -------------------------------------------------------------------------------- /Resources/LeanCanvas.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/nopara73/ForeverAloneProgramming/c8a20bfe8c7137439b51e16b69d515a72e6066f6/Resources/LeanCanvas.png -------------------------------------------------------------------------------- /Resources/Transition2.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/nopara73/ForeverAloneProgramming/c8a20bfe8c7137439b51e16b69d515a72e6066f6/Resources/Transition2.jpg -------------------------------------------------------------------------------- /ToolTrap.md: -------------------------------------------------------------------------------- 1 | Excerpt form the book: [Pragmatic Thinking and Learning](https://pragprog.com/book/ahptl/pragmatic-thinking-and-learning) 2 | 3 | There has been much written on the role of tools, formal models, 4 | modeling, and so on, in software development. Many people claim 5 | that UML and model-driven architecture (MDA) are the future, just 6 | as many people claimed that RUP and CMM process models were 7 | the salvation of the industry. 8 | 9 | But as with all silver-bullet scenarios, people soon found out that 10 | it just ain’t that easy. Although these tools and models have their 11 | place and can be useful in the right environments, none of them 12 | has become the hoped-for universal panacea. Worse yet, the misapplication 13 | of these approaches has probably done far more damage 14 | than good. 15 | 16 | Interestingly enough, the nursing profession 17 | had similar problems with regard to 18 | the use of tools and formal models. They 19 | had fallen into the same trap that many 20 | architects and designers fall for: forgetting that **the model is a tool, not a mirror.** 21 | 22 | Rules cannot tell you the most relevant activities to perform in a 23 | given situation or the correct path to take. They are at best “training 24 | wheels”—helpful to get started but limiting and actively detrimental 25 | to performance later. 26 | 27 | Dr. Deborah Gordon contributed a chapter to Benner’s book, in 28 | which she outlines some of the dangers of overreliance on formal 29 | models for the nursing profession. I’ve reinterpreted her sentiments 30 | with the particulars of our profession, but even the original version 31 | will sound pretty familiar to you. 32 | 33 | *** 34 | 35 | **Confusing the model with reality** 36 | A model is not reality, but it’s easy to confuse the two. 37 | There’s the old story of the young project manager, where his 38 | senior programmer announced she was pregnant and going to 39 | deliver during the project, and he protested that this “wasn’t 40 | on the project plan.” 41 | 42 | **Devaluing traits that cannot be formalized** 43 | Good problem-solving skills are critical to our jobs, but problem 44 | solving is a very hard thing to formalize. For instance, 45 | how long can you just sit and think about a problem? Ten 46 | minutes? A day? A week? You can’t put creativity and invention 47 | on a time clock, and you can’t prescribe a particular technique 48 | or set of techniques. Even though you want these traits on your team, you may find that management will stop valuing 49 | them simply because they cannot be formalized. 50 | 51 | **Legislating behavior that contradicts individual autonomy** 52 | You don’t want a bunch of monkeys banging on typewriters 53 | to churn out code. You want thinking, responsible developers. 54 | Overreliance on formal models will tend to reward herd 55 | behavior and devalue individual creativity. 56 | 57 | **Alienating experienced practitioners in favor of novices** 58 | This is a particularly dangerous side effect. By targeting your 59 | methodology to novices, you will create a poor working environment 60 | for the experienced team members, and they’ll simply 61 | leave your team and/or organization. 62 | 63 | **Spelling out too much detail** 64 | Spelling out the particulars in too much detail can be overwhelming. 65 | This leads to a problem called infinite regress: as 66 | soon as you make one set of assumptions explicit, you’ve 67 | exposed the next level of assumptions that you must now 68 | address. And so on, and so on. 69 | 70 | **Oversimplification of complex situations** 71 | Early proponents of the Rational Unified Process (and some 72 | recent ones) cling to the notion that all you have to do is “just 73 | follow the process.” Some advocates of Extreme Programming 74 | insist all you need to do is “just follow these twelve—no wait, 75 | maybe thirteen—practices” and everything will work out. Neither 76 | camp is correct. Every project, every situation, is more 77 | complex than that. Any time someone starts a sentence with 78 | “All you need to do is...” or “Just do this...,” the odds are they 79 | are wrong. 80 | 81 | **Demand for excessive conformity** 82 | The same standard may not always apply equally in all situations. 83 | What worked great on your last project may be a disaster 84 | on this one. If Bob and Alice are hugely productive with 85 | Eclipse, it might wreck Carol and Ted. They prefer IntelliJ or 86 | TextMate or vi. 87 | 88 | **Insensitivity to contextual nuances** 89 | Formal methods are geared to the typical, not the particular. 90 | But when does the “typical” really ever happen? Context 91 | is critical to expert performance, and formal methods tend 92 | to lose any nuances of context in their formulations (they 93 | have to; otherwise, it would take thousands of pages just to 94 | describe how to get coffee in the morning). 95 | 96 | **Confusion between following rules and exercising judgment** 97 | When is it OK to break the rules? All the time? Never? Somewhere 98 | in between? How do you know? 99 | 100 | **Mystification** 101 | Speech becomes so sloganized that it becomes trivial and 102 | eventually loses meaning entirely (for example, “We’re a 103 | customer-focused organization!”). Agile methods are fast losing 104 | effectiveness because of this very problem. 105 | 106 | *** 107 | 108 | Formal methods have other advantages and uses but are not helpful 109 | in achieving these goals. Although it may be advantageous 110 | to establish baseline rules for the lower skill levels, even then 111 | rules are no substitute for judgment. As ability to judge increases, 112 | reliance on rules must be relaxed—along with any rigid institutional 113 | enforcement. 114 | Don’t succumb to the false authority of a tool or a model. **There is 115 | no substitute for thinking.** 116 | -------------------------------------------------------------------------------- /Transition.md: -------------------------------------------------------------------------------- 1 | # IV. Transition Phase 2 | 3 | ![](https://github.com/nopara73/ForeverAloneProgramming/blob/master/Resources/Transition2.jpg) 4 | The goal is to validate and deploy your system into your production environment. 5 | 6 | # Time requirements 7 | How long do you think it will take? Double it and you have a better estimation. 8 | 9 | # Workflow 10 | 11 | ## 1. (Deployment) Finish documentation 12 | 13 | You may noticed I did not forced you to create any documents without an instant purpose. This is not a coincidence. One reason is because creating documentation for the shake of documentation is a waste of time, but also different projects require different type of documents. User guides, installation, deployment, maintenance instructions, and so on. Chances are you have been already creating some of these. Dig the relevant ones up, organize and revise them. 14 | 15 | ## 2. (ProjectManagement <-> Implementation) Acquire stakeholder acceptance and/or revise your PMF fit 16 | 17 | Other developer oriented methodologies tend to omit the marketing aspect of product development. It is mainly because the creators are used to developing internal systems. But what if you are the CEO, CTO and CMO of your company? 18 | You have to deal with the marketing by yourself. It also gives you the unique opportunity to achieve Product Market Fit (PMF). 19 | If that is the case and you are going to handle the marketing, create a marketing plan now and adjust the product accordingly. 20 | In case you are not your own boss and somebody hired you she/he will inevitably seek to make modifications. Gather all of your social engineering skills to gain her/his acceptance, but keep in mind the customer's ultimate goal with annoying you is to achieve product market fit. 21 | 22 | ## 3. (Deployment <-> Implementation) Beta-testing 23 | 24 | Sometimes you want to gain customer feedback before going all out. During beta testing a sampling of the intended audience tries the product out and you adjust the product, based on the insights, gained by feedbacks. 25 | 26 | At the end of beta testing do not forget to finalize the documentation and update your marketing plans. 27 | 28 | ## 6. (ProjectManagement) Reach agreement on milestones 29 | 30 | |Template| 31 | |---| 32 | |[Milestones](https://docs.google.com/spreadsheets/d/1Du0ZyJNEk_0sKSfAKMe3H6vMxC6S8520Nag32If0BRY/edit?usp=sharing)| 33 | 34 | ## 7. (Deployment) Deploy the system into production 35 | 36 | ## 8. (Deployment) Start executing your marketing plan 37 | 38 | ## 9. (Deployment) Maintain the software 39 | 40 | Maintenance happens by the people who are responsible of operating the system and the people who are responsible of supporting the system. 41 | 42 | Be sure to provide a way for users to provide you with feedback - either via your website or (if possible) directly from your app. Whilst you may be working on adding feature X to your software because you think the users will want it they may all be crying out for feature Y - and if there is no easy way for them to let you know you are missing out! 43 | --------------------------------------------------------------------------------