Maxim Fridental

• 天空是蓝的。。。我已经忘了。。。 http://t.co/zola4CBr #
• I favorited a @YouTube video http://t.co/ElqKLxjb 紀曉君　彩虹 #

Powered by Twitter Tools

Just watched the sneak peek video:

They have desaturated IDE chrome UI so that it is mostly monochrome now (i.e. no colors in the toolbar buttons), with occasional splashes of Metro-nesque deep blue colors, and I find it the most successful Visual Studio UI redesign ever.

First, it is stylish. Second, it channels the focus on the colored source code.

Unfortunately, they seemingly haven’t changed a thing in how the source code is colored, which is pity. Source code colorizer developers seem generally to believe being solving the classic computer science problem of “how many colors do you need to paint a map” and use arbitrary well distinguishable colors. The UX aspect of colorized text is ignored. As a result, one can try to enjoy the source code mostly consisting of bold red text with some lighting blue islands in there.

Another thing I liked was a slight improvement of TFS usability for those who use Scrum. The previous TFS UI, known as Team Exporer, was looking like just some random enterprisey piece of shit. Visual Studio never gave it enough screen estate to look reasonable so that you were forced to scroll and to change the window sizes constantly and a lot of times, even I you just wanted to accomplish a very simple task. Besides, it was unbelievable overcrowded with various text boxes and drop downs, most of them being never used in any company of any size and with any process whatsoever, except of perhaps some teams inside of Microsoft.

So, now, in Visual Studio 2011, they have liberated the TFS UI and put it into a browser. Entering a new sprint item takes typing its text and hitting Enter — exactly the same amount of interaction the best tools in this area support (I mean FoxBugs). Adding tasks to the sprint item is more complicated than it has to be and is not polished enough. For example, I’ve found it funny how the presenter was himself not aware of a usability issue, routinely skipping with a quick double-tab the iteration drop-box when entering a new task (0:36:49 in the video).

In general, when I look at the new task dialog, the worst memories of the Team Explorer go through my mind, and I can’t help but ask:

• Why this warning “The field ‘Title’ cannot be empty” on the top of the form? It is wrong on so many levels:
• Reading this warning even before I had a chance to enter anything in the title field insults me.  It really does.
• This message doesn’t have much value in informing the users how this form works. Users are supposed to use it several times a day, in all sort of circumstances, so that they will quickly learn how to use it and will know even more about it than the guy who has developed it. Because this guy only knows how it is supposed to work, and the users know how it really works.
• There are bazillions of web sites in the Internet having a form, and absolutely most of them (like, 99.9999%) indicate obligatory fields directly in there (by using a star, or a less bold color for optional fields). Why not follow this practice?
• Isn’t the title field actually the only one obligatory field in this form? If it is, why do they need to use a validation framework producing this very robotic, inhumane wording of the message, instead of just checking it with a single if-statement and printing a handcrafted message?
• The message is technically wrong, because, well, the Title field can in fact be empty. If anything, it must read “You probably don’t want to create a task with an empty title” and appear only after the user hits Save.
• Why having users to read anything at all? Just mark the title field red. Your users are software developers. They do really know, what it means.
• Why the title field doesn’t have a title? All other fields have one.
• Why do we need an iteration drop-box just below the title?
• Isn’t the description what is the second-important field after the title, so it must be directly below it?
• Do we want to have sprint items spanning across the sprints, or what is the other reason for the possibility to set the iteration on the task level?
• Even if we want to enter iteration on the task level, is a drop-box the best possibility? Or perhaps just a check-box “not in this iteration” would suffice to move the task to the next sprint?
• Why do we both use words iteration and sprint? Can’t we just agree once what software process we’re using and configure TFS so that it uses consistent wording everywhere?
• Status and Details are split into two columns. Sometimes you have to do it, if you have a lot of information and not enough screen real estate. But in this case, why can’t we just scrap a lot of fields? This is a form to enter a new task, not to edit existing task, right? So, for a new task, we for sure don’t need the fields State, Reason, Blocked, Activity, and History. Let’s see if we can remove even more fields.
• Backlog Priority. The same question as with the Iteration. Do we want to have tasks with a different priority that the corresponding sprint item, and why? Even if we really want, why not implementing the priority by using drag and drop just like they can do it with sprint items?
• Area. This is something I haven’t understood in TFS and still refuse to understand. I mean, why do we need to have two trees (the iteration tree and the area tree) if we can live with a single, combined tree? Well, OK, if your business is to develop a leading desktop and server operating system deployed everywhere in the world, your component and iteration structure might become so complicated that this would require splitting these two fields. But Microsoft, there are really other companies who develop software using the Microsoft Ecosystem. And most of them (like, 99.9999%) never ever develop a product that would have more than a couple of iterations and components in the same TFS repository. Besides, in the most scenarios, the person(s) assigned to the task uniquely identifies the area, because, normally, it is a good idea to clarify responsibilities in the team even before the first sprint planning starts, so that everybody knows that, say, Alice is the database gal, and Bob is the frontend guy, and Chris oversees the REST web services. So, let’s make an uneasy decision and remove the area field and see if the percentage of those who disagree can be ignored!
• The “Links” functionality seems to be implemented in the same way as in the Team Explorer — each link is an item in a list box, and you have to push a button every time you enter a link to add it to the list. Yikes. Let’s just allow users to paste links into the description field, and recognize and summarize them in a list automatically. Even Facebook can do that.
• The “Attachments” functionality has a similar issue. Just let folks to copy the image, PDF, DOC or whatever file they have and paste it into the description.
• The “Description” field. There is no rich text formatting there, is it? Why? You have to be a Byron to compose a really expressive description without usage of typographic tools and formatting.
• The buttons below the form. TFS is a product targeted for Windows developers. If there are such persons who are Mac or Linux users but still use TFS, God will surely bless them, but let’s concentrate on our core public. And in Windows, these buttons are always called “Apply”, “OK” and “Cancel”. Always. Ever.
• And last but not least, the Assigned To field. I don’t know how does it exactly work in there. In the Team Explorer, I couldn’t select several assignees. I was constantly finding myself in a situation where a task can be done by anyone of several developers, and wanted to leave it up to them. The one who cares most should pick up the task. So I ended with assigning the task to a dummy user “nobody” and communicating with the affected coworkers offline.

