Oh yes, another from No Silver Bullets:

“The hardest part of the software task is arriving at a complete and consistent specification, and much of the essence of building a program is in fact the debugging of the specification.”

You best believe. I love this explanation. For starters it unburdens the people tasked with spec’ing the software from having to spec something that’s actually buildable. In most cases those people are UI specialists and business analysts who technically don’t know the first thing about actually building software. How could they realistically be expected to spec buildable software?

So in taking a specification and building it into actual software, we are effectively debugging that spec. Nice. Are you getting this Andrea? You’re off the hook, sorry not off the hook.

From No Silver Bullets:

“In the pitiful, multipage, connection-boxed form to which the flowchart has today been elaborated, it has proved to be useless as a design tool — programmers draw flowcharts after, not before, writing the programs they describe.

Second, the screens of today are too small, in pixels, to show both the scope and the resolution of any seriously detailed software diagram. The so-called “desktop metaphor” of today’s workstation is instead an “airplane-seat” metaphor. Anyone who has shuffled a lap full of papers while seated between two portly passengers will recognize the difference–one can see only a very few things at once. The true desktop provides overview of, and random access to, a score of pages. Moreover, when fits of creativity run strong, more than one programmer or writer has been known to abandon the desktop for the more spacious floor. The hardware technology will have to advance quite substantially before the scope of our scopes is sufficient for the software-design task.

More fundamentally, as I have argued above, software is very difficult to visualize. Whether one diagrams control flow, variable-scope nesting, variable cross references, dataflow, hierarchical data structures, or whatever, one feels only one dimension of the intricately interlocked software elephant. If one superimposes all the diagrams generated by the many relevant views, it is difficult to extract any global overview.”

Tools like UML are nifty, and if you have no choice but to convey a software design on paper then that’s where I’d point you. Remember though, it is still an ugly hack, in my opinion. Architecturally, at BOC, we strive for a design-build methodology where the guys designing the software are the guys building it. Sure it opens yourself up to the hit-by-a-bus syndrome but experience tells us that very few of our people get hit by a bus on a regular basis so it’s an acceptable risk.

The ideal tool for describing a software design is a modern programming language, in other words write code. In The User Illusion, Tor Nørretranders explores a powerful metaphor for human consciousness. One of the examples he uses is maps. As you add more and more detail to a map you have to add more and more information. In the end the only map of the world that has enough information to convey it accurately is the world itself. Anything else is just a best guess and is missing valuable information. The same applies to software, the only thing that conveys a piece of software completely is the piece of software.

There are good reasons to document the software development process like conveying a design to a team of developers who are tasked with implementing your design, or documenting what’s been built for subsequent development, etc. A reason I’ll never put on that list is that it makes for better software. Am I saying you don’t have to plan a lot on paper before hand? No. Am I suggesting you always jump to code and write first? No. I’m suggesting you only document on paper what you as a designer feel will move you towards better software.

Even in the cases where I have to document a design in order to hand it off to a team, I will typically design the system in code. I’ll write up a simple, stripped down version of the application in code and then I’ll document the application I’ve built in order to create documents to hand to the team. If you think about that it ain’t optimal.

Okay, if you haven’t read the paper No Silver Bullets then you best start there before someone yells at you.

One point made in that paper talks about the gap between average software development and the best:

“The gap between the best software engineering and the average practice is very wide, perhaps wider than in any other engineering practice.”

Based on my personal experience, I tend to agree with Mr Brooks. Not only that, it is just that very gap that allows me to dream of what’s possible with boc.

At one level we continually strive to be at the ‘best’ end of that gap and be able to leverage the fact that there aren’t a lot of us over here. On another level, we also hope to be able to share that by growing more people at that end. By grow, I mean people. School’s try but few, if any, will get you to the right end of this gap. Working with us at boc will get you there. We’re new at this part and it’s something we’re only scratching the surface on, however, it’s the part that gets most of us excited.

We already know how to grow the best software, now we’re learning how to grow the best software people.

