Dev.Hell

Proverbs of Dev.Hell

Jason Franks — Wed, 11 Mar 2009 21:02:16 GMT

with apologies to William Blake

(Note: some of these are bastardized, but many are direct quotes. Some of them are my own.)

In design phase learn, in development teach, in between jobs enjoy.
Drive your compiler over the bones of the legacy app.
A fool sees not the same dependencies that the wise man sees.
Eternity is in love with the productions of time.
The hours of folly are measured by the clock, but of wisdom no clock can measure.
A former colleague revenges not injuries.
The most sublime act is to set another before you.
Shame is pride's cloak.
The developer condemns the context, not himself.
Your exclusive class is the doom of my inclusive library,
What is now proved was once only imagined.
The UML contains; the APIs overflow.
Always be ready to speak your mind, and a base dev will avoid you.
The eagle never lost so much time as when he suffered to learn from the crow.
He who has suffered you to impose your design upon him, knows you.
The tigers of wrath are wiser than the horses of instruction.
Expect poison from the standing codebase.
You never know what is enough until you know what is more than enough.
The weak in courage is strong in cunning.
If others had not been foolish, we would be so.
As the dev chooses the fairest platform to lay his code, the corporation lays its curse on the fairest joys.
To create a little flower is the labour of ages.
The best wine is the oldest. The best water is the newest.
Prayers code not! Praises do not pass testing.
Side with the medicore professional ahead of the gifted amateur.
As the air to a bird or the sea to a fish, so is contempt to the contemptible.
Improvement makes straight codepaths, but the crooked paths without improvement are paths of genius.
Sooner murder a project in its planning than nurse unacted desires.
Truth can never be told so as to be understood, and not believed.

And one more:

My Pretty Code Tree
A project was offered to me,
Such a project as May never bore,
But I said 'I've a pretty code tree.'
And I passed the sweet project o'er.

Then I went to my pretty code tree,
I wrote her new features by night,
But the Lead turned away with jealousy
And her bugs were my only delight.

Design.Principles

Jason Franks — Tue, 02 Sep 2008 18:51:55 GMT

Slight change of plan; I'll get back to the topic I offered last time--"Smarter/stupider UI"--after this one. I think this needs to come first.

This is my attempt at a quick, no-bullshit set of principles that determine what makes a good design. None of this is headline news, but I learned this stuff the hard way and I am continually surprised by how many people do not consider thse issues at all.

1/ Control Dependencies
Every module or subsystem should be as independent as possible. Build upwards, not across--each unit is build on top of more basic units, but dependencies to its peers should be carefully and systematically managed. Certainly, they should not ever depend on functionality from layers of code that lie above their own.

For example, a server is dependent on a database. Logical entities that exists inside the server inherit this dependency--but the relationship between those entities must adhere to strict rules. The stricter those rules the easier it is to create the entities and the easier it is to maintain or replace them. The server should also allow clients to connect and communicate with it, but giving the server detailed knowledge of those clients will lead to lunacy, despair and death.

2/ Inheritance vs Genericity
Know when to inherit and when to be generic; know what's an interface, what's an ancestor, and what's an aggregate.

Any base class that exists to unite two otherwise distinct hierarchies is probably a mistake--there are better options. Perhaps some this class owns both objects and controls how they interact directly? Perhaps the features you want to enforce should be encapsulated into an interface? Perhaps you can build a a generic, type-independent object that can add the functionality to class belonging to any hierarchy? (Yes, that means 'templates'). Perhaps an adaptor class is required to wrap conforming behaviour around a specific class (The ever popular 'adapter pattern')

3/ Design Patterns Do Not Maketh A Design
Having read DESIGN PATTERNS does not make you a good architect. Mere use of design patterns does not make a product well designed. If the object model is incorrect, no design pattern is appropriate--develop the hierarchy first and then determine which patterns are useful to the system.

If you find yourself in Mad Scientist terrirtory trying to crossbreed two distinct design patterns you are probably barking up the wrong tree. Clean the whiteboard, get a haircut and think again.