Gee, that was a lot of harsh critique. I’m looking for someone who can teach me how to criticize in a less aggressive way…

Anyways, here is what I would propose instead:

I push a button to create a new sprint item. A window with Microsoft Word like UI opens up.

In addition to the usual text styles, there are styles to represent sprint item title, task title, a person and so on. The current text style is preset to be sprint item title. I type the title and hit Enter. The text style changes to description. I type the description. Now, when I type “@Damian”, the window automatically recognizes it and changes the text style to person. Similarly I can enter a task title.

Generally, I communicate with my team in the same kind I would use if I was writing an E-Mail with tasks. When I hit the Save button, the following happens in the background. TFS parses each sentence. For each sentence containing text with task title style, it creates a task and assigns to it all the persons mentioned in the same sentence. The persons get notification links leading to this sprint item (not to their particular task). The tasks are automatically assigned to the same iteration the containing sprint item is assigned to.

I can right-click on a task title, and an overlay (in the same look as the overlay in Microsoft Word) appears near it, allowing me to enter the remaining work hours for it and change its state. These changes are directly represented in the text, for example by partially coloring the background of the task title, or by striking it through.

One way to reassign a task is by directly replacing the person’s name in the corresponding sentence. When I save the text, a history will be created for that change, and I can optionally enter a comment for it. I also can pass the ball by writing an additional sentence, mentioning the task and another person there. In this case, this additional person will be assigned to the task and will be notified.

If any of words can be recognized as Microsoft Exchange calender resource (eg. Meeting Room, Beamer etc), it will be underlined. If I click on it, Outlook will open with a meeting planning window. Me myself and all persons mentioned in the same sentence will be automatically added to the meeting, and the sprint item and task titles will be put into the subject.

I believe, this UI has several advantages. For the end users, it is plainly more ergonomic and allows for a more humane communication at the workplace. For the decision makers, it looks not less enterprise-ready than the original TFS interface, because it just capitalizes on (and integrates with) existing enterprise-grade tools like Word and Outlook. For Microsoft, it allows to additionally target startups and middle-sized companies still working “in startup mode” because of much less bureaucracy in the UI. And, just in case Microsoft would like to support other big companies allowing them to develop software as huge as Windows using TFS, they can still hide somewhere in the context menu the “Properties” menu item, opening the full property sheet of the corresponding task. But, frankly speaking, I would rather not do even this and allowed to access the full scope of the task object by using a command-line tool like tf.

But that’s another story.

This is a test of your organization software development culture. The answer “a” gives you 0 points, “b” gives 1 point, “c” gives you 2 points, etc. Sum all the points. You can spent as much time as you want to.

1. Software Design Approach.
You need to program a new feature.
a) You read a manual, a book or search in google for possible solutions, and select the best one.
b) You inform yourself about the used tools (programming language, framework, templates etc) and come up with an own solution.
c) You come up with at least two different solutions before you start coding, compare them, understand positive and negative features of them, tentatively select one of them, code, test, and perhaps switch to another approach.

