This is a post by a software engineer trying to make a career decision.
The question can be summarized as: "do I need to take this path or the other one?". These career decision questions are normally phrased as stumbling upon an opportunity, encountering a dead end or you simply feeling the need to make a change. I have a problem answering the questions, as the questions only show one aspect of the dilemma.
The questions show the dilemma as choosing a path and looking the direction this path takes you, expecting a clear view of the outcome. The rational is to select the best outcome and see the decision as a critical point in time. My perspective is different, there is a process and a change evolved in making career decisions.
The process of career buildup requires dedication, perseverance and constant adaptation to change. There are no shortcuts to building competence, as detailed in the post on learning in 10 years. There is an amount of experience you need to accumulate and some errors to be done. Then the question regarding career paths becomes a question of experience given and taken in the specific role. Why giving? Because making errors is a way of giving to the company, making the errors an opportunity and in turn making the question not about choosing but about attitude and actions while doing the job.
My answer to the question presented in the beginning is actually a new proposition: "where do you think you will make most errors, and where would you be accumulating the experience in doing something?"
Since a week is a easy to manage time frame, the work is divided into specific work items:
Item
Content
Duration
(weeks)
User perspective design
Information
Flow
User actions
1
Backend logic
DB design
Flow design
Information model
2
URL logic
Pages flow
relationships
0.5
Infrastructure coding
DB coding
DB interface coding
1
Main page coding
Menus
Links
2
Table presentation coding
Presentation table
Editing table
2
Security
Logic
Cookies
Enforcement
2
Testing
Developer testing
End user testing
4
Total
14.5
Due to the limited timeframe, only a subset of the application can be developed, forcing stepped development. For stepped development, grouping functionality allows concentrating on specific features without having to skimp all over the place.
As first step of the project, only three features need to be developed:
database
Menus and URLs
main table display
Having these 3 features allow internal deployment, using a local computer and the parents reading the information from a monitor.
So the plan now is:
Item
Content
Duration
Design
Data model
Urls
Site flow
2 weeks
Database
Table creation
SQL queries creation
1 week
Main Page
Header
Footer
Menus
Links (static)
2 weeks
Main table
Calendar
Main entry table
Main display table
2 weeks
Testing
With sample or real data
2 weeks
Total
9 weeks
Having 14 weeks, this is doable, even with some delays added.
In previous posts, I've discussed the use of a wiki for information sharing in an intranet. The main idea is having a central repository where each user can provide its insight and discuss the presented information. The posts discussed the requirements and possible alternatives.
The finalists were:
twiki
tikiwiki
mediawiki
First TikiWiki was tried, as it was heavily recommended for CMS and wiki. The installation was a breeze, because a Linux server was available for testing with the required prerequisites already installed.
During the testing some things became clearer.
The wiki needs to support well Microsoft word documents, for importing and exporting.
Wiki management is a difficult task, specially for configuring the first settings.
Selling the idea of a wiki is way easier than making others use it. The wiki should be designed to solve real problems and have a compelling reason to be used.
After having the insights, the whole strategy changed. The software options were limited to software supporting easy import and export of Microsoft documents. At the same time, I'm looking for people that are willing to give the wiki a try and create content with it.
The wiki software I'm going to try is:
Confluence
Xwiki
My hope is people finding the wiki as helpful as I think it can be and easy to use so it can help everybody. After using xwiki I'll update on next steps.
The kindergarten information site has specific requirements, same as any other project. Normally the requirements are specified in some requirement document or RFP. Unfortunately, for this kind of project I have to make the requirements and analyze the consequences.
The requirements can be divided in 3 categories:
Functionality requirements - what is the site required to do.
Non functional requirements, also known and quality attributes - how well then site is required to be.
Security functionality - the security model and information management within the site.
Since no end users are available, the requirements are specified here:
functionality requirements:
the website should allow presenting information regarding activities of each child, joint and separated.
Information is one of several categories and includes comments.
The information should be entered in a table, as easily as possible
non functional requirements:
support up to 20 parents and children
support any browser and operating system
support customization of the website css and users
can be deployed in secure environment
suitable for hosting
fast development time
security requirements
segmentation of information between parents and staff
support of authentication and anti spoofing
use safe password storage mechanism
These are some really basic requirements allowing for analysis and initial decisions to be taken.
Operating system, language and database is a no brainer, as I support Linux and open source, so its LAMP: Linux, Apache, Mysql and PHP.
Regarding the 4 questions for a basic project:
What: web site for information sharing between kindergarten and parents:
How: develop a website software using PHP in LAMP configuration.
How much: one site, supporting up to 20 children.
When: Start now and actual use by end of August.
As you can see, even with very sketchy requirements, some basic design and architectural decisions can be taken.
Software debt - another type of rot (by Daniel Leiderman-Gueller, published Saturday, 07 March 2009 12:53)
Since software is a solution to some requirement, software evolves, the same way as requirements evolve. This is true for games, commercial applications and open source projects. This evolution comes with a cost, as so well described by Jeff Atwood. For me, the process is very familiar because it occurs in almost any project with a large lifespan.
While the post itself is interesting, some of the comments were enlightening, mainly on how people fail to see the problem. Specially this comment:
This post pretty much boils down to "we have to refactor/rewrite some stuff on our software project" - Big deal, so do I; and probably so does the poster above me, and the one above him.
Details Jeff, is what makes a technical article... technical. Otherwise this could have been written by a 2nd year business major.
The problem is not that you have to refactor/ rewrite. The point of the article is that refactoring/rewriting is part of the process, of understanding the why .
The reason code rots or accumulates software debt varies, but has some very simple reasons:
The requirements change
The design is rushed / non existent
The development is rushed
The testing is rushed / non existent
Code fashion changes
Any of them or a mixture will cause software debt, and almost all of the reasons will apply in a larger project. Thus you need to take into account a refactoring phase that can sometimes be large as an architectural change. Because most of the refactoring occurs after the original code has been long used we as programmers see it as "WTF" who wrote this, forgetting that it might had some real reason long ago.
Laugh all you want of previous mistakes, you will make your own mistakes mainly because requirements change.
Quick and dirty design - thoughts (by Daniel Leiderman-Gueller, published Tuesday, 10 March 2009 09:10)
Last week I got a call from a past coworker, asking for design guidelines and comparison between storage vendors. The question itself does not surprise me, but he wanted the information distilled into a few sentences, so it can be presented to management for decision taking.
The situation raised a question; can design be done quick and dirty?
The Agile process promises shortening development time by leaving the waterfall method of design up front, and instead do it on the move while coding. YAGNI promises limiting the design only to parts really used and KISS provides a sound reason for doing it simple. To put it in a few words, the processes above try to replace the waterfall model with something interactive, where design changes with the experience learned while coding and allowing for maneuver room as requirements change.
What do I perceive as a problem in the agile processes?
Design in parts can corrupt the conceptual integrity and provide very limited concepts at the start
Technical debt due to development done according to limited design
Limited infrastructure design can lead to architectural changes along the way
Should one or more of these problems occur, the presumed gain in time will be lost due to architectural modification and probably code rewrite.
Are there other options? Or just Agile vs. Waterfall?
I believe that the extremes are too extremes, that some compromise should be taken. And this is where I concur with Joel, on having requirements and initial design up front. Agile processes can be then used for low level design and coding when the gross conceptual framework is already defined.
Would I be in my coworker place I would take time to design the main components of the system, while analyzing the requirements deeply. These are the major components that need attention and not use snippets of information for decision taking.
Program manager or system engineer? (by Daniel Leiderman-Gueller, published Sunday, 15 March 2009 00:42)
This post on Program manager by Joel Spolsky describes what a program manager does, how to become a better one and what the role distinctions are. The main idea is that a program manager provides the specifications, communicates the design and serves as customer advocate.
This definition is quite similar to the task of a system engineer: (from INCOSE)
Systems Engineering is an interdisciplinary approach and means to enable the realization of successful systems. It focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, then proceeding with design synthesis and system validation while considering the complete problem.
What is comparable?
Defining customer needs - same as being customer advocate.
Required functionality - specifications.
Documenting the requirements - communicate.
To me is seems that the roles are very similar especially considering the following list:
the tasks are similar
the competence required for the job is similar
the role is a peer to the developer
the role should generate a positive conflict with the developer
the role should gain respect from the programmer
So why do we have two definitions?
System engineering profession came into existence for systems that required large cooperative effort in Bell Labs.
Program manager was described in the mythical man month as the "chief programmer" with enough experience to detail the functional and performance specifications.
In my opinion these two definitions of roles come to life because of people working in different worlds using different vocabulary and still facing the same problems of complexity and distribution of work. System engineering handles complex multi disciplinary projects and designs, where program manager handles the same, but in a software only world.
Since most system are becoming more software intensive, replacing tasks done previously in hardware with software solutions, the system engineer becomes more involved in software design, in a way performing the same tasks as a program manager for software projects. The evolution of the system engineer only confirms that the distinction is only artificial only due to the nature of separation of worlds.
Back to the original post, Joel's suggestions are valid for system engineers, especially the part of earning peers respect's while keeping your head open and learning.
Clearing SDD FUD (by Daniel Leiderman-Gueller, published Wednesday, 18 March 2009 14:20)
The last months there has been a lot of FUD regarding SSD vs. regular HD. Most of the ambiguity was regarding performance and suitability to different usages and whether it was really something different.
Mechanical hard disks use a magnetic plate for storing the information using a read / write head. The plate is divided into concentric circles, and each circle is divided into short stripes each storing a specific amount of information. A more detailed explanation can be read in howstuffworks.
SSD use memory chips for storing the information same as RAM, with the difference that the information is persistent until next change.
There are three concerns in hard disks:
Throughput - how many bytes can be moved between the computer and the hard disk in a defined period of time, this is normally measured in MByte / sec for a stated block size.
Latency - the time it takes from the moment you request an action until it is really executed on disk, this is normally measured in milliseconds.
IOPS - the number of read or write actions that can be performed in a defined period of time, this is normally measures in IO per Second for a stated block size.
In mechanical disks, there is a limitation on how fast the head can reach the sector to be read / write, it affected the latency due to the head having to reach the start of the file, the IOPS and throughput because of repositioning of the head in middle of files.
In order to alleviate the problem of head movement, different methods were used, like Native Command Queuing and disk defragmentation.
The SSD does not have a problem of head repositioning because each sector is fetched directly using a direct mapping from memory. Thus methods used on mechanical disks like defrag or NCQ are not relevant. SSD have a limitation on throughput due to the time it takes to read a sector from memory.
Just to understand the different performance benefits, here are 3 disks to be compared:
As you can see, there is a huge difference in IOPS for SSD, but a lower benefit for sustained transfer of sequential information. This raises the question of best use of SSD taking into account the price of one disk.
The best practices form EMC specify that SSD should be used for IOPS intensive use, like DB indexes of frequently accessed small files. The SSD is currently unsuitable for storing large files requiring high throughput.
As always in engineering, each option has a different tradeoff, and with enough clear information a judicial decision can be taken:
SATA - high density, low price and medium throughput
FiberChannel - low density, higher price and very high throughput
SSD - lowest density, highest price and very high IOPS
The future might hold surprises in capacity and price, but it will take some time till there is only one winner.
The problem with design and agile is already known (by @daniel, published Monday, 29 November 1999 16:00)
even agile advocates understand the problem
http://jamesshore.com/Blog/The-Decline-and-Fall-of-Agile.html