Jaimie sent me this link the other day, Don’t Repeat Yourself, saying something about hearing my voice as he read it. I have to say I like it. I live and die by it when it comes to software architecture and database design. I don’t make decisions to duplicate data lightly and will exhaust every available alternative first. To a fault some may argue.

Why? Simple, it’s painful and expensive to duplicate data.

Duplicating data is typically pretty innocuous stuff in the moment and I find it often isn’t even viewed as duplication. Say you’re youtube. Sorry, say you’re google, and you keep a table of data containing a row for every video viewing. It contains some simple data, let’s say video id, date of viewing, user id who viewed, etc. If you need to calculate how many times a particular video’s been viewed then you can perform some type of simple select:

select count(*) from VideoViewHistory where ixVideo = ‘1’

A very common form of data duplication would be to have this table as well as having a column in the Video table called NumberOfViewings. Each time the video’s viewed, we insert a row into VideoViewHistory as well as incrementing the number in Video.NumberOfViewings.

This approach is very common, bordering on a standard. It’s considered an ‘optimization’ as you’re saving a trip to the database and what could be a relatively large select statement being run very often.

I agree that it also may be the best design and it makes good sense in a lot of cases, however, what is often ignored during the design process is that this is an expensive and less maintainable approach. Trust me, any form of duplication increases your chances to introduce bugs and makes the code base more expensive to maintain.

All of this must be factored into any decision to duplicate data which is what this approach is doing. You have to write more code to ensure the multiple data sources are in sync. Guaranteed you will at some point have to deal with edge cases when the two sources of data get out of sync.

Developers often winch that the biz guys don’t understand technology. Well geek boys, it works the other way too. If you’re the one paying the bill to maintain this code base five years from now, do you care more about some extra database trips or the brittleness of your code base? Brittleness translates directly into dollars spent. There’s far more to designing good software than database trips and performance…..I think……

Try this if you want to scare the pants off the average product manager at the average software company. Tell them you’re implementing 20% projects.

“Google requires engineers to spend a day a week on projects that interest them, unrelated to their day jobs”

Disclaimer: I know nothing of Google. I’ve never worked, visited, or otherwise been a part of the monster. All I know is bits I’ve read in the press so this is all just my take and nothing more.

Gmail began as a 20% project. Developers love to tinker with technology, it’s why they’re good at building software and this idea plays into that. Whether you admit it or not, your developers are not spending 95%, 90%, or even 80% of their time working directly on your companies deliverable software. They’re also working on projects that interest them. Endorsing this, and bringing it out in the open, allows you to tap into the knowledge they acquire in an open and meaningful way.

Turnover within software development often comes down to sheer boredom. Developers tire of the same old code base, the same old approach to the same old problems. Jumping ship, and moving to a new organization offers the excitement of new challenges, fresh ideas, and new processes.

On the other side, when you have new people join, they bring with them new ways of approaching problems, new ideas on existing processes, etc. My take, 20% projects reduces turnover and training costs while increasing overall productivity.

Truly excited, passionate developer says: “I’ve got a great idea, what if we built a foobler into our product?”

Guy in charge of his ‘hours’: “Sounds interesting. We’ll need to build a business case to demonstrate it’s ROI”

Truly excited passionate developer heads back to his desk and continues down the slope to becoming bored apathetic code jockey. After a few more exchanges like that one, no one will hear his ideas any longer. He’ll learn the real lesson, his ideas aren’t needed.

Here’s the same guy with 20% projects in place, talking to 3 other developers: “Hey, do you guys have a 20% project you’re currently working on? I want to build a foobler into our product. We could build a prototype as a 20% project and start using it internally.”

You now have excited, passionate developer taking on roles like salesman, project manager, team lead, consensus builder, support rep, etc. They’ve been given a medium to spread their passion and excitement virally throughout the organization. They have the power to act on their passions and take real action. They’re building community, they’re thinking outside the role of code implementer, they’re engaged.