2. Code implementation approach.
a) You find a solution in google and paste it to your code without reading.
b) You find solutions in the Internet, read them, and re-implement them, using your code style.
c) You write your own solution.
d) You write your own solution and open source it.
e) Same as above, but you also write a unit test.
f) Same as above, but you also write some documentation.

3. Interface design approach.
You have two different processes and have to design an RPC interface between them.
a) You don’t create your own interface, but find and use some another existing function instead, that sometimes coincidentally does almost the same thing you need.
b) You think of one possible piece of data that should be transferred between the systems, define a function for that, and call it a day.
c) You think the interaction between systems through, possibly helping yourself with UML sequence diagrams. You go through all use-cases you want to focus on in the first version, and ensure that the API has a complete set of functions and data structures.
d) Same as above, but you also implement both sides of the interface (create DTOs and function proxies) as a library.
e) You also check that both sides of communication are always in a predictable, correct state, no matter how the other party might misbehave during the communication. You ensure absence of racing conditions. When appropriate, you implement the communication in a secure way. Both sides of the communication log the sent and received data to enable API debugging.

4. System architecture design approach
You have a single feature that has to be distributed across different systems (eg. client / server system, or systems with several CPUs).
a) You find at most one possible cutting line and cut the feature along it.
b) You split the feature into the layers (eg. Application & UI, Middleware and Hardware-specific Code) and draw the border along a layer.
c) All your features are split along the same line, so that layers nicely map to systems.

5. Bug fixing approach
a) You guess bug reason without reproducing it, perform a change, check that the software works, and close the ticket.
b) You first ensure the bug is present by reproducing it, then proceed as above.
c) You reproduce the bug, then understand exactly why it happens, then fix it, then check it is fixed, then remove the fix, check it is broken again, the redo the fix and check it is fixed, then set ticket to “ready to test“
d) As above, but you also create an automated unit test for this very bug, and run it every time you release the new version (or even every time somebody commits a change)
e) Same as above, but you also reflect what other parts of  software could have a bug of similar nature. For each such place, you reproduce the bug, implement similar fix, and test it.
f) Same as above, but you also post a wiki article / communicate with other team members in case of an especially nasty bug.
g) Same as above, but you also submit a bugfix, in case you’ve fixed an open-source software.

6. Usage of SCM
a) You don’t use any SCM
b) You commit once a week without writing a comment.
c) You commit once a day, but regularly have changed files you never commit to SCM, and your comments are not very informative.
d) You commit several times a day; after each commit you don’t have any changed local files anymore. But you think branching and merging is dangerous.
e) You can freely use all SCM features (including merging). You prefer using SCM over commenting out unused code paths, because it is more comfortable.
f) You have hooks on SCM server (for example, a continuous integration server, an automatic e-mail, or a automatic policy checker)
g) You have an established code review process.

7. Release process
a) You just copy over some compiled files happen to be stored in various folders on your development PC. You don’t label the state nor have a trackable version identifier.
b) You set a label in SCM, but create your release by manually and selectively cherry-picking some specific files.
c) You label a release in SCM and create a release from that state automatically, so that you can always recreate a bit-identical release by running an automatic script.
d) After each release, you run automated tests and then optionally automatically deploy the software in production

8. Code Ownership
a) Each team member owns a specific set of source files. Nobody else is allowed to touch them.
b) Everybody is allowed to change any files. Nobody feels responsible for any file.
c) Everybody is allowed to change any file by implementing the change locally, testing it and sending it to the file owner with suggestion to check and integrate the patch.
d) Even when changing my own files, I send my change to a peer code reviewer and get his sign-off.

9. Communication strategy
a) Information doesn’t flow horizontally or flows accidentally (meeting someone in the coffee kitchen: oh, by the way, do you know that…)
b) There are dedicated persons (leads, coaches, managers) who are responsible for information flow
c) Information gets stored in the project’s wiki
d) Project’s wiki is a very popular highly visited place, not less entertaining than Facebook/twitter

10. Project planning
a) Software developers don’t plan projects and ignore project planning of other people (eg. managers).
b) Software developers try to achieve deadlines declared from outside (eg. by managers) and fail doing that.
c) Software developers write down an own realistic plan and work at least once a week with management to establish a common realistic roadmap.
d) Most deadlines are met.

26 to 37 points: you probably work at some Software Developer Paradise like Google

15 to 25 points: you’re industry standard.

0 to 15 points: you’re in hell, get out of here!

• This! they should teach in school http://t.co/VBcOTnUY #

Powered by Twitter Tools

• I liked a @YouTube video http://t.co/SGw1gS7M 張惠妹－愛到不能收 #
• 研究, 解决, 讲究, 讲解. 汉语有时候傢LEGO一样. #
• … 继续, 连续剧, 京剧 … #

Powered by Twitter Tools