4/ Occam's Razor
Write as tight as you can: no hobbyhorse coding, no playpen libraries. More code = more dev time + more bugs + more QA. That adds up to a greater possibility of failure. Plan for the future, but don't build what isn't necessary. The simpler solution is better.

The cliche about 'premature optimization' belongs here--code needs to be correct before you worry about how fast it is. Counting CPU cycles is pointless if the system doesn't work. A cleaner, slimmer design will perform better than a fatter, more complex one; it really is that simple.

5/ Stratification
Any reasonably-designed application has at least a couple of layers in it; perhaps just front-end/back-end, but perhaps a more elaborate tiered system. It's a great way of controlling dependencies (point 1 above) and maintaining functional modularity. It's often the only way to provide interoperability across platforms or systems. But it's easy to go overboard.

Every new layer introduces a lot of new code and, as discussed in 4, that leads to extra maintenance. Every layer that gets between thee programmer and the source of an error makes it more difficult to locate that error. Not every new feature requires a new layer. If your new layer is just used for pass-through it's probably unecessary.
6/ Magic Happens
There's no getting around it, sometimes 'magic' is necessary. The programmer waves his wand and the soup congeals into catfood. Sometimes you discover a hole in the design, or there's a corner case you didn't expect, or the pieces just don't fit the way you thought they would, and you just have to hack (excuse me, 'magic') them together to make a deadline.

As the Amazing Jonothan says, "Sometimes magic sounds like tape." Duct tape, to be precise.

There's no avoiding it, but if your design calls for magic from the outset it's not really a design--it's not a cauldron of soup, it's a crock of the same old shit.

-- JF

Dev.Process

Jason Franks — Wed, 06 Aug 2008 17:09:55 GMT

Software Engineering Methodologies are a great way of selling textbooks.

Waterfall, Extreme, Agile, every couple of years there's a new style, a new buzzword, a new technique that will Solve All Your Problems, Meet All Your Deadlines, and Reward You With Meats, Cheeses, Riches and Massive Job Satisfaction.

I was recently asked which methodology I like best. Slayer or Pantera? Levi's or Wrangler? My apathetic response was met with puzzlement, and then with headshaking. "Grumpy old bastard, should have known..."

But I'm not that old, and I'm not that grumpy.

