Coding vs. Configuration

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/coding_vs_configuration.htm]

Real-world applications need to be configurable. There are lots of reasons an app must be configured - different environment, modify the thresholds, even change what providers are used for a task. There's a big difference between coding, and configuration:

• Coding implies writing the actual logic in some language (C#, VB, Java, Html, JavaScript, CSS, Sql, etc...). Coding, by its nature, can deal with complex logic, and may reside in many files across many directories. Sometimes code needs to be compiled into binaries. There's a lot of room for error here, which is why IDEs (like Visual Studio) provide code debugging, and why the community encourages unit tests and code reviews.

• Configuration implies using knowledge of the domain to tweak the app, after it's been deployed, usually via a small number of config files.

	Coding	Configuration
Requires knowledge of language syntax	Yes (and usually for many languages)	No (syntax is usually just xml. A huge point of configs is that they abstract out syntax).
Requires business domain knowledge	Yes	Yes
Requires re-compiling	Sometimes (C#, Java --> Yes, Html/Sql --> No)	No. Usually just xml or plain text
Number of files	Many - a 10,000 line app, with 50 files, could still just have 1 app.config	Few (usually just 1, or 1 per directory)

 

More and more, the push is to abstract coding into configuration. I believe WCF is big on this - instead of getting bogged down in how to transport data (web services, remoting, FTP, messaging, etc...) you just configure the app as appropriate. We also see this in domain specific languages and code generation. For example, .Net tiers has a big config file, but it makes perfect sense if you understand the concepts of N-Tier architecture. So, you can do a little configuration, and it generates 1000s of lines, which spares you from tons of tedious coding.

Career path from hobbyist to professional

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/career_path_from_hobbyist_to_professional.htm]

Software Engineering is unique in that it offers a gradual path from a hobbyist to a professional. Many professions do not. For example, there's a world of difference between building a dog house vs. a sky-scraper, or giving first aid vs. performing open-heart surgery. To be an authorized civil engineer or doctor, who offers products and services to the public, there are rigorous standards that must be met. It's not just that 10 years of hobbyist experience of building dog houses won't give you the necessary professional experience to design a sky-scraper, it's that federal law won't even allow you to authorize the blue-prints. For example, if memory serves me right, to authorize civil engineering blue prints, you need to first go to an accredited university, then pass a huge "Engineering in Training" exam, then work under the guidance of a professional engineer for 5 years, then pass a second exam. Then, and only then, are you legally even allowed to approve a blue-print.  There is not a gradual path, but rather one with steep cliffs.

 

Software Engineering is totally different. There is a gradual path. You could start doing hobbyist web sites on your personal laptop. You can then continually learn more doing harder projects (perhaps for non-profits, or just for fun). All the while, you can read the same books, go to the same conferences, and use most of the same tools that the professionals use. You could then enter the lower rung of the professional world by getting a low-paying contractor job on a short assignment, publishing in an online journal, or contributing to a popular open-source project. From there, you could jump to larger teams, or do harder projects, and the rest is history.

 

This potential gradual path from hobbyist to professional has pros and cons. It offers great opportunity, because almost anyone who has the mental ability, passion, and a computer can enter the profession.  However, the con is that many developers (doing paid, real-world, work), still treat it like a care-free hobby, as opposed to professional work.

 

What separates a hobbyist from professional? Scott McChonnell's good book, Professional Software Development, offers a lot of good ideas. I think some important traits of a professional include:

1. Having public process that works for a team of developers - i.e. a team build server, team source control, etc...

2. Writing code that works on other people's machines.

3. Writing code that scales, is secure, and maintainable by other people

4. Producing deterministic results

5. Providing schedules and estimates

6. Using industry best practices and design patterns, not just your own personal bag of tricks

7. Referencing official standards, not just "I heard somewhere on some blog"

Of course there's more, but this is a start. The good news is that even as a hobbyist transitions to a professional, they can still pick up things like these. It makes me appreciate Software Engineering as a truly wonderful field.

Why care about migrating classic ASP to .Net?

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/why_care_about_migrating_classic_asp_to_net.htm]

Of course we'd all like to use the latest and greatest technology, but sometimes that isn't just handed to us. One example is all the people who know classic ASP, but haven't had the opportunity yet to officially jump to .Net. A practical learning transition for this would be migrating a ASP application to ASP.Net. Even though ASP and VB are over 6 years removed, there are still some benefits to this:

• Good transition to get your foot in the door with .Net.
• Classic ASP apps still uses a lot of marketable technologies - Html, JavaScript, Xml, CSS, and perhaps SQL for the backend), as well as  concepts like client-server and general web development.
• Think of it like instead of getting your business requirements from a product manager, you're getting them from an existing program.
• Working with an existing app will probably give you new ideas (as opposed to writing everything from scratch).
• Seeing how the old technology solved hard problems will give you an appreciation for the new technology.
• You know that if business-sponsors are investing to migrate a classic ASP app (as opposed to just abandoning it), that it likely was a successful and profitable app.
• Focus on the future, not the past: If you're the one who migrated the app, you probably have a future in leading the exciting new .Net version of the app.

It's not ideal for everyone, but there are perks to being on an ASP migration project.

Slow and controlled over fast and uncontrolled.

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/slow_and_controlled_over_fast_and_uncontrolled.htm]

