Human Communications

עם כל התיעוד שנאלצנו לכתוב, אני נזכרת בשני ספרים נהדרים:
The Elements of Style
מאת
William Strunk Jr, E.B. White,
The Visual Display of Quantitative Information
מאת
Edward Tufte.
ברצוני לדעת: האם באמת בכל המטרים של ניירת שאנחנו מפיקות יש מידע משמעותי שמגיע לצד השני? האם המסר שלנו ברור? האם אפילו אצלינו הוא ברור?

אומרים לסטודנטים (שהם אנחנו) שתיעוד הוא חלק חיוני מתהליך הפיתוח, ובמיוחד כשקיימים כמה גורמים עם מטרות שונות ובעלי רקעים שונים, דוגמת צורכים סופיים ומתכנתים. תהליך פיתוח נכון מבחינה זו, לטענת המרצים, ישפיע על הסיכויים שהפרויקט שלך לא יתקל בבאגים בלתי-פתירים בשלב מאוחר ביותר בפיתוח, וגם שלא יופק מוצר שלא יקובל ע"י הלקוח בגלל שהוא לא מספק את דרישותיו.

אבל האם זה נכון? עריכת התיעוד דרש לנו בערך חודשיים, בהם לא התקדמנו בתכנון או בקידוד. רוב הבעיה היתה בזה שהסגנון אותו דרש הלקוח למסמך שלנו לא תאם בכלל לסגנון החשיבה לו אנחנו מורגלות. יתכן שזה הדרך הכי יעיל לוודא שעובדים נכון? באיזה מכיר? ולאור העובדה שעקמנו בחשיבה כל כך כדי להפיק את התיעוד הזה, איזה סיכוי יש לנו להפיק קוד שיתאים לו?

כשהשיטה נהיתה כל כך אי-טבעי וכואב, אני משוכנעת שחייב להיות קיים שיטה טובה יותר

--------------------------------

With all the documentation we're being induced to write, I am reminded of two works: Strunk and White's Elements of Style, and Tufte's Visual Display of Quantitative Information. I wonder, in all the meters of ink on paper we're churning out, how much data is really getting through to the other side. I wonder if our message is clear. I wonder if we even have much message to deliver.

Documentation, we are informed as students, is a necessary part of the software development process where multiple parties with multiple interests and background fields are involved (eg, shareholders and programmers). Proper software development process, they tell us, will help save your project from being so error-prone as to be useless or so far from satisfying your end user as to be rejected.

Is this true? Documentation kept us away from design and code for about two months. This was mostly because drafting documentation to meet the standards set by our client company was completely foreign to our thought patterns. Can this really be the best way to ensure that we're doing it right? At what expense? And considering how far we had to bend our thought patterns to plan and design in this way, how likely is it that we will succeed in actually delivering a product that conforms with what we described?

When the method gets so painfully unnatural, I am convinced that there must be a better way.

Introducing a Project

עכשיו כשאנחנו סופסוף מתחילות לקודד את הפרויקט הסופי (אפילו אם זה התחלה מוטעה, מתקרבים) ברצוני לשמור אזכרה לדברים המגניבים שנעשה. ויתר על כן, אני רוצה לשמור אזכרה לדברים המגניבים שלא נעשה לאחר שמנסים אותם, בגלל שדברים כאלה לא יופיעו לנו בפרויקט הסופי והם עדיין מגניבים.

קודם כל תיאור קצר של הפרויקט:
אנחנו מפתחות אתר אינטרנט לחברה קיימת (לא האתר הראשי שלהם) בשימוש מסד הנתונים והשרתים שלהם. לפי בקשתם, אנחנו כותבות מסמכים שונים בכל שלב התכנון, דבר שמאיט אותנו בצורה משמעותית למדי. לדעתי כדאי לנו לצמצם בדוקומנטציה בהמשך (?).
הדגש בפרויקט אמור להיות בחווית משתמש חלקה ושימוש יעיל בנתונים
(OLAP).

רשימת סיכום דברים מגניבים שעד עכשיו הסכמנו לא לעשות:
ASP.net MVC
EDM
Data controls

רשימת סיכום דברים מגניבים שככל הנראה כן נעשה:
MVC - מימוש שלנו, לא של מיקרוסופט
WCF
AJAX
אלגוריתמים - למצוא העדפות של המשתמשים

--------------

Now that we're really starting to code our final project (at least, even if it's a false start, we're getting very close) I want to start a record of the cool stuff we do. More importantly, I want to record the cool stuff we decide not to do after trying it, because those things won't show up in our final project but still deserve to be remembered.

A brief description of the project is in order:
we are developing a website for an existing company (not their flagship website), using their databases and their servers. By their request, we are writing documentation at intervals, but this documentation slows us down to a near-standstill. I think we should refuse to write documentation in the future, except in very limited measures. (?)
The emphasis of the project is supposed to be a smooth user experience and efficient use of data (by way of OLAP).

A summary of cool things we probably won't be doing:
ASP.net MVC - as we know nothing of unit testing, which seems to be its sole advantage
EDM - we still haven't figured out why we would want this instead of LINQ to SQL
Data controls - objects in the business layer vs easy binding in UI? Business layer wins

Cool things we probably will be doing:
MVC - implemented by us, not by the developers of C#
WCF
AJAX
Algorithms - to determine user preferences

Now let's see what my partners are up to with their parts of the DAL...