tag:blogger.com,1999:blog-267524312024-03-12T17:36:33.720-07:00survic's blog on Programming or Enterprise Computing<b> reminder: to search this blog, use SEARCH THIS BLOG at the top </b>survichttp://www.blogger.com/profile/05621218802357307115noreply@blogger.comBlogger202125tag:blogger.com,1999:blog-26752431.post-19215656718513603352009-05-18T14:53:00.005-07:002009-05-18T15:20:42.291-07:00Silverlight, ActiveX, AIR, Sandbox, and Offline1. Silverlight 2 stand-alone with ActiveX<br /><br />Silverlight 2 stand-alone html application (it is better to change the .html to .hta, the host is MSHTA.EXE), using javascript (file mode, so full trust) to call activeX (note that this approach is not cross platform).<br /><br /><a href="http://www.galasoft.ch/mydotnet/articles/article-2008042301.html">http://www.galasoft.ch/mydotnet/articles/article-2008042301.html</a><br /><a href="http://geekswithblogs.net/lbugnion/archive/2008/04/24/silverlight-running-standalone-full-trust-applications.aspx">http://geekswithblogs.net/lbugnion/archive/2008/04/24/silverlight-running-standalone-full-trust-applications.aspx</a><br /><br /><a href="http://blogs.microsoft.co.il/blogs/tamir/archive/2008/04/27/how-to-make-silverlight-be-air.aspx">http://blogs.microsoft.co.il/blogs/tamir/archive/2008/04/27/how-to-make-silverlight-be-air.aspx</a><br /><br />2. If the requirement is not offline, but to access files and ports, can use special ActiveX with javascript.<br /><br />3. Silverlight 3 OOB is not that useful<br /><br />--a. Silverlight 3 OOB is within browser sandbox, so, cannot access file etc.<br />--b. Silverlight 3 OOB (out of browser) cannot use html/javascript, so, it cannot be used together with the hta technique.<br /><br /><br />4. The above is not cross-platform (but for intranet, it is good that it does not need to install any “extra” stuff), for that, AIR is the way to go.<br /><br />5. Is it possible to use both AIR and pure Silverlight3? Not sure: (i) Can Silverlight3 be invoked from AIR? (ii) Silverlight cannot invoke AIR (sandbox), but it can save to the storage, and AIR can poll that. (iii) Silverlight cannot mash up AIR. (iv) AIR perhaps can mash up Silverlight. As a result, it looks like we can use AIR as the “shell” (base application), and invoke Silverlight screens (because it is in sandbox, so, it does not know other instances; so, the shell must be very lightweight and can be instantiated many times without performance issues). <br /><br />6. For Serial port etc, it needs a generic "proxy" that translates port to socket(). Javascript can then use socket. Note that this makes it not portable. So, if we do not need offline feature, then, we can simply develop small ActiveXes to access things out of the sandbox, and use Silverlight for UI, and use javascript to glue things togother.survichttp://www.blogger.com/profile/05621218802357307115noreply@blogger.com115tag:blogger.com,1999:blog-26752431.post-18956860000299507522009-05-18T07:31:00.004-07:002009-05-18T08:20:03.764-07:00The so-called process is actually parts of the architecture, and the so-called architecture is actually parts (use cases) of the processThe so-called process is actually parts of the architecture, and the so-called architecture is actually parts (use cases) of the process. Both of them are about three things:<br /><br />1. use cases<br />2. data fields<br />3. architecture use cases (transaction-failure handling; network-performance plus offline client, reports, direct database jobs; security, auditing)<br /><br /><br />Key understanding:<br /><br />1. use cases: this is the art. The core of the art is to find the representative use cases so that they are only a few but cover all data fields. Also note that they need to be described using UI terms, however, they are use cases -- using UI language and eventually doing UI design do not mean you need to jump on UI design in the very beginning.<br /><br />2. data fields: this is the science. All computing are based on this, including object oriented programming -- the core of domain model is in data model. However, note that this does not mean you need to jump on database physical design in the very beginning.<br /><br />3. Architecture use cases. They are use cases. "Architecture" is not magic; they must be organized in use cases. Users can and must understand them -- that is, if you organize them in use cases.survichttp://www.blogger.com/profile/05621218802357307115noreply@blogger.com2tag:blogger.com,1999:blog-26752431.post-38702760309317653662009-02-16T11:32:00.007-07:002009-04-06T16:22:57.548-07:00documents and paper computerdocuments and paper computer<br /><br />In addition to "use cases" and "data fields (data points)", another key word is "documentation". I treat "documentation" as if it were source code, and as a result, it corresponds to the real system directly -- I treat it as a "paper computer".<br /><br />By doing this, there is no "process". Note that "use cases/business rules" and "data fields (data points)/technical approaches" (I believe "implementation strategies" is too difficult to say quickly in meetings, so, I traded the phrase with "technical approaches") are the top-most level of the structure ("architecture") of a system.<br /><br />Note that we can talk some "technical approaches" to users. All those are key words in software support/development.<br /><br />Also note that "technical approaches" includes technical items in "use cases/business rules", for example, "transactions", "newwork (web services, report server, eim, remote)", "security", and "audit" are "use cases/business rules".survichttp://www.blogger.com/profile/05621218802357307115noreply@blogger.com0tag:blogger.com,1999:blog-26752431.post-21280628563646203152009-02-10T14:01:00.002-07:002009-02-10T14:12:16.148-07:00the wording I am using: "use cases" and "data points"I know I change a lot, and I play with words a lot.<br /><br />Now, again, I am changing the wording of the top level thinking “formula”. They are "use cases" and "data points".<br /><br />Yes, I am putting “rules” and “implementation strategy” back to where they belong – low level.<br /><br />I changed “common data” to “data points”, because “common data” is too abstract to users. I want the wording easy to understand, intuitively.<br /><br />Also, “points” kind of intuitively leads people into details, closer to implementation. This is especially true when you use "screens" for "use cases". <br /><br />I guess I will keep using them for a while.<br /><br />Now, you may say, why, why are you paying attention to the wording so much? It is important. Without a good wording, you will not say them that often, then, you will be misled, or, worse, you will mislead. Saying something, saying something aloud, saying something aloud in front of a team, are a very powerful action, and that action definitely affect your other actions and behaviors.survichttp://www.blogger.com/profile/05621218802357307115noreply@blogger.com0tag:blogger.com,1999:blog-26752431.post-48487332404740143412009-01-26T09:59:00.005-07:002009-01-26T12:23:40.905-07:00Use "rules" and "non-typical implementation strategy" to replace "use cases" and "common data" respectivelyUse "rules" and "non-typical implementation strategy" to replace "use cases" and "common data" respectively<br /><br />For a technical team, the concept (or “wording”) of “rules” is better than “use cases”, because “rules” is more technical. Users are more attentive and more tolerate to details. It is more "cut to the chase". Note that I correct myself of my previous blogs. Now, I believe the concept of “rules” corresponds/replaces to “use cases” (for technical teams), instead of replacing “common data”.<br /><br />For a technical team, the concept “implementation strategy” corresponds/replaces the concepts “common data”.<br /><br />Note that “rules” and “implementation strategy” are more “mixed”: “rules” has “common data” factors, and “implementation strategy” has “use cases” elements. However, their respective “starting point" is “use cases” and “common data” respectively.<br /><br />I know, it is very confusing, but it is actually simple in action: for a technical team, always have a list, with “rules” and “implementation strategy” as your cheat sheet, then, you will be safe and can proactively respond everything.<br /><br />Just one more bit of details. Usually there are too many details, too many “implementation strategies” – i.e., the list can be too long to be effective as a “cheat sheet”. So, the secret is to scan through the common, usual, routine “implementation strategies”, and, identify those uncommon, non-typical ones.<br /><br />You may ask, what are the criteria of “common” and “uncommon” (i.e. “special”, "non-typical") ones? Easy, the 90% rule (I know, usually people say 80% rule – but in technical areas, we need to be tougher).<br /><br />Of course, to pay attention to the non-typical ones, you have to master the common ones first, even most of the time, you do not need to do them yourself, since you only pay attention to the non-typical ones – it sounds like a paradox, but that is the secret of delegation or helping others to help yourself – that is actually your value as an experienced professional.survichttp://www.blogger.com/profile/05621218802357307115noreply@blogger.com0tag:blogger.com,1999:blog-26752431.post-25040599079384673332009-01-24T23:29:00.004-07:002009-01-25T03:07:48.972-07:00thumb typing is good for IT professionalsDiagrams and spreadsheet are bad, plain text is good, and therefore thumb typing is good for IT professionals<br /><br />The key is, drawing is not that important. If drawing is really that important, than, thumb typing is useless, we neither have to use tablet, or, paper.<br /><br />I find that drawing is not that important. Diagrams are totally overvalued. After all, the general computing thesis is that what you can describe, you can realize it in computing, it is not that what you can draw or clicking. For software engineering, structure English (or structured any natural languages) is the king, not diagrams, not spread sheet. Whenever you find your documents are mostly diagrams and spread sheet, you should treat it as a red flag, something is wrong.<br /><br />It took me so long for me to realize the importance of thumb typing. I will strongly recommend to everybody in my family to begin to use thumb typing.<br /><br />I know young people have been doing the texting for a while. However, I am not talking about texting. I am not that generation; I am not interested in texting. Frankly, I believe it is simply temporary anti-culture, combined with the temporary limitation of computing devices – I am talking about those texting abbreviations – BFF, best friend forever, what a heck!<br /><br />Even in thumb typing, I prefer the whole wordings. To me, using not absolutely common abbreviations is a sure indicator that the author is inconsiderate and therefore not professional, period. I know, this does not mean too much to a teenage. I totally understand, believe me, I was young before also :-)<br /><br />I also know a lot of business people have been using PDA for a long time. However, I am not sure most of them are using them to take notes.<br /><br />As a result, although it took me for a while to plunge into thumb typing, I believe I am still among those not too many people who have recognized the value of thumb typing and are doing it seriously.<br /><br />[OK, after I wrote the above, I googled thumb typing, and I found a lot materials, see below. Some of them were written in 1999 -- it means that I am soooo late! However, I can still say that those are pioneers. From what I have observed, I am not that late to use it as an everyday routine notes-taking device to replace paper-based notes-taking<br /><a href="http://www.blackberryforums.com/general-blackberry-discussion/800-blackberry-thumb-touch-typist-guide-typing-60-wpm-without-looking.html">http://www.blackberryforums.com/general-blackberry-discussion/800-blackberry-thumb-touch-typist-guide-typing-60-wpm-without-looking.html</a><br /><br />It says a lot of things, but all I feel I really need to know is the fact that "we can": it is possible to use thumb typing to think-write, and there are two other tips:<br /><br />a. Note the left thumb holding Num can give you a Uppercase for the right thumb.<br />b. When typing number, left thumb holding the Alt key, and right thumb push the number keys.<br /><br />---Just type the quick brown fox jumps over the lazy dog.<br /><br />---I will try more aggressively to be able to do blind/touch typing with thumbs.<br />]<br /><br />Also, I want to share that, in the beginning, on blackberry, I just send myself emails as my notes. Very soon, I found out that it is a bad idea. I cannot find my notes! They are buried in those emails.<br /><br />Now, I am using “tasks” to take notes, and periodically “select” and copy them to emails as a backup. Of course, now, “tasks” is my first icon on my blackberry.<br /><br />There is another thing that sucks. The company has a group security policy: the blackberry locks itself after several minutes. I have to enter password to unlock it every time I need to takes notes. I tried to ask them to make the timeout longer, but you kow the result, Sigh.<br /><br />For blind/touch typing, I am not sure whether I need a physical keyboard or a simulated one. I am using an old blackberry. The new blackberry model is like an iphone, with larger screen, but a simulated keyboard. I do not have the new model, I guess it is a blessing for typing.survichttp://www.blogger.com/profile/05621218802357307115noreply@blogger.com0tag:blogger.com,1999:blog-26752431.post-61105271284053560812009-01-15T12:11:00.003-07:002009-01-15T12:30:27.448-07:00thumb typing all the time -- on blackberry for to-do-item notesThumb typing, or, thumb-and-index typing, is not that difficult. You can do that pretty fast after a few hours. The problem is the software – there is no auto-spell checking, and no auto-correction in blackberry (perhaps I missed something).<br /><br />Thumb typing is faster than writing pad and real time recognition, but I guess we need both, because we still need drawing. Mouse drawing is not good. Touch screen is useful here.<br /><br />Anyway, thumb typing is worth it. I know, I am slow to pick it up, but I will begin to really do thumb typing on my blackberry to make notes, instead of using pen and paper.<br /><br /><br />This means I will use thumb typing all the time. Note that I have electronic notes that I take in VIM (not MS Word, since VIM also have spell checking – it does not have auto-correction – or I should say I am not using that, I am not user whether VIM has auto-correction or not). Those notes are detailed, and have a lot of content – that is why I use electronic notes for them long time ago. I always laugh at my college who are still using papers to do those kind of notes. It is amazing, a lot of them still doing that, make notes on paper!<br /><br />However, I have been using paper doing the to-do-item notes all the time. This kind of notes, they are short, just a reminder. Also, they must be extremely portable, not limited on computers.<br /><br />Now, I am going to move this to blackberry. I cannot draw anymore, but for those to-do-item notes, I do not do drawing anyway.<br /><br />Note that I blog this, because I believe this kind of thing is important for computer professionals. Too many computer professionals are too behind on using computers!survichttp://www.blogger.com/profile/05621218802357307115noreply@blogger.com3tag:blogger.com,1999:blog-26752431.post-16571967178757783352009-01-11T18:16:00.007-07:002009-01-12T09:00:50.197-07:00Personal Paperless Evolution: Use more laptop, printing pdf on paper, and thumb typing notesAs a new year resolution, starting now, I will always use electronic notes, instead of marking the notes on the margin of paper materials -- this means paper material will officially disposable at any time.<br /><br />Today, I cleaned up my paper materials, there are only a few of them, I will gradually move the notes to electronic notes. They are not critical, I have already been doing this, it is just a "clearing house" activity, I guess.<br /><br />More explanations:<br /><br />1. The key of doing this is to use my labtop more often (the battery is OK, I just need to stop my bad habit of prefer reading paper materials and making notes on them). When I travel or at home, I will use my blackberry and my kindle more often -- even when I have to use paper material (OK, I still prefer reading on paper than on computer. Kindle is fine, but Kindle cannot handle pdf), at least I must use thumb typing on blackberry or kindle to take notes.<br /><br />2. As mentioned above, Kindle is a big disappointment to me, I was hoping it can help me to realize the "paperless revolution" in my "home-office" and my personal life. It did not. Now, I have to re-do it by an evolutionary approach.<br /><br />Now I know, a "reader" should be have larger screen (perhaps by folding it or better bending it without the middle dividing line) so that it can handle pdf without any reformatting. It must be touch screen with stylus support to avoid thumb typing. Also, it should have a fold keyboard for typing. In short, it is a tablet computer with an electronic paper screen.<br /><br />I almost regret of buying Kindle, I should have gone to iLiad 1000, which has a price tag close to $900. However, the screen of iLiad is still small and not convenient for typing (does it support external key board? not sure); futher, it does not have color, which is important for some business documents. Also, it does not support video.<br /><br />This leads to a question, why epaper screen? Because it is easy to eyes, and it saves battery -- both are not that important for business documents.<br /><br />So, after all, I guess for pdf documents, let's keep it in labtop (or tablet - if you have it); for "ordinary" books, use kindle. So, I guess my decision on Kindle is an OK one, although Kindle is indeed disappointing -- the technology is slower than I expected. As a result, we need to adapt to the current status of the technology. Printing pdf on paper (sorry, trees, we still need to cut you!), and thumb typing.survichttp://www.blogger.com/profile/05621218802357307115noreply@blogger.com1tag:blogger.com,1999:blog-26752431.post-32045628072062204632009-01-11T16:08:00.004-07:002009-01-12T09:03:40.491-07:00Summary of 2 "blocks" and their sub-blocksSummary of my previous summary<br /><br /><br /><br />I will do things according to the following 2 "blocks" and their sub-blocks:<br /><br />1. “Common data”: this leads to "OUR" Object, UI, Relational, and their mappings -- OR mapping and OU mapping.<br /><br />2. "Use cases": this leads to UI and "facade" -- in Siebel, "business service" and "workflow", they then lead to networking (which in turn includes 4 parts: web service, EIM, reporting, and remote), logging, and security.survichttp://www.blogger.com/profile/05621218802357307115noreply@blogger.com0tag:blogger.com,1999:blog-26752431.post-12582664062082924252009-01-10T14:50:00.007-07:002009-01-12T09:05:27.117-07:00summary and new startI reviewed all my blogs of the past a few years – that is one advantage of blogging over private notes: it forces you to face your history of ideas! I found that sometimes I contradicted myself, and I debated with friends, and I changed my mind. The important thing is not the conclusions, but the arguments, the process of arguing, and more importantly, the understanding, insights, and friendship.<br /><br />OK, another immediate contradiction of myself: Now, I want to have a summary ("conclusions"!), so that we can invent more in the coming year(s).<br /><br /><br />1. "Philosophy": science and technology, regardless of modern and ancient, are one. The saying that modern science is totally different from ancient science and from technology is a myth. At a high level, they are the same. We can and should use science-thinking ("scientific thinking) in technology, and vice versa.<br /><br /><br />2. "Time" -- the basic sequence<br /><br />“Analysis/Design/Coding/Testing” corresponds to “Problems/Theory/Solving Problems using the theory/Testing”.<br /><br />Note: in "problems", you have both "common data" and "use cases", not just "use cases".<br /><br /><br />3. "Space" -- the basic structure (or “architecture” -- but I prefer small words in science/logic, instead of big words in engineering)<br /><br />“Common data” (this leads to "OUR" Object, UI, Relational, and their mappings -- OR mapping and OU mapping) and “use cases”. "Use cases" leads to UI and "facade" -- in Siebel, "business service" and "workflow", they then lead to networking (which in turn includes 4 parts: web service, EIM, reporting, and remote), logging, and security.<br /><br />Note: “Common data” is a “new” phrase I have begun to use. I discussed/debated a similar topic sometime ago in my blogs, “data model vs. domain model”. I believe “data” is more user-friendly and, well, manager-friendly. I add “common” before "data", to emphasize that the concept has inherently an element of “design”, “structuring”, or well, “modeling”. In short, it is a compromise between “data model” and “domain medel” -- but I still do not like “domain model”: it is too programmer-oriented, not user-friendly. Users are totally confused when you use the word “domain model”, but they know, I mean, really know, “data”. Note that it is not just wording. Inherently, “domain model” has too much “technical” baggage. "Domain model" concept belongs to a more limited technical context, instead of a top level concept that can be used together with the concept of “use cases”.<br /><br />A special note: I notice that there is a mapping between "time" and "space", or, a common spot in both "time" and "space": the "use cases" (UIs and facades) maps to "testing". This is understandable: the so-called "space" is the basic structure for software, which must follow the basic structure of human logic, which is the so-called "time" all about.<br /><br />4. Technical team dynamics (or "team culture" or "team leadership" or "team moral" -- pick the phrase you like):<br /><br />a. Basic estimate of human capability, science, technology, and education: a good high school new graduate or an average college new graduate can start to work productively within two weeks on any computer technologies, within a good team and with good mentoring.<br /><br />b. Rotating/pro-vertical (avoid single threading) and lean (cut self-enforcing communication overhead)<br /><br />Single threading is bad. When project is late, you cannot put more people on the bottlenecks. Worse, it damages team moral. It is the basis of unfairness, laziness, and even outright blackmailing. Based on my observation, it is the root cause of more than 80% of problems in IT.<br /><br />The irony is that out of the 80%, more than half of it is from the “solution” of the problem: heavy communication overhead. It is a self-enforcing overhead -- people first compartmentalize the team, create the hunger for information, and then, they “coordinate”. Gradually a lot of people cannot do things anymore, they only “communicate” and “coordinate” while they are devaluing the whole profession into production-line work, with extremely heavy, costly, error-prone, and misleading overhead. The double irony is that this "solution" actually aggravates the "single threading" problem.<br /><br />We can do better. We need, can, and should be more effective by being lean. However, to do that, we need to find a better way to solve the single threading issue.<br /><br />Observing other professional fields, we can find that the real solution is the opposite of the current “solution”: instead of limiting, we expand the scope – every developer should at least have 2 or 3 “fields” (remember that even an average college new graduate can pick up things in a field within two weeks!), then, we can rotate the fields within the team. Also, when we do “division of labor” in a certain project, we should always prefer “vertical” division (end-to-end of a vertical slice), instead of “horizontal” layering division (e.g., one person in UI, another person in Business layer).<br /><br />c. “Document driven”, meeting minutes, source control, and source control friendly format. The essence of the “document driven” is that all documents, including meeting minutes, user oriented documents, and even “private” or “personal” notes, should be treated as “source code”.<br /><br />There are two big challenges.<br /><br />One is that people want to keep some “private” and “personal” notes – this will be resolved by rotating mentioned above.<br /><br />Another one is “source control friendly format”: some user oriented documents, for example, “requirements” or “user manuals”, are not easy to be put into version control friendly format. Currently, too often they are in MS Word together with spreadsheets, which both are ugly and horrible for version control friendly minds! – This is actually pretty easy to resolve in web technology (wiki etc). I hope the corporate world will catch up on this quickly.<br /><br />d. “Process” must be simple, and not arbitrary. In more detailed terms: it must be in place before projects. Preferably, its wording should be consistent with common usage in the industry, like "analysis", "design", "coding", "testing", “use cases”, and “common data”.survichttp://www.blogger.com/profile/05621218802357307115noreply@blogger.com0tag:blogger.com,1999:blog-26752431.post-23099315110661881132008-12-12T08:53:00.002-07:002008-12-12T10:47:40.138-07:00A Paper on TDD and Karl Popper<a href="http://www.springerlink.com/content/b2m76810u5715802/fulltext.pdf">http://www.springerlink.com/content/b2m76810u5715802/fulltext.pdf</a><br /><br /><br />G. Concas et al. (Eds.): XP 2007, LNCS 4536, pp. 253–256, 2007.<br />© Springer-Verlag Berlin Heidelberg 2007<br />-------------------------------------<br />Epistemological Justification of<br />Test Driven Development in Agile Processes<br /><br /><br />Francesco Gagliardi<br />Department of Physical Sciences — University of Naples Federico II<br />Via Cintia — I-80126 Napoli, Italy<br /><a href="mailto:francesco.gagliardi@libero.it">francesco.gagliardi@libero.it</a><br /><br /><br />Abstract.<br /><br />In this paper we outline a methodological similarity between test<br />driven software development and scientific theories evolution. We argue that<br />falsificationism and its modus tollens are foundational concepts for both software<br />engineering and scientific method. In this perspective we propose an epistemological<br />justification of test driven development using theoretical reasons<br />and empirical evidences.<br /><br />Keywords:<br /><br />Software Testing; TDD; Agile Programming; Epistemology; Falsificationism;<br />Modus Tollens.<br /><br /><br /><br />1. Ghezzi, C., Jazayeri, M., Mandrioli, D.: Fundamentals of Software Engineering. 2nd edn.<br />Prentice-Hall, Englewood Cliffs (2003) (ISBN: 0133056996)<br />2. Dijkstra, E.W.: Notes On Structured Programming. 2nd edn., T.H.-Report 70-WSK-03,<br />Technological University Eindhoven, Department Of Mathematics, The Netherlands (1970),<br />(Url: http://www.cs.utexas.edu/users/EWD/ewd02xx/EWD249.PDF<br />3. Popper, K.R.: The Logic of Scientific Discovery (Translation of Logik der Forschung).<br />Hutchingson, London (1959)<br />4. Kaner, C., Falk, J., Nguyen, H.Q.: Testing Computer Software, 2nd edn. John Wiley and<br />Sons, Chichester (1999) --------------<br />5. Bach, J.: What software reality is really about. IEEE Computer 32(12), 148–149 (1999),<br />doi:10.1109/2.809258<br />6. Pettichord B.: Testers and Developers Think Differently. STQE magazine, vol. 2(1), pp.<br />42-46 (2000), (Url: http://www.stickyminds.com/sitewide.asp?Function=edetail&Object<br />Type=ART&ObjectId=506) --------------------<br />7. Coutts, D.: The Test Case as a Scientific Experiment. (url: http://www.stickyminds.com/<br />sitewide.asp?ObjectId=8965&Function=DETAILBROWSE&ObjectType=ART) --------<br />8. Edwards, S.H.: Using software testing to move students from trial-and-error to reflection-inaction.<br />SIGCSE Bull. 36(1), 26–30 (2004), <a href="http://doi.acm.org/10.1145/1028174.971312">http://doi.acm.org/10.1145/1028174.971312</a><br /><br />-------------------------------------------short quotes<br /><br />It is proved that an ideal test suite exists for any program, but unfortunately it is<br />also proved that there is no constructive criterion (i.e. algorithm) to derive a test suite<br />satisfying that property.<br /><br />The incomputability of ideal test suite is the primary cause of the existence of several<br />empirical criteria to define the test suite such as category partition, boundary<br />analysis, special values detection, an so on.<br /><br />---------------<br /><br />This firmly links software development to methodologies of natural sciences and to<br />epistemology, in particular to theory of falsificationism by Popper. And we need to<br />adopt this perspective if we want to increase the comprehension of methodology and<br />practice of software development.<br /><br />In this perspective TDD is the unique ‘scientific’ methodology to develop software<br />systems because it uses the falsificationism and embraces continuous testing.<br /><br />Summarizing, the successful of TDD in agile processes is based on the rediscovery<br />of scientific method.survichttp://www.blogger.com/profile/05621218802357307115noreply@blogger.com2tag:blogger.com,1999:blog-26752431.post-45717371127736505452008-11-23T15:00:00.002-07:002008-11-23T15:12:35.096-07:00Read, baby, readIt is toward the end of the year, holidays are approaching!<br /><br />Looking back, since the end of last year, I have been carrying out my resolution of the journey of going out the box of the software process (being it UP or TDD), and back to the richness of life.<br /><br />More readings, not just outside the readings of MS technologies, or, Siebel technologies, or, Unix, Internet. Much more than that. Reading is nice, it is like watching TV or go to theaters or movies. Reading does not need to be a burden, even for non-fictional readings.<br /><br />Software engineering is not a "field" or "discipline", it is an inter-disciplinary area. Do not let those process fool you. You can get more useful techniques in philosophy of science (and other areas) than in those theories of software processes.<br /><br />Expand our readings. Read, baby, read.survichttp://www.blogger.com/profile/05621218802357307115noreply@blogger.com0tag:blogger.com,1999:blog-26752431.post-20571160889725015362008-11-23T14:32:00.002-07:002008-11-23T14:49:43.501-07:00Another site that with similar recommedatoin of readings.<br /><br />It seems that "testers" are deep thinkers, shame on "project managers", "analysts", "architect", "developers", and "programmers"! -- of course, I am NOT a tester, so, I do not really care about the testing specific things.<br /><br /><a href="http://www.satisfice.com/bibliography.shtml">http://www.satisfice.com/bibliography.shtml</a><br /><br />Systems Thinking<br /><a class="document" href="http://www.amazon.com/exec/obidos/ASIN/0932633226/satisinc" target="_blank">Quality Software Management, Vol. 1: Systems Thinking</a><br />1991, Gerald M. Weinberg<br /><a class="document" href="http://www.amazon.com/exec/obidos/ASIN/0932633498/satisinc" target="_blank">An Introduction to General Systems Thinking</a><br />1975, Gerald M. Weinberg<br /><a class="document" href="http://www.amazon.com/exec/obidos/ASIN/0932633013/satisinc" target="_blank">Secrets of Consulting: A Guide to Giving and Getting Advice Successfully</a><br />1986, Gerald M. Weinberg<br /><a class="document" href="http://www.amazon.com/exec/obidos/ASIN/0932633072/satisinc" target="_blank">General Principles of Systems Design</a><br />1988, Gerald M. Weinberg, Daniela Weinberg<br /><br /><br />Heuristics<br /><a class="document" href="http://www.amazon.com/exec/obidos/ASIN/0205260837/satisinc" target="_blank">Tools of Critical Thinking</a><br />David A.Levy, 1997<br /><a class="document" href="http://www.amazon.com/exec/obidos/ASIN/0932633137/satisinc" target="_blank">Exploring Requirements: Quality Before Design</a><br />1989, Don Gause, Gerald M. Weinberg<br /><a class="document" href="http://www.amazon.com/exec/obidos/ASIN/0691023565/satisinc" target="_blank">How to Solve It</a><br />1945, George Polya<br /><a class="document" href="http://www.amazon.com/exec/obidos/ASIN/0471510041/satisinc" target="_blank">How to Read and Do Proofs</a><br />1990, Daniel Solow<br /><br /><br />Ways People Think and Learn<br /><a class="document" href="http://www.amazon.com/exec/obidos/ASIN/0262581469/satisinc" target="_blank">Cognition in the Wild</a><br />1996, Edwin Hutchins<br /><a class="document" href="http://www.amazon.com/exec/obidos/ASIN/0521659728/satisinc" target="_blank">Thinking and Deciding</a><br />1994, Jonathan Baron<br /><a class="document" href="http://www.amazon.com/exec/obidos/ASIN/0060903252/satisinc" target="_blank">Lateral Thinking: Creativity Step by Step</a><br />1990, Ed De Bono<br /><a class="document" href="http://www.amazon.com/exec/obidos/ASIN/1578517087/satisinc" target="_blank">The Social Life of Information</a><br />2000, John Seely Brown, Paul Duguid<br /><a class="document" href="http://www.amazon.com/exec/obidos/ASIN/0201626950/satisinc" target="_blank">Things That Make Us Smart: Defending Human Attributes in the Age of the Machine</a><br />1993, Donald Norman<br /><br /><br /><br />Scientific Thinking<br /><a class="document" href="http://www.amazon.com/exec/obidos/ASIN/0262691914/satisinc" target="_blank">The Sciences of the Artificial, 3rd Ed.</a><br />1996, Herbert A. Simon<br /><a class="document" href="http://www.amazon.com/exec/obidos/ASIN/0415043182/satisinc" target="_blank">Conjectures and Refutations: The Growth of Scientific Knowledge</a><br />1992, Karl Popper<br /><a class="document" href="http://www.amazon.com/exec/obidos/ASIN/0262112094/satisinc" target="_blank">Theory and Evidence: The Development of Scientific Reasoning</a><br />1996, Barbara Koslowski<br /><a class="document" href="http://www.amazon.com/exec/obidos/ASIN/0521434610/satisinc" target="_blank">Abductive Inference: Computation, Philosophy, Technology</a><br />1996, John R. Josephson, Susan G. Josephson<br /><a class="document" href="http://www.amazon.com/exec/obidos/ASIN/0738203491/satisinc" target="_blank">The Pleasure of Finding Things Out</a><br />1999, Richard Feynman<br /><a class="document" href="http://www.amazon.com/exec/obidos/ASIN/0750303697/satisinc" target="_blank">Science as a Questioning Process</a><br />1996, Nigel Sanitt<br /><a class="document" href="http://www.amazon.com/exec/obidos/ASIN/0684835827/satisinc" target="_blank">Administrative Behavior, 4th ed.</a><br />1997, Herbert Simon<br /><br /><br />Software Testing<br /><a class="document" href="http://www.amazon.com/exec/obidos/ASIN/0471358460/satisinc" target="_blank">Testing Computer Software</a><br />1992, Cem Kaner, Hung Quoc Nguyen, Jack Falk<br /><a class="document" href="http://www.amazon.com/exec/obidos/ASIN/0849308097/satisinc" target="_blank">Software Testing: A Craftman's Approach</a><br />1995, Paul C. Jorgensen<br /><a class="document" href="http://www.amazon.com/exec/obidos/ASIN/0471318264/satisinc" target="_blank">Bad Software: What to Do When Software Fails</a><br />1999, Cem Kaner, David Pels<br /><br /><br />Example of an Implicit Specification<br /><a class="document" href="http://www.amazon.com/exec/obidos/ASIN/1556156790/satisinc" target="_blank">The Windows Interface Guidelines for Software Design</a><br />1995, Microsoft<br /><br /><br />Teamwork and Communication in a Technical Team<br /><a class="document" href="http://www.amazon.com/exec/obidos/ASIN/0932633285/satisinc" target="_blank">Quality Software Management, Vol. 3: Congruent Action</a><br />1994, Gerald M. Weinbergsurvichttp://www.blogger.com/profile/05621218802357307115noreply@blogger.com0tag:blogger.com,1999:blog-26752431.post-20139662373708128492008-10-18T22:44:00.003-07:002008-10-18T22:50:37.154-07:00Karl Popper and Software EngineeringKarl Popper and Software Engineering<br /><br />I believe now -- 2008, in software engineering, a pure “practitioner” point of view is hitting a dead end. We need an “academic” or conceptual revolution. The revolution is to throw out the inductionism in software engineering. Karl Popper did it in Philosophy of Science. We need to expand that to software engineering.<br /><br />In my previous blog, I proposed the following theory:<br /><br />“Analysis/Design/Coding/Testing” corresponds to “understanding problems and anomalies/theory/solving issues using the theory/ experiment-test the theory”. Now, I am going to make it even simpler: “Analysis/Design/Coding/Testing” corresponds to “Problems/Theory/Solving Problems using the theory/Testing”.<br /><br />You may say, it is just a word-game. I say it is a huge, revolutionary change. Now, "analysis" is to understand problems, not “gathering” those so-called “requirements” anymore! In meetings with users, when we ask “what is the problem” and “how do we solve the problem”, it is always more effective than asking “what are the requirements”! In fact, we all know that “requirement gathering” is the source of all problems in software development. Now, we know why – OK, pun is intended here!<br /><br />I googled about it (Karl Popper and Software Engineering). Surprise, Surprise, I am not the only one!<br /><br /><br /><a href="http://blogs.msdn.com/imtesty/archive/2007/01/15/the-science-of-software-testing.aspx">http://blogs.msdn.com/imtesty/archive/2007/01/15/the-science-of-software-testing.aspx</a> A deep thinker in MS!<br /><br />The following is a short quote (please go to the above URL for a complete read, it is fun!):<br /><br />Testing as a science<br />Computer software is similar to a scientific hypothesis; both are inherently fallible. The basic framework of the software debugging process is analogous to the trial and error practice that advances scientific hypotheses. Computer software is simply technical conjecture. Test engineers attempt to refute the assumption of flawless software through rigorous tests mostly designed to prove that defects exist (falsification).<br /><br />The falsification process sharply contrasts with data-driven approaches such as induction and deduction, which attempt to justify validity based on the repetition of facts. Justificatory approaches mostly attempt to support claims through confirmation. Confirmation primarily endeavors to validate the error-free uncertainty by using specific data that demonstrates proper functionality. This approach clearly only proves that software functions correctly under certain conditions; it does not prove that the software is error free.survichttp://www.blogger.com/profile/05621218802357307115noreply@blogger.com1tag:blogger.com,1999:blog-26752431.post-50497663842599415812008-10-05T18:39:00.008-07:002008-10-05T19:28:41.185-07:00Problem Solving Areas (PSAs), Problem Solving Lean Process (PSLP), Analysis/Design/Coding/Testing and General Problem SolvingProblem Solving Areas (PSAs), Problem Solving Lean Process (PSLP), Analysis/Design/Coding/Testing and General Problem Solving<br /><br />Ya, you may say that all this blog is about names; but good names indicate the maturity of a theory.<br /><br />1. I changed the 8 core "techniques" into 8 core "Problem Solving Areas (PSAs). See the 8 PSAs at the bottom of the blog.<br /><br /> 2. In this blog, I changed the process name into “problem solving lean process”: it is a lean process, with problem solving in its focus.<br /><br />3. I retreat from my noble fighting with “Analysis/Design/Coding/Testing”; now, I believe it is a paraphrase or a parallel mechanism of the “problem solving process”: thinking about problems, a theory, solve issues in the theory, and experiments for the theory. By doing this, I have “saved” the analysis/design/coding/testing, and, more importantly, saved myself from craziness! As a result of this realization, on the one hand, I am now a big fan of the micros-waterfall, because it is the same micro-mechanism of any problem solving processes. On the other hand, I do believe the micro-waterfall is flexible, any step of this micro-waterfall reflects the whole – for example, in analysis, there is testing already.<br /><br /><br />---------------------------8 PSAs<br /><br />1. "OR mapping" (including "UOW", Unit of Work, equiv. to Siebel's BO)<br />2. ("O") "entity": rules in entities, rules engine(******), scripting in entities<br />3. ("U") "Web2 UI": ("ActiveX" and "Ajax")<br />4. "Data Binding" ("OU mapping")<br /><br /><br />5. "transaction" (and non-transaction, with "facsades" and "workflows") (business service and workflows, tasks. Also here: "unit testing" ******)<br /><br />6. "networking (at application level, as "connected applications")"<br />--i. async and sync EAI (background) "messaging" for integration and need "user push notification" (activities or an area on every screen)<br />--ii. batch EIM<br />--iii. offline web client<br />--iv. reporting server<br />7. "logging (that is runtime-configurable)"<br />8. "security"("authorization" and "authentication")survichttp://www.blogger.com/profile/05621218802357307115noreply@blogger.com0tag:blogger.com,1999:blog-26752431.post-16863973182334665372008-08-02T17:30:00.005-07:002008-08-03T01:38:51.691-07:00Seven square number of Problem-Solving-Items (PSI)Seven square number of Problem-Solving-Items (PSI)<br /><br />What are problem solving items?<br /><br />As a first-level approximation, they are requirements + “architecture” requirements.<br />However, they also include technical design items, source control items, testing items, support items. They include all problems. For details why I put all of them together, please read my previous blogs.<br /><br />Of course, we all know that our corporate world does not like the word “problems”, we find all different words for it, “issues”, “challenges”, etc. I do not like those other words, and I like the word “problem” – I like all the honesty, history, weight, and power that go with it. However, I do understand and appreciate the needs from the corporate world; so, I add a positive word with it, and add an “unit” word, hence the phrase, “problem-solving-items”.<br /><br />What is the “7-square”?<br /><br />Psychology shows that the short memory of human’s brain can only handle 7 items. The optimal is half of it, around 3. That is the reason that when we speak or write, we use 1, 2, 3, or 4, not that often we use more than 4. If we really need to, we re-organize them, make it two levels, 1, 2, 3, under each item, we have a, b, c.<br /><br />You may believe it is trivial. I do not believe so. I believe the universe is “consistent” or even “anthropic” – see <a href="http://en.wikipedia.org/wiki/Anthropic_principle">http://en.wikipedia.org/wiki/Anthropic_principle</a> . As a result, I believe those 1, 2, 3 things are “consistent” with those “thesis”, “antithesis”, and “synthesis” in Hegel’s philosophy.<br /><br />I apologize to drag you into this physics-philosophy-psychology indulgence, that is my weakness; but I am also very practical and pragmatic, so, let’s be back to the real business.<br /><br />IT (Information Technology) is about handling large amount of information. Its complexity comes from the large amount of seeming unrelated items. As a result, we have to maximize the capacity of human minds. In short, we have to use 7, not 3; further, we have to use two levels, instead of just one. And use two levels all at once – we have to treat the two levels as if there were one, i.e. we have to treat 49 items all at once, and not make the two levels too restrictive.<br /><br />In short, next time you think about IT, just think about “49 PSIs”!<br /><br />------------------<br />There are no categorical differences between the "problem solving" in sciences and that in engineering disciplines.<br /><br />Further, the best minds, or, at least best documented best minds, due to the very nature of basic sciences, are not in engineering, but in basic sciences.<br /><br />As a result, in addition to Lean literatures, I will resume my love for reading philosophy and history of sciences.<br /><br /><a href="http://www.cs.cmu.edu/afs/cs/usr/wing/www/publications/Wing06.pdf">http://www.cs.cmu.edu/afs/cs/usr/wing/www/publications/Wing06.pdf</a><br /><br /><a href="http://philsci-archive.pitt.edu/archive/00004037/01/The_reductionist_blind_spot-08-05-01-2300.pdf">http://philsci-archive.pitt.edu/archive/00004037/01/The_reductionist_blind_spot-08-05-01-2300.pdf</a><br /><br /><a href="http://philsci-archive.pitt.edu/view/year/"></a>survichttp://www.blogger.com/profile/05621218802357307115noreply@blogger.com0tag:blogger.com,1999:blog-26752431.post-74016000985225716152008-08-01T12:10:00.002-07:002008-08-01T12:12:12.747-07:00Problem Solving Logic-Centric Lean Process (PSLCLP)I believe I am in a creativity storm.<br /><br />I believe I found out the problem of all “software processes” and “IT project management”. It is the “inductionism”, we need a “deductionism” paradigm shift just as Karl Popper did in philosophy of science.<br /><br />I believe the key is indeed “requirement gathering” – the starting point of the waterfall, it is wrong, everything is wrong.<br /><br />We need to replace it with “problem”. The whole thing should be “problem solving”.<br /><br />The name of the process should be Problem Solving Logic-Centric Lean Process (PSLCLP), I know, it is long. The key is to remember “problem solving”.survichttp://www.blogger.com/profile/05621218802357307115noreply@blogger.com0tag:blogger.com,1999:blog-26752431.post-7992166159314922152008-08-01T08:21:00.005-07:002008-08-01T09:34:52.641-07:00testing, testable, Lean, science, and Occam's razorThe effort to apply Lean to software makes me think, very hard.<br /><br />It is about the core waterfall, by that I mean: analysis, design, implementation, teat, and deployment.<br /><br />I want to eradicate them. To me, those concepts are simply a pretentious way to say that we are working toward a new system.<br /><br />TDD is good in the sense that it has already started to break this core waterfall: it says that let’s put aside “analysis, design, coding, and testing”, let’s treat everything as testing – that certainly is disruptive and revolutionary!<br /><br />Of course, the problem is that, this revolution concept is mixed and therefore buried or at least eclipsed by other concepts like “stories” -- but that is another story, of course.<br /><br />Then, the concept in philosophy of science hits me: “testable".<br /><br />Usually we believe software engineering is engineering, and therefore we use metaphors from other engineering. However, perhaps we should think about software more in the terms of science – philosophy of science, logic of science, and logic-psychology of problem solving?<br /><br />After all, modern engineering is based on science; and recent science is more and more “big science”, i.e., engineering based science – science of man-made.<br /><br />After you cut the fat of the waterfall, we can see some many new things, or, new old things!<br /><br />More about why Lean and science: heard about Occam's razor (<a href="http://en.wikipedia.org/wiki/Occam">http://en.wikipedia.org/wiki/Occam</a> ). Science is the leanest enterprise by human being!<br /><br />some blogs I got when I googled ockham razor and six sigma:<br /><br /><a href="http://usercentricea.blogspot.com/2008/05/occams-razor-and-enterprise.html">http://usercentricea.blogspot.com/2008/05/occams-razor-and-enterprise.html</a>survichttp://www.blogger.com/profile/05621218802357307115noreply@blogger.com0tag:blogger.com,1999:blog-26752431.post-27225241136395410302008-07-30T11:56:00.003-07:002008-07-31T09:31:58.718-07:00How to apply LCLP on Siebel CRM developmentHow to apply LCLP on Siebel CRM development<br /><br />It is logic centric; then, what is the logic?<br /><br />It is the 8 core techniques, of course – as promised :-) it is all just about re-packaging.<br /><br />A little further now though. Because of LCLP, we can justify that we jump on those 8 core techniques directly.<br /><br />Because we do it directly, we can immediately split those into a few dozen items.<br /><br />Also, “techniques” are too “doer-centric”, so, let’s change it into “special design areas”.<br /><br />So, the result of applying LCLP on Siebel CIM development is that we directly jump to a few dozen “special design areas” – the groupings are still those 8 core techniques, of course.<br /><br />-----------------examples:<br /><br />---- LOV, constrained LOV, static and dynamic, how to make greatParent-parent-child LOV.<br /><br />---- State model<br /><br />---- ldap/asi adapter: because Siebel does not use a generic database account, so, even we use ldap/asi, we have database accounts. The adapters will help the sync.<br /><br />---- …………survichttp://www.blogger.com/profile/05621218802357307115noreply@blogger.com0tag:blogger.com,1999:blog-26752431.post-74896802798260746702008-07-30T11:50:00.003-07:002008-07-31T09:50:23.240-07:00LCLP and cheese without fatThis is basically a comment I left on:<br /><a href="http://vikasnetdev.blogspot.com/2008/07/leading-project.html">http://vikasnetdev.blogspot.com/2008/07/leading-project.html</a><br /><br />Based on the comments of previous blog, I have to change ALP (architecture-centric Lean Process) to LCLP (Logic-Centric Lean Process, note that I cannot use LLP) .<br /><br /><br />Comparing with Lean, I feel TDD or agile is not enough, even I am willing to go along with TDD, since it is the closet we have for now in software industry.<br /><br />I would like to remove all the concepts that lead to waterfall. For example, the so called "requirement gathering". It implies a step in the waterfall. Requirement gathering is simply communication with users. I deny the concept of "requirement gathering", because there is no special ways in "requirement gathering" -- comparing with "design" (or, a better wording, "logic"), it is vague, and the faster you can jump on to design, the better. "Requirement gathering" is simply an inefficient or less-than-optimal design. All this means, let's talk about screens flows, screens layout and data entities and related business rules, security, notifications, logging, installation, source control, etc. directly and as technical and specific as users or audience can understand, and with no certain orders other than the necessity of the logic.Cut to the cheese, lean, it is the cheese without fat.<br /><br />How do you like that, cheese without fat :-)<br /><br />--------------------------A notes on July 31<br />I know I go to extreme sometimes, that is my weakness – but that is also my strength, by doing that, I get to the bottom of things quickly.<br /><br />I am trying to eradicate all waterfall concepts, even just some traces of it. This exposes the needs for order.<br /><br />I said that there is “no certain orders other than the necessity of the logic”, the tone is certainly mostly negative. After thinking about it, I know I need to emphasize the positive side of it also.<br /><br />The key is, after removing the waterfall, we can see the orders introduced by the “necessity of the logic” more clearly, and therefore, can follow those orders, and do things more efficiently and more effectively.<br /><br />Actually, that is the whole point of removing waterfall. Waterfall ordering eclipses the real orders: it oversimplifies things to one dimension.<br /><br />This leads to a very counter-intuitive statement: the most harmful situation of waterfall process is actually for large projects, when you cannot simplify things like that, even using many iterations, it simply just does not work.<br /><br />Typically, in a mid-to-large sized project, there are a few dozen of “dimensions” (you can “group” them into two or three groups, but those groupings are vague). Experienced team leads or good project managers pick up those dimensions quickly, and follow them up through the whole project.<br /><br />Along each dimension, there are pretty clear patterns, and among those dimensions, there are also some vague but useful patterns. Ya, those dimensions and patterns are “technical”, but good leads or project managers do not only know some “project management” terminologies, they are technical enough to know those dimensions and patterns.survichttp://www.blogger.com/profile/05621218802357307115noreply@blogger.com0tag:blogger.com,1999:blog-26752431.post-60326564479127449702008-06-22T11:49:00.007-07:002008-06-22T13:41:55.357-07:00How to lead a project: the opposite of “waterfall” is “architecture-centric”, not “iterations”How to lead a project<br /><br />We must lead a project around the concept of “architecture”: “architecture design”, “high level design”, or “design”. However, note that because “architecture” has too much overloaded meaning, I use the wording “high level design” whenever I can.<br /><br />The waterfall concept, that we do software in the order of requirement gathering, analysis, design, coding, testing, deployment, support, is simply wrong. However, the opposite of “waterfall” is “architecture-centric”, not “iterations”. "Iterations" are simply small waterfalls. Many small wrongs do not correct one big wrong. Further, the wrongness about the waterfall concept is not its frigidness; it is its emptiness and pretentiousness – it is its tendency to encourage people to think non-senses – things that cannot add values to the project (its frigidness is actually fine if you can deal with its emptiness and pretentiousness). We need to replace the “waterfall” concept with the concept of the “architecture” and the “dependencies” in the architecture. Note that “architecture” and “dependencies” are very rich concepts.<br /><br />1. The project is within a bigger architecture.<br />2. The project itself has its own internal architecture, or, high level design.<br /><br /><br />3. The high level design of the project has the following parts:<br /><br />a. “Functional” (in Siebel, we call it “configuration”). It includes OR mapping and OU mapping (i.e. ORU mapping) and rules. Here we have two important notes:<br /><br />(i) functional is part of the architecture. Some people may say that the “functional part” is not part of an architecture design (i.e. high level design). That is not true. OR mapping, OU mapping/binding, and rule engine are certainly parts of an architecture design (high level design); the usage patterns of ORU mapping and rule engine are also part of an architecture design (high level design). It is actually very easy to see -- once we stop seeing things through waterfall glasses, and begin to see things through “architecture-centric” point of view: there is no “requirement gathering” or “analysis”, there are just vague designs, and designs are simply vague or unfinished systems.<br /><br />(ii) UI must be easy for automated testing. Some people may say that testing is not part of a high level design. Wrong! Testing is part of the architecture, just as logging is part of the architecture. To ensure that, automated UI testing must be part of the early development.<br /><br />b. “Architectural” (in Siebel, we call it “Integration and conversion”). It includes “transaction” (in Siebel, it is BS and WF), “networking (in Siebel, it includes EAI/web service, EIM, offline client, reporting server), logging, and security. Again, an important note here is that automated unit testing is part of a high level design. Here, automated unit testing is included in the concept of “transaction” -- a good high level design should always make it automated unit testable at transaction level.<br /><br />c. “Admin”: this can be treated as an extension of b.<br /><br />(i) Source control is an extension of automated unit testing; this is because it is through automated unit testing that source control is “attached” to the architecture and therefore must be treated as part of an architecture. Using source control is part of a high level design.<br /><br />(ii) In Siebel, when we set up development environment; we need to go through hoops in setting up “offline client”.<br /><br />So, here “admin” includes “deployment admin” and “system admin”. Note that by getting into "system admin", I begin to accomplish my new year resolution that I will consolidate my knowledge into a complete vertical stack, bottom up, from hardware, OS, to browser scripting.survichttp://www.blogger.com/profile/05621218802357307115noreply@blogger.com4tag:blogger.com,1999:blog-26752431.post-25875643783685606452008-06-12T06:10:00.000-07:002008-06-12T06:26:33.657-07:00The differences between ALP and TDDThe differences between ALP and TDD<br /><br />ALP is architecture-centric. It requires finish architecture design in the first a few days (for most projects), or, a few weeks (for really large projects).<br /><br />ALP treats “stories” or “use cases” as vague materials. It directly focuses on three things: (a) the OR mapping -- key concepts (glossary) and (logical) database tables-columns, and (b) the OU mapping (or binding) -- key concepts (glossary) and screens and buttons, and (c) rules – key concepts, screens-buttons, database tables-columns, and business logic, in the contexts of typical scenarios.<br /><br /><br />You may say that TDD can do those things also, or, further, good TDDs do those things also. That is true. The same can be said to RUP. That is why it took me so long to make this explicit. However, I feel it is important to make it explicit, all good processes are alike; however, there are too many bad TDDs and bad RUPs.survichttp://www.blogger.com/profile/05621218802357307115noreply@blogger.com3tag:blogger.com,1999:blog-26752431.post-88584626236349575442008-06-06T13:54:00.002-07:002008-06-06T14:07:11.738-07:00Architecture-centric Lean Process, ALPThe name “Team Capability Model” is not well-known, so, it seems that we have to keep using the word “process” – so, here is a new name for it: Architecture-centric Lean Process, ALP.<br /><br />In addition to the content of the concept, I like the name also. It has some tensions built-in (“Lean” usually means less “architecture”), and, it sounds official and formal.survichttp://www.blogger.com/profile/05621218802357307115noreply@blogger.com0tag:blogger.com,1999:blog-26752431.post-76113811758839690182008-06-01T22:54:00.004-07:002008-06-06T13:54:33.368-07:00An Architecture-Driven Team Capability ModelAfter a few years in written form in my notes and in the blog, I believe the “8 core computing techniques” is mature enough to have a more official or formal name, so that it can be used in any documents in the “corporate culture”.<br /><br />I put some thought on it; the best way for it to "break in" the corporate culture is to use it as a "capacity model" (note that it is not just a “process” -- it has much more content). Because it is all about architecture, so, it is an architecture-driven capacity model.<br /><br /><br />1. A person’s or a team’s CAPABILITY is determined by its ARCHITECTURE CAPABILITY.<br />---- I know, this is a peculiar usage of the word “architecture”. Please see below.<br /><br />2. A person’s or a team’s ARCHITECTURE CAPABILITY equals:<br /><br />“Business knowledge”<br />+ “Technologies”<br />+“Processes”<br /><br />All of those are elements of architecture:<br /><br />(a) “Business Knowledge” simply means (i) OR mapping, (ii) OU mapping, and Rules.<br /><br />(b) “Technologies” simply means (i) Transactions (note: capable of unit-testing at this level is like logging, is part of the architecture, it is NOT just a feature of a “process”), (ii) Networks, (iii) Logging, and (iv) Security.<br /><br />(c) “Processes” simply means the “order of doing things”, based on the DEPENDENCIES in the architecture.survichttp://www.blogger.com/profile/05621218802357307115noreply@blogger.com4tag:blogger.com,1999:blog-26752431.post-44859806551236390652008-05-13T08:05:00.004-07:002008-05-13T09:00:49.412-07:00Lean vs UP or TDDIn <a href="http://survic.blogspot.com/2007/12/post-processesontologies-open-eyes-on.html">http://survic.blogspot.com/2007/12/post-processesontologies-open-eyes-on.html</a><br /><br />I wrote: if you know those (8 core) techniques, you surely already know those "processes". "Processes" is simply experiences you gain when you use those "8 core techniques".<br /><br />In <a href="http://survic.blogspot.com/2008/05/use-lean-process-directly-instead-of-up.html">http://survic.blogspot.com/2008/05/use-lean-process-directly-instead-of-up.html</a><br /><br />I wrote: we should refuse to talk about "software proceess" -- we should use lean process in software directly, instead of UP or even TDD.<br /><br />I am now more convinced.<br /><br />The key is, being “lean” requires that we must do things as close or direct as possible to where the real values are happening.<br /><br />The “8 core techniques” are where the real values are happening.<br /><br />So, we should replace all those TDD or UP with 8 core techniques, and call it “lean”.<br /><br />You may ask, even we know the content of those 8 core techniques, we need to ask: what category do they belong?<br /><br />The answer: they are architecture elements.<br /><br />So, a “lean” process means that we deal with architecture elements directly, iteratively and incrementally – which means, as long as you are making progress and you know about it and you can provide hard evidences for it, then, in whatever order, do whatever is necessary.<br /><br />Lean process is very different from TDD and UP. Obviously, it is “heavier” then TDD, because it has a “default architecture”, and is totally architecture driven.<br /><br />Also, it “includes” or “tolerates” or "consumes" the concepts of “requirements”, “use cases”, etc., because all of those concepts are simply iterations toward “screens and buttons” and “façade methods”. “Testing” is a real concept in “lean”, but that simply because testing is inherently part of the architecture, just like logging is. Note that “lean” is better, because now you always know the context, and know that it can be extremely flexible yet can always focus on the real result. <br /><br />It also "includes" or "consumes" DDD – all those mappings (OR and OU) and related rules are DDD, or, you many say that DDD is the iterations toward OR and OU. Again “lean” is better, because you know the context, and you know it can be extremely flexible yet can always focus on the real result.survichttp://www.blogger.com/profile/05621218802357307115noreply@blogger.com0