I believe that it is valuable to have a systematic approach to building software, and that any method (let's drop the '-ology', my wrist is already sore) is better than no method at all. I just don't buy ionto any particular one. I just don't believe that the way you structure your development cycle is more important than maintaining discipline within those cycles in order to incrementally build and enhance a product.

(Don't get me started on people who don't understand that development it is, indeed, a cycle). Any software project that doesn't follow this cycle is going to fail, regardless off the 'Methodology' fromt he textbook you chose because it had a busty geek chick on the cover (yeah, I bought that one too.)

0. REQUIREMENTS
If you got no requirements, you got no product. Either you're gonna be out of a job soon, or you're living the glamorous lifestyle of a Hollywood hacker. If you were not involved in a car chase, a shootout, or a cocaine-and-hookers binge in the last twelve months then you need to be asking for requirements before your project can proceed.

1. DESIGN
Design is paramount. If there's no design, or inadequate design, it doesn't matter how strictly you adhere to your Methodology.

Make sure you address the requirements. Design for the future, but make sure you address the requirements of the present--otherwise there is no future.

You don't have to design every last class and routine up front, but the high level design needs to be set in stone before a project begins. No design is going to be one hundred percent perfect, so you have to allow some wiggle room--but have a big picture design and stick to it. Smaller subsystems may be designed later in the process, but be wary of spending too much time on this--if a small feature requires a lot of design, either it needed to be part of the grand scheme or you're fiddling. Don't overdo it.

2. SCHEDULE
Once the design phase is done, the implementation effort needs to be properly planned so that those designs can be built out in a logical and efficient way, according to sa chedule--no matter what 'method' you are using to determine that logic or schedule.

You have to have a detailed schedule if you have a deadline. And there's always a deadline.

3. IMPLEMENTATION
Stick to the design as closely as possible. The more design decisions you break the shittier the codebase becomes. Higher level design breaks cause bigger problems. It's that simple.

Be honest about the schedule. If you've slipped it needs to be reported, not covered up--the sooner that a problem is known the cheaper it is to fix it. This will allow you to address the problems properly, rather than running around screaming, pointing fingers, laying blame and finding scapegoats when the deadline is missed, the budget is blown or the project is a failure.

If the schedule slips too badly or the design is broken too many times you're in real trouble, probably because insufficient effort when into the design and planning phases.

Don't break the build. The source repository is not a backup drive. Don't check in code that doesn't compile or link, you may very well end up forcing the rest of the team to be idle while you fix the problem--or forcing somebody else to fix your mistake. If you need to version broken code start your own local source repository or take a branch.

Hack Smart. Sometimes you have to take a shortcut--something isn't done in time, something didn't work, some pieces didn't fit together right, something was missing in the design. If you have to hack, do it smartly--document exactly how the hack was created and why. Even hacks should be well written and object-oriented--if the hack is clean enough it may become part of the design (an adaptor class, for example). Hacks should be easy to remove when the problem you're hacking around has been resolved.

Refuse New Features. Even if they fit the design--or seem to. They're not on the schedule. Even if the customer agrees to change the schedule you should resist--scope creep is insidious and demoralizing. Take the moral high ground for once. Grow a spine. You're not gonna win this every time, but, if you don't resist you're going to get caught in the Neverending Story--and that usually ends in failure of one kind or another.

4. QA
Schedule enough QA time. You know this never happens, but now is a good time to start.

Be super-disciplined about code reviews, bugfixes, unit tests. Lock the codebase down. The closer you get to release the fewer checkins should be allowed and the more closely vetted they need to be. If this means that a big part of the team is sitting idle, then... good. They deserve a break. At this point it's cheaper to pay them to surf google than to introduce more bugs.

Laugh rudely at anybody who suggests a new feature be added.

5. SHIP
Champagne and caviar all around.

6. CLEAN UP
Clean up the puddles of vomit and the empty pizza boxes. Conduct your post mortems.

7. NEW REQUIREMENTS
Gather new requirements.

Analyze failures in the previous cycle or cycles and correct them, wherever they lie--in the design, the scheduling, the team structure, wherever.

8. GOTO 1.
// ******HACK****
// This should have been a do-while loop. I screwed up the design of the article and now I've had to HACK to get it done in
//time.

NEXT UP: (Whenever that might be): Smarter/Stupider User Interfaces.

-- JF

Design.Blues

Jason Franks — Mon, 12 May 2008 17:59:07 GMT

DESIGN.BLUES
As regular readers have no doubt noticed, my overriding interest is design. While it's true that many success stories in the volatile world of IT have been due to luck or good timing, that's not a sustainable model on which to base a line of products or a business. Design discipline, I contend, is the primary difference between continuing success or ultimate failure in the software industry.

Most places I've worked design has been a problem of one kind or another. Usually, in small companies, there isn't any design of if there is, it's been abandoned. Even at the bigger companies this can be a problem: I worked for a software giant for a while and the site I worked at was utterly unproductive because my management was too frightened to authorize any kind of design... so they kept us occupied with busywork until head office shut us down completely. Then again, I worked at a tiny company where the design was held in such high regard that it prevented us from ever shipping any product: the architect was so intent on achieving the perfect design that he changed it on a monthly basis.

Right now, design is the main part of my job. I've designed software before, but usually it's been covertly, in the face of management who though design was 'too expensive' or that the direction they themselves provided (in one case, an Excel spreadsheet) was more than sufficient. My first big project in this capacity kicks into gear next week and I thought this would be a good opportunity to assess my position on the subject.

Resistance is Futile
At school, we're all taught that design and documentation is of key importance, that planning a project properly is vital to its success. Why, then, are we so loathe to engage in the practice?

Well, firstly, because authoring a design means taking personal responsibility. If the design fails than it's easy to point a finger at the designer--he designed it, it's his fault. This approach is, frankly, not good enough. We are engineers, designing is what engineers do. Any project is much more likely to succeed, in the long run, if it has a design than if it's assembled ad hoc by the a dozen different members, none of them working to a certain direction. Yes, sometimes the design fails... but it's much easier to fix it if there was a design to start with. If the project is organized it can be refactored; if it's not it must be rewritten.

The second problem is that, well, design isn't coding--it involves writing words and drawing UML pictures. Developers code, right? Writers write, artists draw pictures, coders code. If we're not coding we're not working, right?

Wrong.

Writers and artists design their works just as software engineers do. Books, screenplays and essays have structure and shape; and so do paintings, photographs and comicbooks.

Design OD
Of course, it's entirely possible to take it all too far. Projects can overdose on design procedure.

I have a friend who is contracting to a giant IT business on a giant project, and his life consists mainly of attending seminars and workshops and coaching an army of project managers, while his own work gets further and further behind. Instead of doing his job--designing and building a system--he is being forced to appease a management hierarchy who are in turn trying to cover their own arses by enforcing a ridiculously complex procedure at the expense of any type of productivity whatsoever.

Designwork is just as productive as coding. Arse-covering is not.

Down and Dirty Documentation
I work at a much smaller company--somewhere between 50 and 100 employees. In my capacity as design-monkey, I have produced a slew of documents and UML diagrams showing how I want the system to work... but not anything close to what my friend at the big boys is dealing with. I write short, highly targeted documents, addressing a specific problem or audience (high level design & integration is a specific problem, so is the behaviour of a complex algorithm). I tailor the format of the documents to the audience and the goal of the document.

People say that picture is worth a thousand words, but you simply cannot document a software system only with pictures. Studies show that a combining written words with a sequence of static pictures is the most effective way to communicate--comicbooks are a great way to teach skills or procedures. You can forge a synergy between the images and the works that is much easier to absorb than a slab of text or a hundred class diagrams. As a comicbook guy as well as a software engineer, this is something I've taken to heart.

I try to keep my design documents tight and to the point. I don't waffle on implementation detail; I don't show every single object or class or sequence, I just enough so that the team knows how the system needs to fit together without having every single detail dictated to them. They're smart guys, not children, they don't need to be spoonfed. Besides which, I know if I write too much the team just won't read it, even if I put LORD OF THE RINGS on the spine. There is a point where design ends and code begins, and I believe that finding it is the key to a presenting a successful design.

Once I'm happy with the design, I start to prototype it in code. Sometimes you can get a better insight into how things work from the inside and, as the architect of the system, I feel that it's my responsibility to assess the design from all sides. I need be able to prove that my pie-in-the-sky comicbook stories work as actual code if I expect the team to buy into it. I work remotely (29 hours is a pretty long commute to the office) but I will be actively coding with the team as the project proceeds--an architect in an ivory tower is no use to anyone.

OK GO
Once the system is designed it is up to the team to ensure that they stick to the design as best they can on the way to a release. It's never going to be a perfect match--there will be errors in the design and in the code-- but the closer we stick to the design the easier it is to control the schedule and to maintain the code after release. Unless the design is severely flawed there should be no stopping to reassess in the middle of the project.

The docs are pretty much done, the prototype works; next week I will present everything to the team and the build-out will begin. Let's go.

-- JF

This.Country

Jason Franks — Thu, 28 Feb 2008 22:06:40 GMT

This country, man.

We call ourselves the lucky country, the clever country. We say other quaint things like "Australia rides on a sheep's back." A former Prime Minister once called us "the arsehole of the world."

We have a new government this year, a Labor government that claims they want to put education first. Which basically amounts to talking a lot about buying laptops for schools, as opposed to pie in the sky initiatives such as lighting the fiber that's already in the ground so we can have proper broadband internet, or increasing teachers' pay. The minister for education wants to reduce the cost of Maths/Science degrees, because there is a clear and present skills shortage... but the reason students are deserting technology is not the cost of the degrees. The government needs to invest that money in the industry; our technology business isn't going to reanimate itself. This is why so many Australian techies--myself included--sell their skills overseas.

Then we have the University of Melbourne wanting out of the government-subsidized education game altogether; they want to be our Ivy League of One. We have the head of Monash University--once the biggest comp sci school in the country--demanding that the university be allowed to set its own fees, because the current costs are 'not dissuading students from applying.' In other words, he only wants rich kids at his school. Part of the additional revenue gained from those increased fees, he says, will go to disadvantaged students. I suppose those same disadvantaged students that he wants to dissuade from applying at his institution, and which he has disadvantaged further by jacking up the tuition costs.

Both of these guys, of course, are violently opposed to the government's idea of cutting full fee degrees for residents and putting those additional places on the government subsidy scheme... which, to be sure, is going to cut into the Universities' coffers. Obviously the government needs to pay for those extra places. We do have plenty of surplus cash for it. Perhaps our Education First government needs somebody to explain basic arithmetic to them--I guess we really are suffering for mathematics people.

Here's another good one: our Minister for Innovation is currently begging Japanese motor vehicle manufacturers to start producing hybrid cars in their Australian plants. Just weeks ago, Mitsubishi shut down operations here: the cost of manufacturing in Australia is getting too high. Does the minister really think he can persuade the Japanese to expand their operations right now? And why, exactly, is the Minister for Innovation asking foreign countries to innovate for us? Surely he should be speaking to Holden, the Australian manufacturer, about developing their own line of fuel -efficient vehicles? Or funding university research into same? I know Holden are owned by General Motors, but they've always been somewhat independent of their American parent.

We need politicians who can make policy, who can organize and lead and make decisions and innovate, people who know how to make things, how to build things. I'm tired of these guys who only know how to buy and sell. We need politicians who are engineers and educators and scientists; not lawyers and rockstars and MBAs.

-- JF

Stepping.Backwards

Jason Franks — Sun, 30 Dec 2007 18:49:27 GMT

I was planning to write an article about software quality, but I had some technical problems that prevented me. Which, I figure, is in itself a quality issue. It's not my aim, in this blog, to pick on specific products or bad user experience, but, when those problems are part of a major new operating system by the largest software vendor in the world, I thought that perhaps I should make an exception.

Y'know, I was really starting to like Vista.

It was slow, but it sure was pretty. I liked the way the new Start menu managed its size. I liked the wizbang Aero UI. I liked having a filesystem search function that a/ worked, b/ worked fast, and c/ did not try to hide its deficiencies behind an cute animated dog.

No compatibility issues; all of my old software and my peripherals worked great. I use my machine for image processing and publication design stuff as well as for development, and everything worked great... for about 3 weeks.

Last week Windows Defender started reporting problems. Couldn't update itself. I couldn't work out why--I hadn't changed any policies or anything--but I really didn't spend a lot of time looking into it. Defender is about as useful as teats on a bull and, frankly, I was pleased that it was no longer wasting bandwidth.

Friday, I shut the machine down in the morning, and when I started it up again in the afternoon I couldn't connect to the internet. I was connected to my local wireless network, but I had no IP address. Further investigation revealed that a number of services, including the DHCP client, the Diagnostic Policy Service, and the Time service had failed to start. I couldn't start them manually, either--access denied. This was puzzling; I hadn't changed any policies or access rights. I enabled the Administrator account--that didn't work. I turned UAC off--that didn't work. Nothing in the event logs. Nothing peculiar reported by the Sysinternals Process Monitor. I pored through the registry. I trawled forums and found that many other people had experienced this problem, but nobody had a solution that was applicable to my setup. No domain auth problems, no corrupt or missing drivers, nothing.

Then the Windows Firewall (I know, I know...) started reporting problems: the driver service didn't exist or was marked for deletion. Well, that was peculiar--I could see it running just fine.

Somehow the permissions of the local system had gotten screwed up, and the problem was worsening. UAC started turning itself back on after several reboots. Computers do not magically hose themselves. I annoys me every time some civlian says "It just stopped working" or "it broke", as if they couldn't possibly have caused it. But there I was, wondering what kind of demon had possesed the box. Which of course suggested spyware. But how? I work in the anti-malware industry and I couldn't locate any kind of infestation. Perhaps a bad update from my antivirus or antispyware software? Sounds likely--this is the reason I don't use any of the products I work on on my own box. If we seriously mess something up, I don't want at least my own machine to be harmed when I can least afford it. So I uninstalled my security software, but that wasn't it.

Back to the forums: the only remaining solution was to reinstall the OS.

I thought about it for a while. A number of my colleagues--IT professionals who love new toys--have been downgrading from Vista after only a few days. A couple of them love it, but most of them seemed unduly skeptical of it... or so it seemed to me at the time. I thought about it for a bit more.

This really is the first time in many many years that I've had a support issue on my own box that's left me stumped. It's a brand new machine, and it lasted three weeks before something mysterious started tearing down my OS. I thought some more. This machine is three times as powerful as my old one, but usual suite of apps have been running at much the same speed--that can only be attributable to the OS. What was Vista giving me in exchange for the performance cost? Fancy UI, a marginally better file explorer, and the likelihood that I would again suffer these same dyspraxic problems at some point?

So now I've gone back to XP. It's cost me another day, but I have everything mostly set up again now, everything us running noticeably faste,r and I'm pretty sure the system isn't going to start locking bits of itself away from other bits for no discernible reason. Maybe I'll try it out again next time I have set up a machine, if the Service Pack is out, but I'm back on the road in another week or so and I can't risk having to rebuild it--again--while I'm overseas. If I get the urge to play around in the meantime, perhaps I'll put XP 64 back on.

-- JF

Onwards.And.Upwards

Jason Franks — Sat, 01 Dec 2007 00:09:20 GMT

Haven't posted in a long time. Looking at what I've writtten so far, most of myposts have been essays, rather than journal articles. There's been a bit of mayhem going on over here and I haven't had anything I felt driven to talk about at length. But today, this is a bit of a blog post.

We have a new government in Australia. The Labor party have replaced the conservative coalition that's been running the country for the last decade. It's been a decade of boom, but it's hard to know how much credit to give old Johnni Howard and co: frankly, they'd have been criminally incompetent not to make money out of China's new hunger for our mineral resources. The country got wealthy, but the old government didn't spend much of the surpluses besides giving out some tax cuts. Even the Iraq war didn't put much of a dent in our profits. Meanwhile, our infrastructure is aging, our healthcare and education systems are crumbling, and we still don't have proper broadband like the rest of the developed (and not-so-developed) world. The new Labor government at least claim that they have policies to rectify all of that. About bloody time Australia joined the 21st century.

But it no longer matters as to me, personally: I have a new job starting next week and I'll be working remotely for a European company. So, while I'm still here, I've really been brain-drained a second time. This is an ideal position for me; it's more a research than a development gig and I'll finally get to use the stuff I went to University for in the real world. I get to concentrate on innovating and I'm out of the maintenance/release cycle for a while. I couldn't be happier, truth be told.

Left my old job last week. I was sad to see the back of my team, after only 6 months, but it's a choice between doing the work I've always wanted to versus rehashign the work I've done before. No contest, really. Sunday I'm flying to the States for planning and preparation meetings.

My HP laptop died on the weekend, which highly inconvenient. Haven't been able to find a shop that's prepared to maintain it for me, because it's out of warranty and I bought it overseas. It's a small fix, but they claim that getting the parts will be a problem... although my machine was manufactured in China just like the rest of HP's stock. So I had to rush out and buy and set up a new laptop. Went for Fujitsu this time; they're the only brand besides Sony who still manufacture in Japan. My experience with Japanese laptops has been like my experience with Japanese cars: they keep going forever. So far I'm pleased; it's twice as powerful and 2/3 of the weight of my old HP.

Off to finish packing. 2008 is going to be a very different year for me; I'm looking forward to getting down and dirty with the sort of computer science I've never been able to practice before.

Excelsior!

-- Jason Franks

Decoration

Jason Franks — Mon, 08 Oct 2007 01:43:42 GMT

Been involved in a discussion about what 'elegant code' means lately. I'll try not to get too C++-specific, but that's what I spend most of my days working in and I'm sure that will show.

Elegant solutions are something that all developers claim to aspire to, but what does that mean, exactly? Code that will impress? Code that uses Design Patterns? Buzzword-compliant code that's built on the latest hot gimmick? While I'm a long way from being a Grumpy Old Programmer, I've been a down-n-dirty C++ for long enough to know better than that.

We all know what isn't elegant. Big fat unstructured functions, global data, copy-and-pasted code, logic that's been encapsulated in the wrong places, if it's been encapsulated at all. Nested switch statements, gotos, do{ } while(false) constructs, misuse of exceptions. Almost any use of the preprocessor to write actual code (hint: if your macro takes up more than one line, it should be a function).

Many of us make claims that small pieces of code are elegant, but I've seldom heard anybody describe a completed system as elegant. The bigger the project, the less elegant it becomes. "Elegance" becomes a series of flourishes or signature tricks confined to small functions or features, while the rest of the system is hacked and patched together. I put it to you, lads and lassies, that this is an engineering failure. The design of the system AS A WHOLE should have priority. The big picture should be consistent and definitive; if some of the more granular parts are less than perfect, that's okay. They can be fixed. More often than not, though, I see crumbling systems bejeweled with tiny intricate classes that do very little besides add to the dead weight.

Let's face it, we software engineers have a definite tendency to overengineer. We all like a challenge, and, when confronted with a mundane task, there's always the temptation to get fancy, if for no other reason than to stay awake. So we write buckets of unnecessary code-- code which is far to intricate to reuse, let alone maintain--and, when, asked to justify its existence, we claim that it was 'elegant solution'.

I'm sorry to tell you. but it's not.

Elegant code is simple, easy to read, and concise. Elegance implies that you will write less code, not more.

The best engineer is the one whose code is the shortest, the clearest, and the easiest to maintain.

If your class library requires a user to implement a suite of specialized templates, and multiple inheritance across numerous hierarchies, and a thousand functors to hold this all together, and in the end all it does is raise a messagebox? It's not elegant. If I can't work out how a simple for loop runs without having to open a dozen other code modules, the code is too granular.

Make no mistake, I'm all for investing in code infrastructure that can be leveraged to save time and effort in the future--code that will be highly reusable and that will save us from repetitive and dangerous copy-and-paste-search-and-replace coding. Infrastructure that will allow engineers to write less code as they build out the system. I'm a huge advocate of design, but I'm also an advocate of not sweating the small stuff.

Over-engineering usually follows in the decadent phase of a project that was under-engineered to begin with, and it's completely counterproductive. You want to prove you're a real engineer? Next time you want to build something frilly and decorative--you know it when it happens--go instead to the bits of the project you don't like to look at. The old modules that your much-maligned predecessor wrote, in between puffs on the crack pipe. The decaying structures where the real work of the system happens--or should happen. Get in there and work out how to fix it. Find a path that will allow you to fix the fundamentals of the system without hurting the build out of new features. Work out how much time and code it will save and sell it to your management team. I guarantee you'll get more satisfaction from deleting a thousand lines of crap code and replacing them with one than you will from checking in a thousand lines of new code that does bugger all, but does it in a really pretty and buzzword-friendly way.

Be an engineer, not an decorator.

-- JF

Dev.Culture

Jason Franks — Wed, 15 Aug 2007 16:44:55 GMT

Further musing of the Mysteries of the Vanishing Devs.

As discussed in my earlier post, there's a shortage of developers. Big companies are complaining that it's hurting their bottom line, but developer salaries do not reflect this. Small wonder that the talent pool continues to shrink. But that's just the first part of the mystery:

Seems like there are still a lot of development jobs are for small companies, and I'm curious as to how they can compete in what should be a a much tighter market.

In my career, I have mostly worked for smaller businesses: 15 people, 30 people, 60, 120. I prefer it; I worked for one of the big boys for a while and it was the worst experience of my career. Office politics has an inverse relationship to development work, and the bigger the company, the bigger the politics... the smaller the amount of actual development. I'm a developer, not a politician.

Anyway. Let me posit this as a formal argument again, because I'm a formal sorta dude:

Premise 1:There are a limited number of developers available
Premise 2: Big companies are hurting for developers.
Premise 3: Big companies have more to lose than small companies
Premise 4: Big companies have more to spend than small companies.
Conclusion: Big companies should have bought up all the developers, and there should be none left for the smaller guys.

But this conclusion doesn't hold. But why? If it's really that costly, why are there so many small shops in business? How can they even begin to afford it? I think there are several factors in play.

Firstly, I don't think the big companies, for all their complaining, truly understand the value of development. This is particularly true of non-tech businesses like banks and insurance companies, who, like it or not, are among the biggest customers for large scale development. Dev is expensive, it takes a long time, projects are late, projects fail. Nobody wants to invest in staffing or training, they want everything quick and cheap. Money men don't appreciate what's involved in planning a project for success, and they're just going to continue half-assing it until somebody gets upset, lays off the R&D department, adds a zero to the budget and outsources everything. They don't know any better, that's how they were trained and that's how software services are sold to them by those of us who should know better.

This attitude is reciprocated: a lot of developers--including me--don't like working for those guys. We don't like filling out TPS reports or sitting in meetings. We like to report to other engineers, not to middle-management MBA types.

Another factor, I believe, is that there's an entrepreneurial spirit to software that I think other engineering disciplines lack. We want to build new things, we want to make an impact... and we don't _need_ tens of millions of dollars to accomplish anything. In software, we can built anything we imagine from nothing but keywords and logic. Garage development continues to be the leading edge of software--corporate money is required to polish and commercialize those products, but corporate structures are often antithetical to breaking new technology in a timely fashion. That's why there's this continual cycle of big companies acquiring smaller ones.

The story of the hero developer is never about a dude who joined a big company and worked his way up from the mailroom; it's about the guy who founded a company that grew into a behemoth, the visionary who built something that one of the big boys him or her paid millions for because their own internal, hidebound, reactionary, shareholder-accountable structures didn't think of it or failed to deliver it.

At the end of the day, I think the reason that the market is as loose and nonsensical as it is rooted in developer culture. We are iconoclasts, loners, wizards. Geeks. Idealistic as it sounds, I believe that, as a community, we are not demanding the money we could because the work itself is our reward. We do it for the doing of it.

-- JF

Better.Dev

Jason Franks — Sun, 12 Aug 2007 19:03:15 GMT

My first thought, when Martin Hinshelwood tagged me with this 'becoming a better developer' meme was "what's this nonsense?"

My email chain-letter aversion had already kicked in. My next was surprise that anybody had actually taken enough notice of this blog that they remembered who I was.

After that, I grumbled to myself a bit.

Then, finally, I noticed that I have developed an attitude problem... and that is certainly something I need to work on in order to become a better developer. First, though I need to understand where it comes from.

It's a recent problem, I think, and me starting this blog is a symptom of it. It stems from my returning to Australia, after five long years overseas, to find that the sickly IT industry I left behind is now on life support. Corporations grumble that there are no devs, but universities have cut Comp Sci faculties. Salaries have fallen, despite our booming economy. Our government, which considers telecommunications an unnecessary pain in the arse, won't even acknowledge that we exist. I left the States on the back of a large payrise, feeling like a valued asset, and I came home to a staggering indifference.

My reaction has been to bitch and moan about it. Sure, I'm working and I'm entertaining a side project or seven, but I have this constant need to grumble about everything. My coffeetime conversation at the office consist in a large part of war stories from my time in the States. But when it comes to learning or improving my abilities? I'm not doing a damn thing, and that is not like me at all.

So, step one, is to pick up my game. Start paying attention to now instead of then. Step two? Start playing with some new toys--that's the best way to motivate myself. There are parts of BOOST that I want to learn more about. I want to download the ORCAS beta and see what I can learn about the interop possibilities between .NET and STL containers. I need to set up the LINUX box I've been promising myself for ages, because it's starting to feel as though I'm going to have to change platforms if I want to remain a C++ developer.

Can I become a better developer while continuing to bitch and moan for your entertainment? Why, yes, I believe that I can.

-- JF