“Toyota does a great job of engaging their employees. Toyota employees are required to submit two suggestions per month that they can implement themselves or with a teammate. As a result, Toyota receives about 1.5 million employee suggestions for improvement each year. More impressively, 80% of these actually get implemented! Even though many of Toyota’s employees perform repetitive manufacturing jobs, this approach fully engages employees in improving their work processes.”

20% projects are meant to facilitate the growth of your individual’s, allowing them to be creative and use their imaginations. They can actively take on new roles, make mistakes, learn by doing, take on responsibility, feel in control and capable of contributing.

Quality people quit companies when they know they lack the power to change things. 20% projects addresses that head-on. While it’s great to end up with a product like GMail, in my opinion any actual products that come out of something like this is just gravy.

People are most productive and work best when they enjoy what they’re doing and most importantly have a sense of ownership. You can ask people to be leaders, take responsibility, innovate, etc until you’re purple in the face. People learn through action not orders or lessons. 20% projects are a stepping stone to 100% projects. It allows people to enjoy their work and learn that it isn’t as important what you do as how you do it. In the beginning they may pine to work on their 20% projects but over time their passion will bleed over and infect all of their projects. If you’re lucky, in time, you’ll be unable to distinguish when people are working on 20% projects or not.

The religious argument of exceptions versus return codes comes up more often than I honestly thought it would. Maybe I’ve been isolated in my exception based cave all this time?

I’ve travelled a path that started out return code based by virtue of being in the early Microsoft web days. I then came out of the return code forest onto the exception path. I personally prefer the exception path, unfortunately it seems that people in the return code forest like to climb the trees and chuck rotten apples at us clean living exception path people trying to mind our own business.

My personal take? This is one of the few topics I don’t see eye to eye with Joel on. Apparently I’m not alone on this.

I also agree with Raymond that exception based code is more difficult to write well. So is raising three children instead of one but that doesn’t mean it’s to be avoided.

Is it simpler to write return based code? Yes. Does it sometimes require more design, more thought to write good exception based code? Yes. Does that convince me to revert to return based code? No. Is this writing style of asking myself questions lame? Clearly.

The whole ‘using exceptions for business processing’ argument always comes up as part of this. My rule, which is relatively standard, is the 70/30 rule. Exceptions should be returned from a method no more than 30% of the calls to it. More than 30% means it is no longer considered an exceptional situation and the code should be tagged for refactoring.

It’s actually kinda simple, only throw exceptions in exceptional situations, it’s built right into the name. Sometimes you won’t know what that is until you get an application into production which is where the 70/30 rule comes in. Do your best, profile, refactor as needed.

If you follow the 70/30 rule then it means that the whole performance bogey man doesn’t exist. The point of exception based code is that everyday typical processing doesn’t encounter the overhead of throwing exceptions and therefore doesn’t suffer from any performance hit. If you’re throwing exceptions from a method for 50% of the calls to it those cases can’t really be considered exceptional cases can they? Ie, you’ve written poor exception based code. That’s fine, fix it, don’t give up on the entire concept.

I recently made a few somewhat uninformed statements regarding Ruby On Rails. As always, Joel has a take on it. Had I read this before I could have just said “what that guy said”.

“Ruby is a beautiful language and I’m sure you can have a lot of fun developing apps it in, and in fact if you want to do something non-mission-critical, I’m sure you’ll have a lot of fun, but for Serious Business Stuff you really must recognize that there just isn’t a lot of experience in the world building big mission critical web systems in Ruby on Rails, and I’m really not sure that you won’t hit scaling problems, or problems interfacing with some old legacy thingamabob, or problems finding programmers who can understand the code, or whatnot. So while Ruby on Rails is the fun answer and yes I’ve heard of 37 Signals and they’re making lovely Ruby on Rails apps, and making lots of money, but that’s not a safe choice for at least another year or six. I for one am scared of Ruby because (1) it displays a stunning antipathy towards Unicode and (2) it’s known to be slow, so if you become The Next MySpace, you’ll be buying 5 times as many boxes as the .NET guy down the hall. Those things might eventually get fixed but for now, you can risk Ruby on your two-person dormroom startup or your senior project, not for enterprisy stuff where Someone is Going to Get Fired.”