In my personal experience, I notice that most developers would rather user a technique that takes longer (but for which they have complete control over), then a faster techniques (for which they can't really control). They want a slow and controlled shot over a faster, but random, one. For example, they'd rather use

• A cumbersome open-source project (which lets them step through and modify all the code), than a powerful framework that they cannot modify.

• An older technology that they've mastered, than a new one that "sounds" promising.

• Their own code (that they know inside out), than someone else's, or a third-party, that's obscure.

To some degree, this makes sense. Who cares if a technology or component is powerful if you cannot harness that power? The problem is if you cannot control the code, it becomes not just useless, but rather dangerous. The un-intended consequences will kill your schedule. However, good developers need to constantly learn, and tame those powerful, yet still-wild, technologies. For example, a developer may be afraid of regular expressions, and comfortable writing tons of string-parsing code, but ultimately they need to learn regular expressions.

Tool: Microsoft SQL Server Database Publishing Wizard 1.1

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/tool_microsoft_sql_server_database_publishing_wizard_11.htm]

I was experimenting around with some starter kits, and I came across this good, free tool - Microsoft SQL Server Database Publishing Wizard 1.1. Basically, it can write a database schema, and data, to a sql script. I think it has a command line API too!

 

I found this useful when trying to deal with some database in a starter kit that I couldn't access outside of Visual Studio. I wanted to be able to script and extend it. It was in an ASP.Net 2.0 app_data folder. I'm sure there was a way around it, but this approach seemed so much faster for me. I scripted the database, and then re-ran the script in SQL Studio, and changed the asp.net db connection strings to that new database.

Paylocity is Hiring for a Software Engineer (in Chicago)

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/paylocity_is_hiring_for_a_software_engineer_in_chicago.htm]

Our software engineering department is hiring again. This is a technical position, we're located in Chicago. You can see the job description here.

• Great Learning Opportunities: Working with cutting-edge .Net development (already migrated to .Net 3.5)
• Work-Life Balance: Local software department - no travel. Dress code is casual. Office hours about 8-5. We have laptops and can do extra work at home.
• Working from home twice a week.
• Job Security: Smaller company (175 people total, 30 in software department), so we're too small to be outsourced, and privately owned (and owner refuses to sell), so we won't be sold.
• Company has been profitable and grown every year (for all 10 years) - even during the IT crash we still grew.
• Interesting work: There are separate IT and Internal development departments. Even within our department there are separate QA and Business Analyst teams. Therefore you can focus on development.
• Great, collaborative team. Average person has maybe 8 - 10 years experience. Team is large enough that you can specialize in areas that interest you (UI, Business Tier, Database, etc...), yet small enough to still get an interesting variety.

If you're interested, just leave a message, or email me directly at tims@paylocity.com.

 

As an aside, Jeff Atwood has a great article on interviewing.

Purist vs. Pragmatist

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/purist_vs_pragmatist.htm]

I've seen a lot of different developer personalities over the years. Two main groups, who always seem at odds with each other, are the "purists" and the "pragmatists".

 

Here's a brain-dump based on my personal experience:

• The purist wants to do pure, perfect coding, and never get their hands dirty with un-pure code.

• The pragmatist wants to get the product shipped and make the client happy, but may take hacks and shortcuts to do so.

I see pros & cons to each approach.

 

	Pro	Con
Purist	PRO: Always trying to do it right, wants to avoid hacks that would be costly later on. PERCEPTION: Seen as visionary leaders whose best-practice principles set the entire project on the right path, and spares the team from endless hours of hacks. EXAMPLE: "This is a 3 month project, we're going to take the first week and set up a build server with proper continuous integration". FAVORITE SAYINGS: "We got to do this right" "These are the best-practices" "Look at the rate-of-return"	CON: It is easy to be a purist on paper, or with the easy problems, but the mess of the real world (deadlines, client changes, complex technology, personality differences) means that we often need to make compromises that aren't always perfect. PERCEPTION: Seen as ivory-tower elitists who never actually get the job done because they keep waiting for the perfect component in an un-perfect word. A purist is more talk than action, and because it's easy to talk, purists are always asking for the impossible. If a purist actually had to do it themselves, they'd act like pragmatists. EXAMPLE: "That fileCopy utility (used only for internal development) isn't good enough because it may not handle the new encoding standards in three years, you need to re-write it from scratch." FAVORITE SAYINGS: "My previous project (which did everything perfect) got this right"
Pragmatist	PRO: Focuses on getting the job done so that the company stays in business. PERCEPTION: Seen as the "real workers" in the trenches who get the job done. EXAMPLE: "It'd be nice to have a script that automatically deploys the entire product, but there are some third-party manual GUI configuration steps that we just cannot automate yet" FAVORITE SAYINGS: "Talk is cheap" "It's easier to describe than implement" "Show me a proto-type" "How will you find schedule time for that"	CON: The pragmatist may get so caught up in "just getting it done", that they always take the immediate solution, which is usually not the best long-term solution. PERCEPTION: Seen as desperate hackers who get the current product out only by writing mountains of bad code, for which the purists later spend 10 times the effort to fix. EXAMPLE: "This component is due next week, I'll just copy this code to ten different places because I don't have time to refactor it." FAVORITE SAYINGS: (bad if used as a justification to commit some hack) "We got to get it done" "We don't have time".

 

You could simplify this as the purist is obsessed with the cause (we'll do it right, no matter how long it takes), the pragmatist is obsessed with the effect (we'll ship a product, even if we need to cut corners).

 

Of course, I think the ideal approach is a balance. The very good book, The Pragmatic Programmers, shows many such balanced-techniques. Sometimes, you'll be forced into a hack - but there are still good ways to handle that. It also helps having a team with a range of these personalities so that people can hold each other accountable and bring out the best in one another.