Developer Summit, Architecture and Business value.
I attended Developer Summit last week and went mainly to the architecture sessions.
One trend I noticed was the wake up call for developers to close the gap to the business side of their organizations. It is a line of thought I have taken for granted, but that may be because I worked for five years as a bean counter before I became a developer. The colleagues that came straight out of some tech school and never saw the process and people side of software development might need the wake up call, but calling it a new paradigm to see software as an enabler of business is to devalue a lot of talented people around the word.
Another trend I spotted was that we have to understand that there are lots of architectural decisions made at the developer level. I think that discussion is a bit taken out of context without discussing the role and abstraction level of architects. We tend to call a lot of developers architects independent of the level of abstraction they work in. Both deciding between static methods or a singleton and the amount of external data centers are considered architectural decisions.
I think that you hand over the right to decide about thing in abstraction levels below yours as soon as you hand over your design to the implementor. As I wrote here, I think that one responsibility of an architect is to aggregate external information and spread it within the organization. Seen from the abstraction level point of view that would mean that every one within a developer organization should aggregate information relevant to his abstraction level and inform those at a lower level. Taken one step further you have to inform the ones ‘above’ you too, since small gravel can make the optimal solution undo able.
It is not about climbing the abstraction ladder the better you get. It is about finding the abstraction level you are fit for and grow within it.
Continuous builds instead of meetings.
Lots of times I have been involved in lengthy discussions about how to solve a problem and trying to guess what the user really wanted based on his initial request. It is not uncommon that implementing all of the possible solutions and lettings the user choose the one that satisfies his needs would have been done in a shorter amount of time than discussing it.
I’m probably rambling but if we have a continuous build, that is releasable, we could in many of these cases give the customer builds with all of the solutions and let the customer decide.
I have heard of development teams that has taken deliverable builds to such an extreme that they build Virtual PC images with their system preinstalled every night. So even if there is server software involved it is possible to create agile deliveries.
Installable daily builds and salesmen
I have quite often ended up in situations where the salesman has promised new or existing customer non-existing functions. Functions that took lots of overtime and ugly code to get done. When developers, more or less loudly, protests against this practice they are either laughed off or told they don’t understand the sales process.
Quite often these forced solutions are not tested enough so the client isn’t satisfied anyway.
Assuming you took my previous advice and created releasable daily builds, I suggest you deliver what you have at the moment and update with new functionality as it is done. With shorter iterations everyone involved gets a feeling of success. This will probably not work for all kinds of systems but I think that generally it is not devastating if you (re-)introduce a bug that a large regression test would have found. The risk is quite big that a suite of test that are run a couple of times a year will find less than an ever growing suite of tests that are run every day. Furthermore, the receiver knows it it non-critical since there a new deliveries soon.
I don’t think you should be afraid to deliver often. One way of removing that fear is to have a well organized automatic test suite and build environment.
Hidden information
I made a guest appearance at an old client recently and found that they had a handful of critical errors that were there only because no one had read what I wrote a year ago.
As I wrote here:
It is not enough to use the wiki to cross reference all the information about the current state, we also need to write down the discussions and misshaps that lead here. That way we can turn these vast amounts of information into knowledge that is transferable.
There is also terabytes of well written stand alone documents out there but it is to hard to find them.
Every organization needs a document repository that is easily searched. I still think a wiki is a really good thing to have but some documents work better as stand alone entities. Those documents must be easy to find. They need to be stored at a place that the organization members find natural to go to for information otherwise the time spent writing them is a total waste.
My personal aversion to writing software documentation comes from knowing that no one will ever read it. I’ve had several colleagues who have written lots of pages of junk just to intimidate any potential reader.
Since SharePoint Services is part of the OS now it is very easy to create a central place for documents.
So this is a call out to all project managers and team leaders: Please create a place where your staff can find and create living documentation. Everyone will gain from it.
Saving passwords
I am by no means a security guru, but can all you developers please end your stupid habit of saving passwords in clear text to the database.
It makes my cry when I click ‘forgot password’ on a web site and get a mail with my old password in it.
Make a hash out of the users password combined with a random value, called salt. Store the salt and the hash in the database. When the user later tries to log in you can hash the supplied password together with the salt and compare it to your stored hash.
Releasable daily builds
Share and store documents… Free.
When you do daily builds, a practice I think is essential for high quality software development, it is important to make sure the build is so complete and easy to find that the test team and sales force can choose what version, and when, to install by them selfs.
It is an accepted truth that the longer you wait to fix an error the more expensive it gets. If the test team can verify a fix the day after it is checked in to the source repository instead of waiting for the next sanctioned release both the feed back loop and cost gets smaller.
For this to work all of the organization has to work in union to keep the daily build complete. It will not work if someone is working by him self and checking in bad code because he ‘knows’ there is a long time until the next release. If the development is done for a customer that expects to see continuous progress it is extra bad if someone is checking in bad code. It is a problem that is not solved with unit testing since the result of those is easily manipulated by the rouge developer.
Everyone has to work together to make each and every daily build ready for release.
Top 5 – Group Writing Project Day 4
Today was the last day of the Top 5 – Group Writing Project
My entry from day one is here.
As usual, here are the ones a have read:
- Top 5 technology websites
- Songs That Make Me Insanely Happy – The Top 5
- Five Ways to Make Money Scrapbooking
- Five Killer Apps That Keep Me Using Kubuntu
- The Top 5 Google Tools I Use Every Day
- The Top 5 FREE Software Programs Every Writer Should Have
- Moving online journalism to Linux: Top 5 programs
- 5 reasons to use Ubuntu and not Windows
- Top 5 Autopilot Moneymakers for Your Website or Blog
- (Re)Fill Your iPod: Top 5 Ways To Find New Music
- Top 5 Board Games I Grew Up Playing
- Top 5 Easiest Ways to Solve Almost Any Problem.
- …$10 is a lot of advertising?
… and here are the ones I subscribed to:
- Top 5 Ways to Find What Makes You Happy
- Top 5 Things You Can Do For Your Kids…EVER
- Fantastic Five: 5 Freeware Apps You Don’t Know About
Share and store documents… Free.
Text Link Ads | $100 in FREE Links
TFS Listener for logview4net
Howard van Rooijen has created a template for creating listeners to Team Foundation Server events. This might come in handy since I was thinking of creating a TFS Listener for logview4net.
I am about to separate the SQL and EventLog listeners to an assembly for MS listeners. A TFS Listener is exactly what that would need.
Add: Share and store documents… Free.
Top 5 – Group Writing Project Day 3
Here are all the entries of day three.
Here is my entry.
Theese are the ones I read today:
- The 5 Smart Things To Do When You Purchase An Item With A Warranty
- Back To The Future – The Top 5 Old School Ways – That Still Work – To Get a Job
- Top 5 ways to display your RSS Feed Subscription Link on your blog
- Top 5 gradient color schemes for blog design
- Top Five Essential Practices for Developing Software
- My Blogging Swiss Army Knife: Top 5 Essential Sites For Bloggers
- Top 5 Blogging Myths
- Top 5 reasons I switched to Sony Ericsson
- Top 5 Free Webmail Services
. and here are the ones I subscribed to:
Unshelve files in TFS
If you are looking for your shelved changes in the Source Control Explorer you are out of luck.
There is a tool item in the Pending Changes windows for managing you shelved files.