Speaking of processes, there’s also a Capability Im-maturity Model. The levels:

0: Negligent

-1: Obstructive

-2: Contemptuous

-3: Undermining

Hmmm…..CMM, CIMM, can you tell them apart?

Okay so we know there are some sucky parts of agile processes, is there anything good in there? Most of the great parts look surprisingly similar to the bad parts. For starters:

“YOU HAVE TO USE YOUR BRAIN!”

If you work in software, and you’re not a robot, then you want to use your brain. Sure, 8am the day after your 30th birthday you may want to coast but in general most people want work that requires them to be present, contribute and think. How many people do you know who ‘phone it in’ during their day jobs only to spend all their off hours on a project they’re utterly passionate about?

If you’re a business owner, do you want a process that attempts to get every team member thinking about your business goals in every decision they make and every action they take? Or do you want a process that requires a small subset of people to think and then hand off their attempt at documenting those thoughts to a team of glorified line workers?

Am I biased? Of course I’m biased, because I’m not a robot. I’m biased to providing real value to business owners while providing a model to work in that places value on that wrinkled piece of sponge held in people’s brainboxes.

Traditional processes creep in when intelligent, collaborative models are forced to scale too aggressively. It’s difficult to control this model and that scares people. You can have the control back but only by introducing more traditional models that have a proven record of stifling innovation. They come at the sacrifice of that individual intelligence. You really can’t have it both ways.

A warning to the non-technical, this is going to get technical.

While I’m sure they weren’t the first language to do so, C# made properties first class supported constructs and I thank them for it daily. Previously, or currently in other languages, this was often accomplished through accessor methods, typically named something like GetValue(). You can then protect your variable, or add more logic, through this technique. If you’re lost at this point then try this and this.

l was asked today “do you find it weird to use a public property to access something from inside the class where that property exists?” To elaborate, and take it one step further, in example. We have a class named Person. We have a private integer variable in the Person class named _bodyHair and, well I’ll leave it to your imagination what we’re storing in that variable. You’re writing some code in the Person class, if you had to access that private variable _bodyHair how would you do it?

Would you access the variable directly or would you create, and use a property, or accessor method? In the early stages of a class, accessing the variable directly is simplest and most obvious. It may even seem a tad bonkers to create an essentially empty private property and add the performance overhead of the added calls.

I do just that almost 100% of the time. Why? My primary reason for doing anything is that I’ve been burned by not doing it a lot in the past. In this case I’ve been burned by accessing a variable directly and then down the road having a bug related to it’s return values. Something like null being returned when we want -1. So I refactor the class, add a property containing that logic. I’m then left refactoring all references to that variable over to the new accessor property. Annoying but not a big deal.

Burn #2. I’ve spent days, possibly weeks, chasing down a particular species of bug. It’s a simple one. A developer accesses a variable directly instead of through it’s property. In the above example, doing so allows that null value to trickle up the chain and get it’s nose into business a -1 wouldn’t have. Not a big deal, just lost time.

Let’s get crazy and contemplate if there’s a way to reduce the odds of generating a bug like this again? I realize this isn’t anyone’s job and we’re probably messing with the very fabric of corporate software development but humour me. The problem is accessing a private variable directly in the class you’re working in. It’s easy to miss the fact that a private property for that variable exists and thus miss the logic you need. There’s no way to make a variable extra private to prevent access from anywhere outside of your property. Typically the rule is to go ahead and access the variable directly unless a property has been defined. It’s the float in that rule that allows for the burn #2 bug.

So why not just move all access to properties? Doing so eliminates, or at least reduces, the chances of human error. I have been doing this myself for years. I rarely, if ever, access a variable directly even within the class it exists. I use properties for almost all variable access. This makes it simple to add any required access related logic down the road as well as greatly reducing the risk of a relatively common bug. It does introduce a potential performance issue in the added calls and means more code. I tend to err on the side of simple code and reducing the chances of bugs. Am I nuts??